Page MenuHomePhabricator

username only handled on protected pages
Open, Needs TriagePublic

Description

I'm not sure if this is a bug or simply lack of understanding of how this extension works on my parts. I am trying to upgrade from an older generation of this extension and mediawiki (pre-1.27) that worked well with the REMOTE_USER/REMOTE_USER_DATA variables set by single-signon. However, I am having a hard time getting the current version of Auth_remoteuser working with mediawiki-1.31.0 to enable public wikis that require logins only for editing and admin functions. The setup I have consists of the same Special:UserLogin redirect to a SSO-protected Authentication page that seems to work fine as I see my user logged in on that particular page when I use a closure recommended by the Auth_remoteuser documentation shown below. However, the moment I navigate away from a SSO-protected page I see 'Log In' navigational link and cannot edit pages or perform any logged-in functions even though a review of cookies shows that there is a valid session and the correct username is stored in other relevant cookies. Here's my LocalSettings.php configuration pertitent to Auth_remoteuser:

wfLoadExtension( 'Auth_remoteuser' );
$wgSessionName = 'wikidb_main_session';
$wgAuthRemoteuserRemoveAuthPagesAndLinks = true;                                                          
$wgSessionsInObjectCache = true;

$wgAuthRemoteuserUserName = function() {
      if ( isset ($_SERVER['REMOTE_USER_DATA']) ){
          $credentials = explode( ':',$_SERVER['REMOTE_USER_DATA']);
          $username = ucfirst($credentials[0]);
          return $username ? $username : null;
      }
  };

Of course, on all non-protected pages the $_SERVER['REMOTE_USER_DATA'] is not set, so the user is considered logged-out, which is not the behavior I would expect from Auth_remoteuser.

Fully private wikis work well with Auth_remoteuser as REMOTE_USER and REMOTE_USER_DATA are set by the webserver for every URI.

Thank you,

Alex

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 26 2018, 5:10 PM

More testing by selectively adding SSO coverage to other URIs showed the same pattern, so there is a clear distinction between pages behind SSO, which show user as logged in, and pages not behind SSO, which show the user as anonymous user and present a 'Log In' URI in the upper right corner of the interface.

Enst80 claimed this task.Jul 26 2018, 9:52 PM

If $_SERVER['REMOTE_USER_DATA'] is not set, then Auth_remoteuser won't do anything, even if there are cookies present with valid session and user information.

Auth_remoteuser needs the parameter $wgAuthRemoteuserUserName to be set to even get to the point of evaluating cookies. That means, yes, it is true that the user is not logged in on your non-protected pages. Or in other words, you have to provide a non empty $wgAuthRemoteuserUserName for every protected page/action, not just for the Special:UserLogin page.

If it really worked this way (like you described) in Auth_remoteuser prior 2.0.0, than we have to patch the current version accordingly to get it working again. I'll prepare a patch after having thought about the security implications of trusting cookie data without a matching remote source identifier ^^...

Thanks for taking the task Stefan. I can tarball the old Auth_remoteuser extension code I have if needed to show that it works. Logically, it seems that this is how the current Auth_remoteuser should work as well i.e. since a user gets logged in via Special:UserLogin, which is behind SSO, and a mediawiki session is created I would expect the user to stay logged in until explicitly logged out or until a session timeout without Auth_remoteuser overriding the login status to none on pages that are not explicitly protected by SSO or it becomes impossible to edit pages or perform admin functions. Again, thank you for taking a look!

No sure if this is on-topic or not, but can anyone say that this extension has been thoroughly tested to work with configurations that rely on an immutable session from a SSO source? Specifically with respect to the way Auth_RU handles cookies during session revalidation from the SSO. If I understand correctly, using Auth_RU as a pure session handler for immutable sessions via an SSO is a (currently) rare use case. Can anyone say that Auth_RU is tested for this use-case? (My apologies if this is the wrong place to ask this question)

Enst80 added a comment.Aug 7 2018, 7:28 AM

@OMoskalenko Just an interim report. I'm working on a solution, but due to beeing really busy lately and my upcoming holiday, it will take more time (some weeks). In the meanwhile if you are in urgent need of a solution, you can take this prerelease branch of my private github repository: github.com:enst80:mediawiki-extensions-Auth_remoteuser:T200451 . It represents an early state, but should be usable. It accepts session cookies, when the new configuration option $wgAuthRemoteuserTrustSessionCookie = true; is set (and deletes the cookie if set to false an no remote user name validates this cookie).

+++++

@Revansx

...Specifically with respect to the way Auth_RU handles cookies during session revalidation...

Regarding that aspect: Auth_remoteuser doesn't really do anything on his own. It relies completely on the default CookieSessionProvider of which it is derived from. But there's one catch, session information from cookies is not trusted, therefore the SessionManager will renew the session at each request. (A user can forge arbitrary cookies.) A real immutable session provider would set the idIsSafe property of the SessionInfo object accordingly to reuse the same session. (I'm thinking about this currently and there's perhaps still something to overhaul in the current source ... I think of trusting the cookie session data if the cookie user names equals the remote user name AND the session user name ... )
If you have such a specific use case with unexpected behavior of the authentication/session revalidation process, than please open another phabricator task, where we can follow the process of finding a suitable solution. (Please don't expect a solution to fast, i'm mostly offline for the next few weeks due to holidays ;-) )

Thank you for a prompt response. The experimental branch seems to be working for logins. I wonder if the logout link still needs to be enabled to clear the session cookie / log user out of mediawiki until they go back to a protected page that will trigger authentication.

Enjoy your vacation!

Regards,

Alex