$wgAuth is deprecated in 1.27

[jdarwood007]

https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager

While working on #10 I was informed $wgAuth is deprecated and should be replaced by AuthManager Plugin system.

https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager

This will greatly change how we handle auth. Looking at it, we would be using SessionManager to validate the login and then tell MW what to do (login, create user, etc). We also will need to build this as the plugin system.
The GoogleLogin plugin uses this. As does IPBLoginAuth

Would like to find more plugins to use for researching on how others are handling this.

[tazinator]

https://www.mediawiki.org/wiki/Extension:GoogleLogin/PostAuthManager

Might be of assistance there. Seems thats using AuthManager.

[Vekseid]

https://github.com/Vekseid/ForumSessionProvider

I wrote this for SMF and Elkarte both as I'm preparing for conversion. It should work with SMF 2.1 out of the box.

[jdarwood007]

Looking into this the base that @Vekseid provided is the right direction for the future. Some of the errors would be easy to solve, but MediaWiki has decided to overload session_start(), which creates another set of issues. PHP 7.2 also made this more difficult to do as well and prevents us from calling session_start again and complicates this more.

Since you can't interact with SMF's session data. This prevents the auth plugin from issuing old_url to the session. Which means PHP and MediaWiki have just made this impossible to do securely since the only other way to do this is to insecurely send the return url in the request.

Thats about as much as I looked into it. I couldn't see a way to get into the SMF session to inject the old_url.

This most likely means we need to implant a system in 2.1 which can allow the auth system to issue redirects in the safest way. Only way I can see doing that is a trusted domains list, which means a attacker could still issue a attack to a url you controlled, but not outside your site. This also means it would be possible for a attack to occur by a blind redirect attack. Need more time to think up a solution.

[Vekseid]

@jdarwood007 is that what was going on.

I think, a better solution would be, if SMF gets hit on the logout url without valid session tokens backing it up, just confirm it with the user.

[jdarwood007]

Logout it makes sense for us to allow a confirmation page to confirm logouts. This is easily setup.
I have an idea of what we can do for the redirects. Will work on a solution for 2.1 and somebody can backport it to 2.0 if desired.