www programming

Time to start fixing points about how the integration 2.4.0 will work, and why:
in the while the code may will change, so something here will be added or updated

You should (but could be not) start the integration, with corresponding and unique email and usernames pairs (as it has been until now).
phpBB need to be setup on ACP to not share same email for different usernames, and DO NOT allow usernames changes (but since the integration works by email now, could be allowed to change usernames, but this aspect will be covered after, since with changing these rules, concepts of an integration become more hard, that is may clear for those that knows advanced CMS logic and web programming, and considering that this is a WP plugin, that so, only run in WP side).

Possible logins integrations:

If user's profile email update allowed in phpBB, then the user's login and registration is possible to be allowed ONLY in phpBB.
If user's email update disabled into phpBB user's profile, any other combination between wp and phpBB is possible, included (but it is discouraged since 2.4.0>) leaving users register on both wp and phpBB.

It is possible to switch to one or other way to integrate, any moment

2.4.0, is not anymore by username, but by email. And an email can be updated to something else.
SO it is important to fix in mind that for this reason, it is mandatory to choose, and users need to be forced to update their email or register in WordPress OR phpBB (and in this case also the login need to be allowed ONLY in phpBB), not on both.

Usernames scenario example:

phpBB usernames (if they exists, but it remain suggested to setup phpBB ACP to not allow phpBB to accept any usernames chars) like:
$£ALE'-\=0
will be added in wordpress as:
ALE-0
because this is the default wordpress result after the username has been "cleaned".
this username, added in wordpress if not exist, can be added in wordpress because the user come to visit wordpress as logged in phpBB, or due to a login done in wordpress side. The user can login in wordpress using $£ALE'-\=0, but will be created as ALE-0, so first login will fail if done as phpBB username, the message will display that the username do not exist and invite to try by email. The user will have to use ALE-0 (the wp username), if logging in wp side by username and not by email, after it has been created in wordpress.
The user's Display name option of the user at this time, will display the complete phpBB username not sanitized, so $£ALE'-\=0.

Anyway, note that wordpress if the login done by user_login -> $£ALE'-\=0, so this user will have to login in wordpress side, using his email and NOT his phpBB username, or will have to use ALE-0 (the wp username), if logging in in wp side by username and not by email, after it has been added.


On WordPress MUMS, any phpBB username containing characters that aren't into the range [0-9A-Za-z]/' (lowercase Uppercase a-z, and 0-9) will not be added into wordpress-

User ID1 in WordPress and user ID2 in phpBB (default install admins) are not linked anymore.

Since 2.4.0 release it is mandatory:

Setup into phpBB ACP options: do not allow users re-use email or usernames for different accounts.

To disable the possibility for users into phpBB to update their email:

ACP -> TAB System -> User Control Panel -> click into Profile -> Edit account settings, click into Disable to disable the user's account settings module. Then the Edit account settings , where it is possible to update user's email and password in phpBB ucp will not be accessible (while all the rest of phpBB profile options will be still available to phpBB users). Disable new registrations in phpBB.

It is possible to hash the password in phpBB way or WordPress way. Hints are on same option, into the integration plugin admin page. phpBB way used until now, and it is the default.

Default page-forum.php for the iframe mode has been updated, because the user ID1 in WP and UID2 in phpBB are not linked anymore, so a fix for this user, whenever he goes to navigate the forum in iframe mode, has been necessary. The old one will work fine for all users, but not for UID1 WP & UID2 phpBB, or they will fall into the "famous refresh loop" while visiting wp page-forum as logged in phpBB or WP.

The integration, if phpBB is configured to not allow new registrations nor profile fields updates for email and url, can be set excluding the execution of the main query verify_phpbb_credentials(), speeding up the integration to maximum possible. No queries executed during normal users operations, but just singles queries only when updating profiles in wordpress.

In true, due to simplicity of the code, if phpBB configured on ACP to do not allow users to update those fields on UCP
it would be just necessary to put a
return;
just after the line, on /wp-content/plugins/wp-w3all-phpbb-integration/class.wp.w3all-phpbb.php

and removing calls in some other function if the case.

An option will be added about this, somewhere along 2.4.0> releases or maybe added right into 2.4.0 as this is proven after some test, that it will be exactly as expected, after some little more code changes

In the while, a correction for the above:
the main verify_credentials query has been shortened and reduced to the minimum to be executed faster.
It will not check using LEFT JOINs where not necessary, because this add nothing about security, and will retrieve the minimum.

The unique secure measure against a bruteforce attacks to phpBB sessions keys on wp side, is the
w3all sessions keys Brute Force countermeasure
option active.

Further more, the assertion on plugin admin where this option hint say:

Note: it is not required to activate this option, if you do not let users to login in WordPress side

is NOT TRUE.
It is required that this option is active, in any case.
So it will become default since 2.4.0.

Unfortunately, this lead to a conclusion, since/if the email can be updated into phpBB:
if in phpBB an user change his email, and since the integration is email based, how the user will be allowed/recognized to login into wordpress, if after he will try to login in wp side? The email will mismatch because do not updated at same time in wordpress for the user, if the user do not visit wp side as logged at the time email has been updated into phpBB (because this is a wp plugin that run in wp side).

Due to the logic of the code that act against bruteforce on sessions keys, it is required that a regular not logged in User which his ID is on the bruteforce list, due to a presented not matching phpBB session id, is allowed to login in WordPress side to unlock his login in wordpress.

Best way is that EVER, the email update should NOT BE ALLOWED in phpBB profile, disabling related module.
But i will try to check if there is another way to workaround to this.

The assertion above, is as follow explained (because again, not totally true).

if an user change his email in phpBB, then logout before to visit the WordPress side, so his email is not updated in WordPress also, and come into wordpress side to login
then what happen is the follow:

if the login done via email, since no corresponding email will be found in wordpress, the message will be this:

Unknown email address. Check again or try your username.

then if the login done via username, it depend, there are two possibilities
if the used username is the same in WordPress and phpBB or not:
1) if the username in wordpress is the same as it is in phpBB, then the user using the username to login in wp side will be ok, and his email in wp updated to the same as it is in phpBB, at same time.
2) if the username in wordpress do not match the same in phpBB, then this user will not have possibility to login wordpress and if necessary will not be able to unlock his account.
using the username that do not match, the user login simply is nullified, without returning any error, but will be added.

If using email, the message will be instead:

Sorry, that username already exists!
ERROR: try to reload page, but if the error persist may mean that the forum's logged in username contains illegal characters that are not allowed on this system. Please contact an administrator.

that's hard to explain why, but let me resume that it is perfectly congruent (you can argue why) and it is the expected result (as code is).


Resuming it is important to fix in mind that, the integration can work fine in any scenario, if usernames in phpBB are the same as they are in wordpress.
Or it will be mandatory to AVOID USER'S EMAIL CHANGE ON PHPBB PROFILES, to avoid problems for those users with mismatching usernames between phpBB and wordpress, where phpBB email updates allowed in phpBB.

Last consideration if that if an user login in phpBB, then come into wordpress, but his id result to be on the antibruteforce list due to detected bruteforce attack, will be logged out and required to login in wordpress side to unlock the account

Just applied all the above, after that what about transfer and check-users part, has been also fixed.

w3all sessions keys Brute Force countermeasure behavior
Brute Force countermeasure become by default active, and need to be intentionally disabled on plugin admin.
The Swap WordPress default Login, Register and Lost Password links to point to phpBB related pages
has been changed, and become only Swap WordPress Register and Lost Password links to point to phpBB related pages.

The reason of this is explained and can be argued, on last 4/5 replies here above on this thread.

It will be an admin/developer task, to remove links that points to wordpress login on wp frontend if logins preferred to be done/forced only in phpBB side, but/so leaving the possibility for legit not logged in users, to login via wp and unlock their account, when/if it is required due to a bruteforce block.

RC3 is coming within today if possible, with definitive code tested and fixed under any aspect, or at least this is it on any executed stress test, working without any error since days now here.