Issue Details (XML | Word | Printable)

Key: MDL-16640
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Petr Skoda
Reporter: Garret Gengler
Votes: 0
Watchers: 1
Operations

Add/Edit UI Mockup to this issue
If you were logged in you would be able to see more operations.
Moodle

Bogus sesskey change for existing session results in lost forum posts

Created: 24/Sep/08 12:06 AM   Updated: 03/Jan/09 08:52 AM
Return to search
Component/s: Authentication, Forms Library, Forum
Affects Version/s: 1.9.2
Fix Version/s: 2.0

Issue Links:
Relates
 

Participants: Garret Gengler and Petr Skoda
Security Level: None
Affected Branches: MOODLE_19_STABLE
Fixed Branches: MOODLE_20_STABLE


 Description  « Hide
I posted about this issue on the Moodle forums, and corresponded with Petr Skoda... here's the thread:
http://moodle.org/mod/forum/discuss.php?d=105891

And here's the short summary:

Several of our users have lost forum posts when they got an "Incorrect sesskey" message. The error message is in the formslib.php... it is thrown when Moodle believes the form they are submitting was not generated for them. (I.e., sesskey in the hidden form field does not match sesskey stored in the user's session data.)

The error is happening because, for some reason, the login/index.php page is being requested by these users when they open a second browser tab or window. In Firefox, all browser windows and tabs share the same session.. and somehow the second browser ends up passing through the SSO sign-in process, and executing the code in login/index.php. You can reproduce this on any Moodle site with or without SSO, by opening a second browser window, requesting the login/php.php page yourself, and entering your username and password.

The downstream code in /login/index.php sets a random sesskey, and stores it in the session. So the users are having the sesskey changed for their existing session... and when they try to submit a forum post that they left open in the first browser window, it fails with the sesskey mismatch.

The fix is very simple:

In login/index.php, add this, around line 45 (after the auth_instructions stuff).

// check if the user is already logged in
// if so, skip the login process... otherwise we can mess up
// the existing sesskey and other session data

if (isloggedin()) {
  redirect($CFG->wwwroot.'/index.php');
}

After implementing this fix on our site, the sesskey errors have stopped. (We were previously seeing about six a day).


 All   Comments   Change History   Version Control      Sort Order: Ascending order - Click to sort in descending order
Petr Skoda added a comment - 03/Jan/09 08:52 AM
I am going to solve this in 2.0 by adding new auth callbacks and db session features...