Talk:BOINC Authentication
From Pirates@Home
I welcome any member of the Pirates@Home crew to work on the text of the introduction. This page is being prepared for the MediaWiki site, and they may not know much about BOINC (or care). But it would also be nice to have a copy on the Unofficial BOINC wiki, hence a section of introduction about MediaWiki. We'll remove the section which doesn't fit when the page is uploaded to one or the other.
I'll flesh in the technical details, but another set of eyes never hurts on the rest of it as well, should you be so inclined. (And if so, thanks in advance.)
--Wormholio 10:33, 31 January 2007 (EST)
Contents |
Notes on Work in Progress
I'm also using this talk page as a place to keep notes as I work on the known problems.
BOINC status changes applied immediately
If a user's status changes on the BOINC project, such as having RAC drop below a threshold required for editing or being banned from the forums, the changes that would follow from this on the wiki were only being made if the user logs out and logs back in again. Once they have a session going and are logged in to the wiki we didn't check their credentials again.
I don't want to go through the bother of checking authentication each time a page is requested, as it would be a lot of overhead for a rare occurence.
The best way to deal with this now looks to be to set the 'user_touched' item in the user database on the wiki to a timestamp, and then maintain another timestamp in the session. If the user has been touched more recently than the session timestamp indicates, then recheck their credentials). This is a quick way to signal this without a lot of overhead. Most of the time there is no need to do further review, and the page is served quickly.
I think I have this working on the wiki side, though it may need tweaking.
On the BOINC side I have to arrange to insert this user_touched timestamp into the wiki user table. For example, when a user is banned (thrown in the brig on Pirates@Home) then insert this timestamp at that point. The next time they request a page it will trigger a review of their credentials and there will be a change (they get put in the 'brig' group on Pirates@Home).
For changes in credit or RAC the best place to do this would probably be in the nightly task which expires RAC, or some nightly task which looks for users who likely need their credentials checked again.
When the user's credentials are checked the timestamps in both the user table and the session are set together and hence further connections go through quickly since they no longer need to be reviewed.
I now just need to implement the BOINC side to test this. The brig part is easiest so that will be first.
Note to self: the wiki does not use Unix timestamps, it uses YYYYMMDDHHMMSS format.
--Wormholio 09:45, 4 February 2007 (EST)
We also check credentials if the session timestamp is missing. That would happen, for example, if the PHP session ended. But we could also check credentials if the session timestamp is over an hour old, just to be sure we check occasionally.
--Wormholio 11:09, 5 February 2007 (EST)
We now re-check user status after an hour (configurable), in case something has changed (RAC dropped, out of the brig) for which we should change their permission group membership. I have a function for BOINC called touch_wiki_user($user) which updates the timestamp. I'll submit that to Rytis, but after this plug-in has been released. And/or it can go in the tweaks section.
--Wormholio 10:08, 3 March 2007 (EST)
Login Required
In OutputPage.php in the function loginToUse() I'm trying to short circuit the page by creating a redirect link. I've set up a 'hook' to run my own function, which then redirects the user to the BOINC login page, with the final destination set in the url as what follows ?next_url=.
This is working, except that after I do log in correctly I am redirected to the same login page again, even though I'm already logged in. If I authenticate again, or even if I click on "glossary", then I'm in the glossary (I turn off anonymous reading to test this).
Since the main page on the Pirates@Home wiki has a ' in the title I had to modify the BOINC code to translate this in $next_url into %27. I need to forward that change to Rytis. But I'll save it for a collective report of what's needed to make the wiki work. So far there is not much.
--Wormholio 09:45, 4 February 2007 (EST)
Rather than using the existing BOINC login_form.php I found it useful to create a new file, login_required.php. It's similar, but invokes the full login form and thus gives the user the message "you must login to do that".
Still being refered back to that page after I log in. Perhaps still a problem with placement of the hook?
--Wormholio 09:47, 4 February 2007 (EST)
The problem is likely the placement of the hook. If I am logged out and I log in normally (not trying to access the wiki) and then later I try to access the wiki I get redirected to the new login required page. But even if I don't log in then following the "glossary" link again works fine. Something is out of order.
--Wormholio 09:56, 4 February 2007 (EST)
I placed the hook immediately after the check that the user is already authenticated, and now it seems to work.
--Wormholio 07:47, 23 February 2007 (EST)
There are two other places that one needs to make adjustments to intercept jumps to the wiki's normal login page [[Special:UserLogin]]
- system messages: there are about 8 of them which have links to the userlogin page
- The page itself. You can redirect to the BOINC login page instead.
In fact, if you deal with #2 then you don't really have to worry about #1, since those links will then get you to the right place.
--Wormholio 07:47, 23 February 2007 (EST)
While I had been redirecting a separate file in BOINC called login_required.php, I've now found it more useful to modify login_form.php to handle both cases, and when I have this general enough I'll submit a patch to Rytis. So I need to change the link back to login_form.php.
--Wormholio 10:03, 3 March 2007 (EST)
Notes on further customizations and tweaks
Disable e-mail input field
We don't want users to be given an input field for their e-mail address on the preferences page, since their e-mail address is copied over from BOINC. To disable this edit SpecialPreferences.php, find the input field for wpUserEmail (around line 565) and disable that section. It should then look something like
if ( 0 && $wgEnableEmail ) {
$wgOut->addHTML(
$this->addRow(
'<label for="wpUserEmail">' . wfMsg( 'youremail' ) . '</lab$
"<input type='text' name='wpUserEmail' id='wpUserEmail' val$
)
);
}
It might be useful to create a method for $wgAuth to check for this, or a global setting $wgAllowEmailChange. That's something to discuss with the MediaWiki developers.
--Wormholio 09:52, 3 March 2007 (EST)
