Manual talk:SessionManager and AuthManager

Links

Where can this be linked so that extension developers and sysadmins find it? At least Manual:Developing extensions and AuthPlugin I'd say. Did you make a list of keywords to find the interested developers? Among the most popular I'd guess there are SSO/single-sign-on, login integration, authentication; none of these finds satisfactory results on mediawiki.org via search engines. Nemo 06:27, 27 May 2016 (UTC)

API

Does it change the procedure of login through API functions? --Infovarius (talk) 15:53, 16 June 2016 (UTC)

Somewhat.

If you're running a bot or other non-interactive tool, ideally you should switch to using OAuth, likely an owner-only consumer. But if you can't for some reason, you can set up a bot password and continue to use action=login as you always have. Using action=login with the "main" account password is no longer supported and might start to fail for an account without warning.

If you're maintaining an interactive app or tool, you again might use OAuth (not owner-only this time), or you might start using action=clientlogin to provide an interactive login flow.

See also previous announcements to the mailing lists, such as [1], [2], and [3], Anomie (talk) 13:44, 17 June 2016 (UTC)

Examples

I think it would be nice if we could have a list of example extensions that use different features of SessionManager/AuthManager to recommend other people look at. Legoktm (talk) 08:13, 27 October 2016 (UTC)

Feel free to add one. Off the top of my head,

• CentralAuth implements two SessionProviders, and OAuth implements one.
  • I'd hesitate to recommend CentralAuthSessionProvider as a good example, since for BC reasons it replaces core's CookieSessionProvider instead of working with it, but CentralAuthTokenSessionProvider is decent. OAuth is also good.
• AbuseFilter, AntiSpoof, ConfirmEdit, SpamBlacklist, and TitleBlacklist all implement PreAuthenticationProviders. Most are good examples of adding stuff to the login form, if only "bypass the blacklist" checkboxes.
• CentralAuth and GoogleLogin implement PrimaryAuthenticationProviders.
  • GoogleLogin is a good example of one using the "redirect to a third party" mechanism.
• Campaigns, CentralAuth, OATHAuth, and WikimediaIncubator implement SecondaryAuthenticationProviders.
  • OATHAuth is a good example of one that adds an extra step to the login process.
  • CentralAuth is an example of one that does extra validation of the user (in this case, preventing login if the user is being renamed).
  • Campaigns and WikimediaIncubator pull data out of the initial account creation form (in a somewhat hacky manner) and use it later to do things.

Anomie (talk) 13:52, 27 October 2016 (UTC)

Not obvious behavior of AuthManager and "autocreateaccount" permission

For extensions that're authenticate users using some non-persistent session storage (like external Auth or OAuth over cookies when site is permit from modifying cookies and should generate session ID based on cookies hash) and using SessionProvider for that there may be not obvious situations when account auto-creation fails after session ID was generated.

The reason of this is that your anonymous user (*) lacks createaccount and autocreateaccount rights. However, if you will grant these rights to the anonymous user group you still may experience same behavior - AuthManager rejects auto-creation for certain users.

This happens because AuthManager stores autocreation blacklist flag in session data, hence if some user was tried to be created before you've changed your anonymous users group right that "blacklist" flag will persist in Mediawiki session storage ( "objectcache" table ). To avoid such situations you need to truncate objectcache table after 'autocreateaccount' right was changed.

Hope this will help someone.