[RFC] Auth Plugin Refactoring & User Integration

[Oleg]

This RFC should probably include a list of authentication providers that the changes are going to be tested with/targeting.

[Hardolaf]

OpenID, Facebook, Google are the popular providers I can think of that I've used.

[naderman]

You probably trust Google to provide you with a working email address

I do not. Lots of bots managed to bypass user activation with Gmail addresses. Hard to believe but it happened to me.

Sure, but the gmail address they have is still valid. And if they bypassed that, they can bypass email activation too. So no additional safety from bots through email activation in this case.

[naderman]

So far, are there any plans regarding the user interface for all of this yet? What will the user interface for logging in, signing up or connecting your account to multiple providers look like?

[ecwpa]

Sure, but the gmail address they have is still valid. And if they bypassed that, they can bypass email activation too. So no additional safety from bots through email activation in this case.

If phpBB ended up doing it like this, this won't affect boards with manual activation by administrators, right?

[Hardolaf]

If phpBB ended up doing it like this, this won't affect boards with manual activation by administrators, right?

It will still support manual activation by administrators as I plan to implement it.

So far, are there any plans regarding the user interface for all of this yet? What will the user interface for logging in, signing up or connecting your account to multiple providers look like?

I added some mock-ups to the main post. If you want any more, I can make more up.

[AmigoJack]

BUG: Changing Auth type breaks UCP change email or username (and as a result ticket PHPBB3-10870) comes with an additional aspect: if the user changes his username or e-mail-address he needs to type in his password. If a (current) non-DB auth plugin is used there is no chance that a user can do this, as the entered password is compared with the one being hashed by phpBB and stored in the DB - and not the one which the auth plugin would refer to.

Reading this RFC makes me wonder if checking the passwords should move from phpBB's core to the auth plugin, or if it should stay where it is, where it gets augmented by checking if the auth plugin provides a function/method for comparing passwords (and if not, the core is used).

[naderman]

BUG: Changing Auth type breaks UCP change email or username (and as a result ticket PHPBB3-10870) comes with an additional aspect: if the user changes his username or e-mail-address he needs to type in his password. If a (current) non-DB auth plugin is used there is no chance that a user can do this, as the entered password is compared with the one being hashed by phpBB and stored in the DB - and not the one which the auth plugin would refer to.

Reading this RFC makes me wonder if checking the passwords should move from phpBB's core to the auth plugin, or if it should stay where it is, where it gets augmented by checking if the auth plugin provides a function/method for comparing passwords (and if not, the core is used).

Indeed these authentication related settings in the UCP need to become part of the auth plugins, so that they can be switched out or altered for other plugins.

Some statistical info from the data users can send us through the ACP (this is based only on reports from last year, unique entries for each forum, and > 2 registered users):

There were 81 different authentication plugins reported (3 of these: db, apache, ldap ship with phpBB). So having a backward compatible interface to the new plugins will be most useful.

There were 12 auth plugins that based on the name are most likely identical to the db plugin, but use a different password mechanism to be compatible with another forum software that the board was converted from (e.g. smf, vb3, ipb). This suggests that we should offer more different password hashing mechanisms by default which are simply chosen through a prefix in the password column. That way these converters could simply prefix all passwords in the phpbb user table and have it work automatically without the need for a custom auth plugin.

In total, 1693 out of 34638 forums (4.88%) matching the above criteria, are using an auth mechanism that is not the default "db". Apache is only used by 7 installations, but this was always meant more of an example than something we expected to be commonly used. LDAP is used on 125 installations. So 4.5% of all forums use an auth plugin that does not ship with phpBB, and 0.38% of all forums use LDAP or Apache plugins which ship with phpBB.

[innov8ion]

Just wondering, what's the status for the Google Summer of Code project on the authentication plugin? It seems like it'd be pretty valuable to the phpBB community.

https://blog.phpbb.com/2012/07/16/google-summer-of-code-2012-authentication-plugin-refactoring-and-user-integration/

[Hardolaf]

innov8ion, there is still some work needed to be done before it can be merged. I'll be working on polishing it up, getting more documentation written, and finishing up the user interface changes as I have time. However, as I'm back in college, I have little free time during the week so I'll probably only be able to work on weekends. The code as it exists will log you in with a properly programmed provider if someone wanted to use it. However, it is not polished, the UI needs significant styling, and there is at least one feature which sadly has not yet been coded (an authentication link manager so people can add associations and remove them at will).