Last modified: 2011-04-14 15:10:52 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.
*** This bug has been marked as a duplicate of bug 17077 ***
(In reply to comment #1) > > *** This bug has been marked as a duplicate of bug 17077 *** > Oops, guess it's not
Created attachment 5776 [details] Hook code.
Created attachment 5777 [details] Debug file for failed attempt.
Created attachment 5778 [details] Debug code for successful attempt.
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.
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.
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.
Not really sure what's going on here (adding +testme). Definitely not an issue with installation, so resetting to General/Unknown.