Last modified: 2011-04-14 15:10:52 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T19339, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 17339 - User group changes not effective when using UserLoadFromSession hook
User group changes not effective when using UserLoadFromSession hook
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.13.x
Other Solaris
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
http://(internal)
: testme
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-03 15:11 UTC by Sam Sexton
Modified: 2011-04-14 15:10 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Hook code. (8.25 KB, text/x-php)
2009-02-03 15:15 UTC, Sam Sexton
Details
Debug file for failed attempt. (4.48 KB, text/plain)
2009-02-03 15:15 UTC, Sam Sexton
Details
Debug code for successful attempt. (8.55 KB, text/plain)
2009-02-03 15:16 UTC, Sam Sexton
Details

Description Sam Sexton 2009-02-03 15:11:59 UTC
MediaWiki  1.13.0
PHP 	     5.2.6 (apache2handler)
MySQL 	   5.0.67-log

Warning - you are about to enter the world of X Files!

I have implemented the UserLoadFromSession hook (UserAuthTGST.php code attached) to authenticate the user via our SSO. It was quite a battle (see bug 17077) but I thought I'd finally sorted it. Apparently not - strap yourself in! I have two IDs - SS (created in the standard way) and Sam.Sexton (created using the hook). 

When, as SS, I gave Sam.Sexton sysop and bureaucrat access, the latter could see the restricted pages in Special Pages. However, when I granted someone group membership via the User rights management page, instead of clearing the group list etc., the page refreshed showing the boxes I'd ticked as empty.

I did some research and updated the hook so that it called User->loadFromId() rather than loadFromDatabase(), as the former manages the cache. That was successful, but it made no effective difference. I have turned on SQL debugging and can see where the successful and failing paths diverge.

Before I show you those, the problem disappeared for Sam.Sexton after I commented out the hook definition in LocalSettings, logged in as SS and then reversed that process - it all works fine for Sam.Sexton now but the problem persists with users to whom I have granted admin rights.

Here is the indication of the successful call to loadFromId() from my own logging file:

2009-02-03 13:48:23 Page: /d3wiki/index.php/Special:UserRights
2009-02-03 13:48:23 TGSTWiki cookie found
2009-02-03 13:48:23 Entering UserAuthTGST::loadFromDatabaseTGST ...
2009-02-03 13:48:23 Cookie exploded: 8001532, Kxxx.Bxxx@mydomain.com, Kxxx, Bxxx
2009-02-03 13:48:23 DB entry found for employee id 8001532 with user id 133 and name Kxxx.Bxxx
2009-02-03 13:48:23 loadFromId succeeded for user ID 133 and name Kxxx.Bxxx

From Special:Listusers:

Kxxx.Bxxx ?(bureaucrat, nsD3PRIVRW, nsD3PRIV_TalkRW, sysop)

Here are extracts from the debug log for (firstly) a failed attempt by KB to give GB nsD3PRIVRW membership. The full logs are in the attachement.

Start request
POST /d3wiki/index.php/Special:UserRights
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.46 Safari/525.19

...

Connecting to localhost wikidbD3...
SQL: SET /* Database::open  */ NAMES utf8
SQL: SET /* Database::open  */ sql_mode = ''
Connected
...
SQL: SELECT /* User::loadFromDatabase Kxxx.Bxxx */  *  FROM `d3_user`  WHERE user_id = '968'  LIMIT 1  
SQL: SELECT /* User::loadGroups Kxxx.Bxxx */  ug_group  FROM `d3_user_groups`  WHERE ug_user = '968'  

# This is where the paths diverge ....

SQL: SELECT /* Parser::replaceLinkHolders Kxxx.Bxxx */ page_id, page_namespace, page_title, page_is_redirect, page_len FROM `d3_page` WHERE (page_namespace=2 AND page_title IN('Gxxx.Bxxx')) OR (page_namespace=3 AND page_title IN('Gxxx.Bxxx'))
SQL: SELECT /* IndexPager::reallyDoQuery (LogPager) Kxxx.Bxxx */  log_type,log_action,log_user,log_namespace,log_title,log_params,log_comment,log_id,log_deleted,log_timestamp,user_name,user_editcount  FROM `d3_logging` FORCE INDEX (page_time,user_time),`d3_user`   WHERE (log_type != 'suppress') AND log_type = 'rights' AND log_namespace = '2' AND log_title = 'Gxxx.Bxxx' AND (user_id = log_user)  ORDER BY log_timestamp DESC LIMIT 51  
SQL: SELECT /* Job::pop Kxxx.Bxxx */  *  FROM `d3_job`  WHERE job_id >= 0  ORDER BY job_id LIMIT 1  
SQL: COMMIT
SQL: BEGIN
SQL: SELECT /* LinkBatch::doQuery Kxxx.Bxxx */ page_id, page_namespace, page_title, page_len, page_is_redirect FROM `d3_page` WHERE (page_namespace=2 AND page_title='Kxxx.Bxxx') OR (page_namespace=3 AND page_title='Kxxx.Bxxx')
SQL: SELECT /* User::checkNewtalk Kxxx.Bxxx */  user_id  FROM `d3_user_newtalk`  WHERE user_id = '133'  LIMIT 1  
OutputPage::sendCacheControl: private caching;  **
Request ended normally

and here's a successful one for Sam.Sexton adding the same permission:

Start request
POST /d3wiki/index.php/Special:UserRights
Host: d3wiki.nott.ime.mydomain.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
...
Connecting to localhost wikidbD3...
SQL: SET /* Database::open  */ NAMES utf8
SQL: SET /* Database::open  */ sql_mode = ''
Connected
...
SQL: SELECT /* User::loadFromDatabase Sam.Sexton */  *  FROM `d3_user`  WHERE user_id = '968'  LIMIT 1  
SQL: SELECT /* User::loadGroups Sam.Sexton */  ug_group  FROM `d3_user_groups`  WHERE ug_user = '968'  

# This is where the paths diverge ....

SQL: DELETE /* User::removeGroup Sam.Sexton */ FROM `d3_user_groups` WHERE ug_user = '968' AND ug_group = 'bot'
SQL: UPDATE /* User::invalidateCache Sam.Sexton */  `d3_user` SET user_touched = '20090203143753' WHERE user_id = '968'
SQL: DELETE /* User::removeGroup Sam.Sexton */ FROM `d3_user_groups` WHERE ug_user = '968' AND ug_group = 'sysop'
SQL: UPDATE /* User::invalidateCache Sam.Sexton */  `d3_user` SET user_touched = '20090203143753' WHERE user_id = '968'
SQL: DELETE /* User::removeGroup Sam.Sexton */ FROM `d3_user_groups` WHERE ug_user = '968' AND ug_group = 'bureaucrat'
...
oldGroups: Array
(
)
newGroups: Array
(
    [0] => nsD3PRIVRW
)
SQL: INSERT /* LogPage::saveContent Sam.Sexton */  INTO `d3_logging` (log_id,log_type,log_action,log_timestamp,log_user,log_namespace,log_title,log_comment,log_params) VALUES (NULL,'rights','rights','20090203143748','3','2','Gxxx.Bxxx','','\nnsD3PRIVRW')

... and on to sweet success ...

I've pored over User.php to see if there's something I'm missing, but if so, I can't find it.
This has (I'm convinced!) to be something I'm not doing correctly in the hook, but there was no sample code, so I had to migrate the old code (hacked into User.php for 1.8.2 by a departed colleague) into the hook. I've provided the code I ended up with in the talk page for the hook at http://www.mediawiki.org/wiki/Manual_talk:Hooks/UserLoadFromSession and will update that when this is sorted.

Many thanks in advance for any advice.
Comment 1 Roan Kattouw 2009-02-03 15:13:10 UTC

*** This bug has been marked as a duplicate of bug 17077 ***
Comment 2 Roan Kattouw 2009-02-03 15:15:05 UTC
(In reply to comment #1)
> 
> *** This bug has been marked as a duplicate of bug 17077 ***
> 

Oops, guess it's not
Comment 3 Sam Sexton 2009-02-03 15:15:15 UTC
Created attachment 5776 [details]
Hook code.
Comment 4 Sam Sexton 2009-02-03 15:15:56 UTC
Created attachment 5777 [details]
Debug file for failed attempt.
Comment 5 Sam Sexton 2009-02-03 15:16:21 UTC
Created attachment 5778 [details]
Debug code for successful attempt.
Comment 6 Sam Sexton 2009-02-03 15:23:21 UTC
Well spotted Roan! I thought I'd set the severity to "blocker" as that's precisely what it is, but I'll leave it as it is for now in case you changed it.
Comment 7 Sam Sexton 2009-02-04 15:50:26 UTC
I've been poring over this again today (in between going out and getting fresh bandages for my head!) and have some trusses of what was happening in the good and bad scenarios - there was a lot of SemanticMediaWiki gorp in the bad truss - I have no idea why it's there, but I disabled it and that made no difference - which is good, really.

Anyway, what I have noticed is that in the debug log for failure, I see:

User::matchEditToken: broken session data

but that's not in the debug for the successful attempt, so this HAS to be significant, doesn't it? I'm going to go look at the code, but if some kind soul who is more familiar than I with this code (that's not hard!) could tell me how to fix that, I would be eternally grateful. Thanks in advance.
Comment 8 Sam Sexton 2009-02-04 16:22:27 UTC
OK - I think I'm nearly there - it looks as if I need to call setToken (in User) somewhere in my hook - something like that. Unfortunately I have to dash, so now that we're down to the wire, I'd be grateful if someone could push me over the line - and I'll update the sample code once it's sorted. 
Comment 9 Chad H. 2010-08-08 16:37:50 UTC
Not really sure what's going on here (adding +testme). Definitely not an issue with installation, so resetting to General/Unknown.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links