Upgrading from 3.1.7 to 3.3 with core OAuth 2 services - sessions timeout too quickly

Upgrading from 3.1.7 to 3.3 with core OAuth 2 services - sessions timeout too quickly

by Les Bell -
Number of replies: 5

Following an upgrade to 3.3, configuring the site to use the core OAuth 2 Services for Google logins results in sessions timing out in around 90 seconds or so.

Prior to upgrade: 3.1.7, with auth_googleoauth2 plugin (many users using it).

Upgraded to 3.3. My upgrade script copied across the auth/googleoauth2 directory and the site came up correctly using it. After logging in and performing various functionality tests, I went to Site Administration -> Server -> OAuth 2 Services and created a Google service. I initially copied the client ID and secret from the old plugin's configuration. I got green checkmarks for Configured, Allow login and Discovery.

Next, I went to Site Administration -> Plugins -> Authentication -> Manage authentication, enabled OAuth 2 and disabled OAuth2. I was immediately logged out, so I logged back in via the "Log in using your account on . . Google" button. As expected, I was sent an email with a link to confirm that I owned the existing account, and once I'd pasted the URL and confirmed it, I had access.

That was when the pain started. Within 90 seconds, my session expired. I couldn't even edit a short forum post before being logged out. Essentially, it is impossible to do anything before the session times out.

I have tried all the following:

* Updated Site Administration -> Server -> Session handling -> Timeout to 3 hours. (After being timed out once while doing so).

* Cleared all site-related cookies in my browser (Firefox).

* Exited the browser and restarted

* Completely rebooted the server.

* Logged in from a different machine, using Chrome rather than Firefox.

* Edited the Google API client ID - it was set up with two authorised redirect URI's:

  •     /auth/googleoauth2/google_redirect.php (for the googleoauth2 plugin)
  •     /admin/oauth2callback.php (for the new core OAuth 2 support)

and so I removed the outdated first redirect URI, rebooted server yet again and cleared cookies.

Nothing worked. Within about a minute, I start to get error messages ("web service not available", "draft could not be saved", "Could not connect to the server.", etc.) and the session times out.

I've gone back to the old googleoauth2 plugin for the time being, as most of my users prefer to authenticate via OAuth2. I've been switching back and forth between the two authentication systems by enabling and disabling the plugins and have not uninstalled the googleoauth2 plugin or deleted the auth/googleoauth2 directory and am reluctant to do so because I have many users authenticating via Google accounts.

I've read various posts here about OAuth 2 problems, but nothing has suggested a fix so far. Any suggestions are welcome!

--- Les

Average of ratings: -
In reply to Les Bell

Re: Upgrading from 3.1.7 to 3.3 with core OAuth 2 services - sessions timeout too quickly

by Les Bell -

This is getting weirder and weirder.

I got up early this morning (Sunday) with the intention of biting the bullet and uninstalling auth_googleoauth2, in case it was interfering with the core auth_oauth2 module. I carefully backed up the auth/googleoauth2 subdirectory in case i needed to put it back again quickly.

I went to Plugins -> Authentication -> Manage authentication, disabled OAuth2 (googleoauth2) and enabled OAuth 2 (oauth2). Then I went to Plugins overview, only to find there is no uninstall option for the googleoauth2 module.

"Right, you [expletive deleted], I'll fix you!", I said to myself, and I moved auth/googleoauth2 out of the way. Refreshing the Plugins overview page got Moodle to complain that the plugin could not be found on the disk, followed by an option to update the database - so I did that, and thought I'd got googleoauth2 uninstalled.

Logged out, tried to log back in using the core OAuth2 Google button and was taken to the Google account chooser, only to then get a BIG message that googleoauth2 could not be found, and no way of getting the site to load.

A few  things suggest themselves:

1. There seems to be no way to uninstall the googleoauth2 plugin - possibly because I have many users currently using it for authentication. Perhaps if that was reduced to zero it could be uninstalled? (Incidentally, I also noticed that the core OAuth2 plugin shows zero (0) users, even though I have previously logged in via it and have a row in the mdl_auth_oauth2_linked_login table - weird?)

2. Even when googleoauth2 is disabled, it is still being called/invoked or something when I try to log in. I don't know enough about OAuth2 to properly diagnose this (and I really don't want to have to buy and read OAuth2 for Dummies to do so). I know theres's a bit of JavaScript and browser redirection going in, so I suppose it's possible clearing cookies, etc. might help, but I already tried logging in from a completely different machine and that didn't help, so I suspect not.

3. There really needs to be a documented upgrade/migration process for sites that will need to move from the googleoauth2 plugin to the core OAuth2 module. As it stands, this process sucks.

--- Les

Average of ratings: -
In reply to Les Bell

Re: Upgrading from 3.1.7 to 3.3 with core OAuth 2 services - sessions timeout too quickly

by Ken Task -
Picture of Particularly helpful Moodlers

You might need to compare how the old googleoath2 did users vs how the new/built-into-core oath2 handles users.

The old used social_user_# for the user name ... # starting with 1 and increased by one each new account that used it.

One has to use direct database manipulation to 'un-install' the old plugin:

In whatever you have to browse and edit data containd in a DB (phpmyadmin/other tool?), do this query:

select * from `mdl_config_plugins` where `plugin` like "auth/googleoauth2"

That should show you 40 rows ... double check to make sure.   Remove the rows.

Then go back to the Moodle Admin UI see what moodle says about that plugin now.

The next problem ... how to convert users that had been using the old to the new.

No utility or tool to do that ... that's why I suggest trying to edit existing accounts via CVS

Here's what the new looks like

oauth2 is the auth

username is the persons google EMail address

email is of course their google EMail address

Moodle doesn't retain the password (like ldap/others)

Here's the diff:

 id,username,email,firstname,lastname

4,user@gmail.com,user@gmail.com,Ken,Task,,,,,,,,,,,,,

6,social_user_1,user@gmail.com,Ken,Task,,,,,,,,,,,,,

User 4 above is new google.

User 6 above is old google auth.

'spirit of sharing', Ken



Average of ratings: -
In reply to Ken Task

Re: Upgrading from 3.1.7 to 3.3 with core OAuth 2 services - sessions timeout too quickly

by Les Bell -

Thanks, Ken!

I've done quite a bit of probing around in the database (I'm using the command-line client), and made notes of the various tables used. I get 38 rows in that result set, and I can see that there's a lot of general info there, like the Google client ID and secret, the user prefix ("social_user_"), the last user number, etc.

I'm not going to just delete those rows right away, though, just in case - I'll copy the values and make sure I have a little script to put it all back in case everything breaks. Or I'll do a backup immediately beforehand. ;)

I wondered if maybe I would also have to set mdl_user.username to NULL where mdl_user.username like 'social_user_%' - i.e. null out the username so the old plugin seems to have no users and can therefore be uninstalled? I'd like to do a clean uninstall if I can, just to make sure the database is consistent and there's no lurking traces of the old settings pointing to the wrong configuration somehow.

It's mid-Sunday morning here now, but at least the site is stable on 3.3 with the old plugin - so I'm going to a) enjoy the sunshine and b) collect more information before making a move next weekend. With any luck, someone will post, saying, "No - I've done it, and you just have to delete all the users, uninstall the plugin, and the accounts will be relinked next time people log in" or similar.

I sure wish there was a migration script, though. . . ;)

Thanks again, Ken - you've given me some good info to follow up on.

--- Les

Average of ratings: -
In reply to Les Bell

Re: Upgrading from 3.1.7 to 3.3 with core OAuth 2 services - sessions timeout too quickly

by Ken Task -
Picture of Particularly helpful Moodlers

When one uploads the edited/built .csv file, you are not attempting to merge accounts nor change an account's ID number.   One is editing the id row changing the authentication used, the user name.   That's all.

Ref: https://docs.moodle.org/33/en/Upload_users

I had a large public school that used self-registration until they got their LDAP mess straightened out.   2 HS instances of Moodle, 1 JHS instance of Moodle, and one instance of Moodle for Elementary - all to be converted to LDAP.  

No student username,etc. was changed ... just auth column, blanked out the password - that would be looked up upon their next login.   So bjones was still bjones ... that user ID still associated with whatever the student had done in the past in any course.   The only thing changed ... the authentication method.

All I had to do was build a spreadsheet, manipulate columns, create a new sheet to use as the csv dump, checked the dump, uploaded the changes via csv.    The hard part was the spreadsheet.

If the users are already setup then the only thing to be done is getting the built in oath2 to work.

You could use just one user to test it all out.

'spirit of sharing', Ken


Average of ratings: -
In reply to Ken Task

Re: Upgrading from 3.1.7 to 3.3 with core OAuth 2 services - sessions timeout too quickly

by Les Bell -

Aahh - thanks, Ken; I hadn't picked up on what you meant by CVS/.csv. If data has to be moved between tables, I'll probably hack a bit of SQL to do it directly - I'm an old relational database hand - after backing up first.

I think it's more complex than that, though - there's still some part of the old googleoauth2 module that's still being either used or called, possibly indirectly via a URL in the database somewhere, when the googleoauth2 plugin is disabled. The new core OAuth2 module is possibly being used for the login, but then something happens around 90 seconds later and the user's session gets broken. I don't know what, though; right now I'm staring at extracts from the web server's log trying to trace the chain of events and going blind in the process.

My suspicion is that, even after I've disabled the old plugin and enabled the new one, then logged in via the new one, there's some state information being kept in the browser (or maybe at Google) that is trying to invoke the old plugin. Right now, for example, I can see a successful login via the new plugin - all the requests are for paths like /auth/oauth2 and /admin/oauth2callback.php, which is the new code - followed by an HTTP request to edit a quiz question:

"GET /classroom/question/edit.php?courseid=2&category=24 ... "

and then, just over 6 minutes (?) later, I see:

"GET /classroom/admin/auth.php?sesskey=BSNCUO2XyJ&action=enable&auth=googleoauth2 HTTP/1.1" (with a 303 response code, which is an HTTP redirect)

and 6 seconds later:

"GET /classroom/auth/googleoauth2/google_redirect.php?state=8197d14270530c94 ... "

which is a call to the old plugin's code, followed by a redirect to the site login page. Since there are no HTTP requests between those, I'm guessing that last request from my browser is the one that is causing the session to be dropped.

Anyway, I'm not going to rush into any major changes - there are people logged into the site and working right now. If I log people out while they're in the middle of a quiz I will not be popular!

And now I need to get out into the Sunday afternoon sunshine - I've had about as much OAuth2 fun as I can stand for one day. ;)

Thanks, Ken!

--- Les

Average of ratings: -