UI > personEdit > Bug (done?)

New users can't edit their own profile / #3817

MoveBookmark

Summary

done?
Jan 16, 2007
100%
Jan 17, 2007 / ganesh
Feb 5, 2007 / pixtur
View previous 4 versions
ganesh
 

Attached files

No files uploaded

Issue report

Minor
Have not tried
Linux
v0.711
  1. Create a new user with login
  2. Wait for notification mail to arrive
  3. Click on the "Please set a password to activate it." link in the mail
  4. Set a new a password and click "Submit"
Operation will abort with the following message: "Item has been modified during your editing by Unknown (1 minutes ago). Your changes can not be submitted." The new user is effectively forbidden to update his own profile.
Operation should succeed
Replace line

from db/db_item.inc.php, line 1451

if($this->modified_by != $auth->cur_user->id) {
with

from db/db_item.inc.php

if($this->modified_by != $auth->cur_user->id && $this->modified_by != FINIT_CUR_USER) {
 

7 Comments

pixtur

Jan 17, 2007
confirmed...
Can you commit the suggested code?

ganesh

Jan 17, 2007
View comment
I debugged a little more and I found that there may be a better fix. In fact the modified_by is initally set to FINIT_CUR_USER when creating the user, but it should be replaced with the correct id in DbItem::__construct. Appartently that doesn't happen, probably because the test on $auth->cur_user fails. I'll check it again this evening.

ganesh

Jan 18, 2007
View comment
Found a different, hopefully better, fix. It seems that function setCurUserByIdentifier() called from index.php is not enough to make DbItem::__construct replace FINIT_CUR_USER with the correct user id. Calling setCurUserByIdentifier() a second time inside function personEditSubmit() seems to fix everything. I got the idea from function activateAccount() which also include an apparent redundant call to setCurUserByIdentifier().

pixtur

Jan 18, 2007
oh... interessting...
I can reproduce the bug and tried to figure out your suggestions. This is indeed a very weird problem.
The weird thing is, that FINIT_CUR_USER is a string which cannot be stored in field 'modified_by'. Actually the field appears to be set correctly and stored correctly in the database.

Could it be, that this is a time problem?

tom

ganesh

Jan 19, 2007
version 2
Reply to oh... interessting...
I don't think it's a time problem. As far as I understood, the bug occurs because:
  1. the dbitem of the person somehow appears to be modified after the user submits the profile change request but before processing the request itself (why this happens, I don't know);
  2. while processing such misterious modification, the flow enters DbItem::__construct and tries to replace FINIT_CUR_USER with the current user id. Unfortunately, the $auth context is not properly set at that time, so the test if($auth->cur_user) fails and the dummy value is not replaced;
  3. while processing the actual profile change request, the flow enters validateEditRequestTime and we have $edit_request_time < $last_modified because of 1. and $auth->cur_user->id == FINIT_CUR_USER because of 2.;
  4. the test $this->modified_by != $auth->cur_user->idfails (because $auth->cur_user->id contains a proper user id) and the operation aborts.
With my fix, the $auth context gets properly set before entering DbItem::__construct, so the modification appears to be made by the current user and validateEditRequestTime won't complain even if the time of the misterious modification appears to be later than the time of the request.
It took me almost three hours to get it... ;-)

pixtur

Jan 19, 2007
thanks for your help...
Some of the aspects of editing the current user are really hard to track. Could you add a small comment to your fixed code, which points to this Ticket?

I am good at remove bad memory, and I stumble over this code somewhere in the future, a quick reminder could help :)


ganesh

Jan 19, 2007
Reply to thanks for your help...
Eheh... I already did it! I too find these kind of remainders most useful!
 
 

Comment / Update