Vot urody!

3 views
Skip to first unread message

alexey...@gmail.com

unread,
Aug 27, 2008, 5:29:07 AM8/27/08
to Clipperz
If you have an account, everyone can delete your information by
account creating!

This happen with me....

Very fun! Thanks a lot!

P.S.: tested - it work
username - tast
passphrase - passphrasepassphrasepassphrase

Giulio Cesare Solaroli

unread,
Aug 27, 2008, 5:41:56 AM8/27/08
to alexey...@gmail.com, Clipperz
Hello Alexey,

is this happening on the Community Edition, or on the live version?

Giulio Cesare

alexey...@gmail.com

unread,
Aug 27, 2008, 5:54:36 AM8/27/08
to Clipperz
it's about online version

Giulio Cesare Solaroli

unread,
Aug 27, 2008, 6:00:59 AM8/27/08
to alexey...@gmail.com, Clipperz
Ok. It sound very strange, but I will double check it as what you are
reporting sounds quite scaring.

Thanks for the update.

Best regards,

Giulio Cesare


On Wed, Aug 27, 2008 at 11:54 AM, <alexey...@gmail.com> wrote:
>
> it's about online version
> >
>

aka...@gmail.com

unread,
Aug 27, 2008, 7:36:02 AM8/27/08
to Clipperz
so? any results?

Giulio Cesare Solaroli

unread,
Aug 27, 2008, 8:35:38 AM8/27/08
to alexey...@gmail.com, aka...@gmail.com, Clipperz
I have done some tests on my development environment, and this are the findings:

- if you try to register with a username/passphrase that already
exist, you get an error (and we know since long ago that we should try
to handle this kind of errors more politely, but being quite rare we
did not put too much effort into fixing it);
- if you try to login using the same username/passphrase after a
failed registration, you get a failed login.

In my test environment, simply restarting the server fixed the problem
immediately.

This probably means that the application is triggered into an
inconsistent state, that does not allow the user to login again. But
no actual data is lost.

In order to be able to login again, you probably need to wait until
the server side session is expired (or the application restarted for
other reasons, but this is quite rare, as the online application has
some venerable uptimes - current uptime is almost 42 days).

So, unless you are seeing something completely different from what I
am seeing, I would consider this a minor bug with very little options
to actually be triggered.

Does this match your findings?

Best regards,

Giulio Cesare

On Wed, Aug 27, 2008 at 1:36 PM, <aka...@gmail.com> wrote:
>
> so? any results?
> >
>

Marco Fabbri

unread,
Aug 27, 2008, 8:42:58 AM8/27/08
to Clipperz

I reproduced the bug on the Community Edition. Being the CE, I could
take a look at the whole picture (code, database, communication between
the client and the server) and I have seen that:

1. original user account data doesn't get deleted;
2. duplicate user accounts (with different uids but same username) are
created;
3. the problem is into the POST on index.php with METHOD:registration,
here (index.php line:231) you have:

switch($method) {
case "registration":
$message = $parameters["message"];

if ($message == "completeRegistration") {
$user = new user();

updateUserCredentials($parameters["credentials"], $user);
updateUserData($parameters["user"],
$user);
$user->Save();

$result["lock"] = $user->lock;
$result["result"] = "done";
}
break;

no control is in place to check if the username does yet exists.

--
Marco

=====
"We know nothing
— that is the first point.
Therefore we should be very modest
— that is the second.
That we should not claim to know when we do not know
— that is the third."

Karl R. Popper

Giulio Cesare Solaroli

unread,
Aug 27, 2008, 9:00:06 AM8/27/08
to mrfa...@gmail.com, Clipperz
Marco,

thanks for the check on the community edition software.

I am completely positive that the second record is not created on the
online version, as an unique index is present on the "username"
columns on the user table (the online version uses a PostgreSQL DB
instead of MySQL).

So the code lacks a check, but the DB is definitely not being
corrupted by its absence.

Thanks for your effort.

Best regards,

Giulio Cesare

alexey...@gmail.com

unread,
Aug 27, 2008, 9:31:58 AM8/27/08
to Clipperz
Just try to create the account with username "test". (I created it
already)

And look at this - http://fotki.yandex.ru/users/m89263262898/tags/clipperz
And please repeat it

(Use another pass! different from me and different from the first
time)


On Aug 27, 5:00 pm, "Giulio Cesare Solaroli" <giulio.ces...@gmail.com>
wrote:
> Marco,
>
> thanks for the check on the community edition software.
>
> I am completely positive that the second record is not created on the
> online version, as an unique index is present on the "username"
> columns on the user table (the online version uses a PostgreSQL DB
> instead of MySQL).
>
> So the code lacks a check, but the DB is definitely not being
> corrupted by its absence.
>
> Thanks for your effort.
>
> Best regards,
>
> Giulio Cesare
>
> On Wed, Aug 27, 2008 at 2:42 PM, Marco Fabbri <mrfab...@gmail.com> wrote:

Giulio Cesare Solaroli

unread,
Aug 27, 2008, 9:46:11 AM8/27/08
to alexey...@gmail.com, Clipperz
Alexey,

the only thing I have done differently in my test, is that I didn't do
the logout.

I will try again doing also the logout.

Thanks,

Giulio Cesare

Giulio Cesare Solaroli

unread,
Aug 27, 2008, 10:01:37 AM8/27/08
to alexey...@gmail.com, Clipperz
Alexey,

now I see the __real__ difference between your test and mine: you
changed the password!!!!

So what you are seeing is just the expected behaviour.

What you are seing is not the same user with all data deleted, but
just a brand new user altogether. You may try and log back in with the
initial username/passphrase, and you will find all your content just
as you left it.

Clipperz wise, the "username" is a composite value of both the real
username and passphrase.

This means that you can have multiple users using the same real
username, as long as they have different passwords.

This was a side effect on the choice we made early on the design of
the system, to know nothing about our users: not even the username!

Hope this makes the situation clear enough.

Regards,

alexey...@gmail.com

unread,
Aug 27, 2008, 10:34:32 AM8/27/08
to Clipperz
well

"I am completely positive that the second record is not created on the
online version, as an unique index is present on the "username"
columns on the user table (the online version uses a PostgreSQL DB
instead of MySQL). "

I suppose so too - it is a general practice

otherwise... it well enough. Thanks.

On 27 авг, 18:01, "Giulio Cesare Solaroli" <giulio.ces...@gmail.com>
wrote:
> Alexey,
>
> now I see the __real__ difference between your test and mine: you
> changed the password!!!!
>
> So what you are seeing is just the expected behaviour.
>
> What you are seing is not the same user with all data deleted, but
> just a brand new user altogether. You may try and log back in with the
> initial username/passphrase, and you will find all your content just
> as you left it.
>
> Clipperz wise, the "username" is a composite value of both the real
> username and passphrase.
>
> This means that you can have multiple users using the same real
> username, as long as they have different passwords.
>
> This was a side effect on the choice we made early on the design of
> the system, to know nothing about our users: not even the username!
>
> Hope this makes the situation clear enough.
>
> Regards,
>
> Giulio Cesare
>
> > On Wed, Aug 27, 2008 at 3:31 PM, <alexey.po...@gmail.com> wrote:
>
> >> Just try to create the account with username "test". (I created it
> >> already)
>
> >> And look at this -http://fotki.yandex.ru/users/m89263262898/tags/clipperz
> >>> > -- that is the first point.
> >>> > Therefore we should be very modest
> >>> > -- that is the second.
> >>> > That we should not claim to know when we do not know
> >>> > -- that is the third."
>
> >>> > Karl R. Popper
Reply all
Reply to author
Forward
0 new messages