Login failed

[Mela Eckenfels]

Oh my god,

please say there is a solution..

I have my own installation of clipperz communitiy edition. Trying to
login tomorrow I got a "Login failed" and the popup won't disappear. I
reloaded the side and tried again. Login failed. A tried a couple of
times. Login failed.

I tried from a different computer. Login failed.

The login _is_ correct, checked double and thrice.

Can you please give my tips how to save my really huge clipperz-db?

Mela



P.S.: Application version: community.edition (revision 3)

[Adam McMaster]

Have you tried using an offline copy? (Assuming you have one saved somewhere.)

[Mela Eckenfels]

On Jun 24, 11:39 am, Adam McMaster <a...@blamethebull.com> wrote:
> Have you tried using an offline copy? (Assuming you have one saved somewhere.)

The offline copy do open. But it is much too old. My fault, I know :-(

[Giulio Cesare Solaroli]

Hello Mela,

a couple of questions to try helping you:

Have you got a backup of the MySQL DB?

Have you tried using a different browser?

In case you are using Firefox, have you tried disabling all extensions
(this is possibly easier creating a new profile)?

Have you got just a user on this DB? If you have more users, do they
all have the same issue?

Have you tried creating a brand new user?

Have you changed anything on your server lately (installed an updated
version of PHP / Apache / MySQL)?


Now a few more things to check:
- try loading index_debug.html instead of index.html and see if some
meaningful error is reported in the browser console (the best option
is to use Firebug within Firefox);
- look into the server for PHP error logs.


If you can provide some feedback about this questions we could try to help you.

Regards,

Giulio Cesare

[Mela Eckenfels]

On Jun 24, 12:23 pm, Giulio Cesare Solaroli <giulio.ces...@gmail.com>
wrote:

> Hello Mela,
>
> a couple of questions to try helping you:
>
> Have you got a backup of the MySQL DB?

A nightly binary backup. I've forgotten to put the clipperz-db into
the nightly db-dump :-(

>
> Have you tried using a different browser?

Not by now.

>
> In case you are using Firefox, have you tried disabling all extensions
> (this is possibly easier creating a new profile)?

Nope. But creating a new user works flawlessly.

> Have you got just a user on this DB? If you have more users, do they
> all have the same issue?

More users, but only this user has the problem.

> Have you tried creating a brand new user?

This works.

> Have you changed anything on your server lately (installed an updated
> version of PHP / Apache / MySQL)?

Yes, but a couple of days before the problem occurs. Clipperz worked
between then and yesterday evening. Yesterday evening I logged in,
added a new Card, checked it and logged our. The problem occurs this
morning after getting up.

I've updated the apache and some PHP-Modules. (I'm working on FreeBSD
so I use portupgrade regulary)

> Now a few more things to check:
> - try loading index_debug.html instead of index.html and see if some
> meaningful error is reported in the browser console (the best option
> is to use Firebug within Firefox);

I will do this. Hang on.

> - look into the server for PHP error logs.

No error that is related to clipperz, according to the timestamps.

>
> If you can provide some feedback about this questions we could try to help you.
>

I really, really hope so.

Mela

[Lutz]

I also have this problem now. I run clipperz on my own vserver. I
changed nothing on the server. Some days ago the last thing i did was
adding a card to my account. Now i tried to login, but it says "Login
failed". But it is different from a normal "Login failed" with wrong
password. If i use a wrong pass, the background don't changes, while
logging in. But now it changes, so the password seems to be ok.

i have also created a new account. this one works without any
problems!
i also had a try with index_debug.html. but the firebug console shows
no error!

in my usual account i have a lot of etries. may be more than 200.
could this be the reason?

[Lutz]

Lucky as i am, i hade an offline copy which is only 1,5 month old. so
now i exported everything in JSON. Then i created a new account,
imported the JSON, and added 4 direct logins.

After this, I made a new OFFLINE COPY. But with this offline copy i
have the SAME problem. It behaves exactly like my old not working
account.
So it seems, there is a bug in the software. May be i have too much
data in my Clipperz, or may be there is something in one of the 4 new
accounts, which i added, which makes trouble.

I added the following accounts using the "Add to Clipperz"-
Bookmarklet:

Google - https://www.google.com/accounts/Login?hl=de&continue=http://www.google.de/webhp%3Fsourceid%3Dnavclient-ff
ShoutMix - http://www.shoutmix.com/main/login.php
MySipSwitch - http://www.mysipswitch.com/
PaulDirect - https://www.pauldirekt.de/

But before i still had one other Google and one other MySipSwitch
account in my Clipperz without problems. So i guess the reason is
ShoutMix or PaulDirect.

I use: community.edition (revision 3)

[Lutz]

I have forgotten one account:

i also added:

stock.xchng - http://www.sxc.hu/index.phtml

This account SEEMS to be THE REASON!

Because i noticed the new login problem while a test of my new Offline
Copy, i had still the online version of my new clipperz account opened
in an other tab. In this one i still was loged in. So i removed step
by step the new added Direct Logins. After each one, i downloaded a
new Offline Copy and tried to login. After i had removed the
stock.xchng Direct Login, i was able to login agine into my new
downloaded Offline Copy.

So it seems to have something todo with this Direct Login!

The Bookmarklet produces the following code (i have used "testlogin"
and "testpass" here). I hope google groups displays it unchanged:

{"page": {"title": "stock.xchng - the leading free stock photography
site"},
"form": {"attributes": {"action": "http://www.sxc.hu/index.phtml",
"method": "post"},
"inputs": [{"type": "hidden",
"name": "where",
"value": "/index.phtml"},
{"type": "hidden",
"name": "f",
"value": "login"},
{"type": "text",
"name": "login",
"value": "testlogin"},
{"type": "password",
"name": "pass",
"value": "testpass"}]},
"version": "0.2.3"}

[Lutz]

Now, after i thought i can be sure, the stock.xchng Direct Login is
the reason and it helps if i don't put this into my clipperz, i added
other accounts. But i got the same problem again. So stock.xchng seems
to be not the reason.

So now, i think the REASON for the PROBLEM have to be connected to the
AMOUNT OF DATA in the Clipperz account.

Can this be possible?

[Giulio Cesare Solaroli]

Hello Lutz,

I will definitely look into this direct login to see if there is
something that compromise Clipperz behaviour.

THANKS VERY MUCH for the great work done on isolating the problem!

I will keep everybody updated on what I will find.

Giulio Cesare

[Giulio Cesare Solaroli]

Hello Lutz,

I skipped too fast through you mail, and I miss read your last observation.

I have checked the tock.xchng direct login, and it seems to work as
expected (as you have also said, but I did not read properly the first
time).

The number of the cards is definitely not a problem for the Javascript
code; on the online version there are users with much more than 200
cards (I have got about 240 cards and 150 direct logins myself).

There could be some issues on the PHP backend, but in this case it
would be much more difficult for me to debug it; I will try to setup a
community edition instance, and import my own account data and see
what happens.

I will try to do this during this weekend.

Sorry for the trouble.

Regards,

Giulio Cesare

[Giulio Cesare Solaroli]

Hello Lutz,

could you please check one thing for me?

How long is the header field before the data gets corrupted and after?

The header field is in the user table.

It also would be very interesting if you could post the initial and
final chunk of both versions of the header.

Thanks,

Giulio Cesare


On Fri, Jul 10, 2009 at 3:15 PM, Lutz<lutz....@googlemail.com> wrote:
>

[Lutz]

oh, that's a goog idea!

[Giulio Cesare Solaroli]

Hello,

thanks to Lutz precious collaboration, we have managed to collect some
hard evidence that the Community Edition version of Clipperz is
truncating the header field at 65535 characters.

We are still investigating if this is a limitation on MySQL Text
fields, or if the problem is due to the POG library we use to access
the DB.

We will keep everybody updated on what we will find.

Mela, given Lutz finding, it could be possible to restore your data,
if the trim at the end of the header content was not too severe.

Regards,

Giulio Cesare



On Fri, Jul 10, 2009 at 3:15 PM, Lutz<lutz....@googlemail.com> wrote:
>

[Lutz]

Hello Giulio Cesare,

is there still any progress to solve this problem?
the last what i have heard was the plan to analyse if it is possible
to change the data type of the header field in the DB from TEXT to
MEDIUMTEXT or LONGTEXT...

Best Regards
Lutz

On 11 Jul., 02:46, Giulio Cesare Solaroli <giulio.ces...@gmail.com>
wrote:

> Hello,
>
> thanks to Lutz precious collaboration, we have managed to collect some
> hard evidence that the Community Edition version of Clipperz is
> truncating the header field at 65535 characters.
>
> We are still investigating if this is a limitation on MySQL Text
> fields, or if the problem is due to the POG library we use to access
> the DB.
>
> We will keep everybody updated on what we will find.
>
> Mela, given Lutz finding, it could be possible to restore your data,
> if the trim at the end of the header content was not too severe.
>
> Regards,
>
> Giulio Cesare
>

[Giulio Cesare Solaroli]

Hello Lutz,

sorry, but I had not time at all to look into this problem.
I will keep you informed on when I will be able to test the problem.

Sorry for the delay.

Regards,

Giulio Cesare

[Lutz]

Today I had a bit time, so I made a copy of my clipperz dir & database
and took a look into the code. I got it repaired with doing two
things:

- I used the pog generator link which is mentioned in the
class.user.php, to generate a new class.user.php. For the new class
file i only changed type of header from TEXT to MEDIUMTEXT. I replaced
the old class.user.php file with the new one.
- I used phpmyadmin to change the data type of header filed (in user
table) also from TEXT to MEDIUMTEXT.

That's all!
I have added some new cards. Now the content of header field is bigger
as 65535 chars. And it still works.

I did the following tests:
Logout / Login: WORKS
Download & Use Offline Copy: WORKS
Generate, Use & Delete One Time Passwords: WORKS
Delete Account: WORKS

Also the automated table creation using /php/setup/index.php works &
creates the tables like in the new style.
So for new installations it looks like the only thing what is needed
to exchange is the class.user.php file.


This is link creates a new class.user.php file with MEDIUMTEXT for the
header field:
http://www.phpobjectgenerator.com/?language=php5.1&wrapper=pdo&pdoDriver=mysql&objectName=user&attributeList=array+%28%0A++0+%3D%3E+%27username%27%2C%0A++1+%3D%3E+%27srp_s%27%2C%0A++2+%3D%3E+%27srp_v%27%2C%0A++3+%3D%3E+%27header%27%2C%0A++4+%3D%3E+%27statistics%27%2C%0A++5+%3D%3E+%27auth_version%27%2C%0A++6+%3D%3E+%27version%27%2C%0A++7+%3D%3E+%27lock%27%2C%0A++8+%3D%3E+%27record%27%2C%0A++9+%3D%3E+%27onetimepassword%27%2C%0A%29&typeList=array%2B%2528%250A%2B%2B0%2B%253D%253E%2B%2527VARCHAR%2528255%2529%2527%252C%250A%2B%2B1%2B%253D%253E%2B%2527VARCHAR%2528255%2529%2527%252C%250A%2B%2B2%2B%253D%253E%2B%2527VARCHAR%2528255%2529%2527%252C%250A%2B%2B3%2B%253D%253E%2B%2527MEDIUMTEXT%2527%252C%250A%2B%2B4%2B%253D%253E%2B%2527TEXT%2527%252C%250A%2B%2B5%2B%253D%253E%2B%2527VARCHAR%2528255%2529%2527%252C%250A%2B%2B6%2B%253D%253E%2B%2527VARCHAR%2528255%2529%2527%252C%250A%2B%2B7%2B%253D%253E%2B%2527VARCHAR%2528255%2529%2527%252C%250A%2B%2B8%2B%253D%253E%2B%2527HASMANY%2527%252C%250A%2B%2B9%2B%253D%253E%2B%2527HASMANY%2527%252C%250A%2529

[Giulio Cesare Solaroli]

Thanks Lutz!

Giulio Cesare

[Giulio Cesare Solaroli]

Hello,

I have just committed a few changes in the PHP code of the community
edition, in order to create some LONGTEXT fields where regular TEXT
fields were used before.

This should avoid the problem of data truncation that a few users have
experienced.

The new code is available in the public SVN repository (revision 8),
but I have not actually tested it. I will create the packed ZIP as
soon as some users will report a successful installation of the new
version.

Current users will have to migrate the DB, as the structure of the
tables is different. If someone is willing to create a script to
migrate the DB from the current structure, to the new structure, I
will be very pleased to include it in the main distribution.

Hope this helps.

Regards,

Giulio Cesare

[Mike Richards]

Uh, you can take me off this thread, got on it accidentally somehow...

Mike Richards
c/248-835-6184

[Josh]

Hey Giulio,

I finally got around to upgrading my DB to use LONGTEXT instead of
TEXT in the same places that you have changed in the upstream.

These are the commands I used, perhaps they can be used by other
people?

start transaction;
ALTER TABLE record MODIFY COLUMN data LONGTEXT NOT NULL;
ALTER TABLE user MODIFY COLUMN header LONGTEXT NOT NULL;
ALTER TABLE user MODIFY COLUMN statistics LONGTEXT NOT NULL;
ALTER TABLE recordversion MODIFY COLUMN header LONGTEXT NOT NULL;
ALTER TABLE recordversion MODIFY COLUMN data LONGTEXT NOT NULL;
commit;

Thanks,
-josh

On Aug 17 2009, 5:24 pm, Giulio Cesare Solaroli
<giulio.ces...@gmail.com> wrote:
> Hello,
>

> I have just committed a few changes in the PHP code of the community

> edition, in order to create someLONGTEXTfields where regular TEXT

> fields were used before.
>
> This should avoid the problem of data truncation that a few users have
> experienced.
>
> The new code is available in the public SVN repository (revision 8),
> but I have not actually tested it. I will create the packed ZIP as
> soon as some users will report a successful installation of the new
> version.
>
> Current users will have to migrate the DB, as the structure of the
> tables is different. If someone is willing to create a script to
> migrate the DB from the current structure, to the new structure, I
> will be very pleased to include it in the main distribution.
>
> Hope this helps.
>
> Regards,
>
> Giulio Cesare
>
> On Fri, Aug 7, 2009 at 10:10 AM, Giulio Cesare
>
>
>
>
>
>
>
> Solaroli<giulio.ces...@gmail.com> wrote:
> > Thanks Lutz!
>
> > Giulio Cesare
>

> > On Wed, Aug 5, 2009 at 3:13 AM, Lutz<lutz.ho...@googlemail.com> wrote:
>
> >> Today I had a bit time, so I made a copy of my clipperz dir & database
> >> and took a look into the code. I got it repaired with doing two
> >> things:
>
> >> - I used the pog generator link which is mentioned in the
> >> class.user.php, to generate a new class.user.php. For the new class
> >> file i only changed type of header from TEXT to MEDIUMTEXT. I replaced
> >> the old class.user.php file with the new one.
> >> - I used phpmyadmin to change the data type of header filed (in user
> >> table) also from TEXT to MEDIUMTEXT.
>
> >> That's all!
> >> I have added some new cards. Now the content of header field is bigger
> >> as 65535 chars. And it still works.
>
> >> I did the following tests:
> >> Logout / Login: WORKS
> >> Download & Use Offline Copy: WORKS
> >> Generate, Use & Delete One Time Passwords: WORKS
> >> Delete Account: WORKS
>
> >> Also the automated table creation using /php/setup/index.php works &
> >> creates the tables like in the new style.
> >> So for new installations it looks like the only thing what is needed
> >> to exchange is the class.user.php file.
>
> >> This is link creates a new class.user.php file with MEDIUMTEXT for the
> >> header field:

> >>http://www.phpobjectgenerator.com/?language=php5.1&wrapper=pdo&pdoDri...

[Johannes W]

Hi Josh,

you can write an UPGRADE.txt file (003->004), then we can upload it to the
commutiy edition git repository and make a 004 tar.gz. Also,
INSTALL.txt would need some love (e.g. which directories are really
needed). That way, all users would be able to use the latest edition and
less duplicate bug reports would show up on the mailing list!

Greetings,
Johannes

[Hannes Balken]

Hi!

I have the same issue (clipperz community edition version 1165 on godaddy virtual server). I used it for years without problems, until last weekend: When I enter my credentials (100% ok, even OTP don't work), I get the "Login failed"-error-message, which won't close.

I immediately made a backup from both database and the files and started experimenting: Executed ALTER TABLE commands from above (still stuck), first edited class.user.php  (from TEXT to LONGTEXT) an then generated new class.user.php (again with LONGTEXT - still stuck).

Is there any hope to retrieve my passwords?

The good news is: only one account is affected. I can log in to my other, more important accounts (e.g. for financial transactions).

Hoping and waiting for a solution,

Hannes