www programming

Found errors, and fixed. Not code errors, but behaviors errors.
There was on updating users by admin in certain cases, into the login widget, and some more.

The [b]w3all sessions keys Brute Force countermeasure[/b] is set to yes by default since 2.4.0, and change a little to be more effective.
To me, it was possible to mount an attack based on a little complicate, but maybe possible way.
Now, the [i]w3all sessions keys Brute Force countermeasure[/i] logic works little different, and do not cleanup records as before.
Cleanup records eliminating older 100, when it exceed 4000 records, but maintaining ALL that exceeds.

If the bruteblock ids array will contain more than 4000 records, that in theory should never happen to to the auto-cleanup behavior, a little red warning/notice with the number of total records will display, where related option on plugin admin.
Setting to NO the option and saving preferences, will empty/reset data (as it was until now).

I'm in doubt on adding option into plugin admin, if right now, or along 2.4.0> series, to setup data for the db connection to phpBB into plugin admin, [b]and terminating with the inclusion of the phpBB config.php file[/b].
I assume it would be a good switch to, and further (so little maybe) speedup of code execution.

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

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

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.

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

[b]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[/b]
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:
[quote]Unknown email address. Check again or try your username.[/quote]

then if the login done via username, it depend, there are two possibilities
[b]if the used username is the same in WordPress and phpBB or not[/b]:
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 [b]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.[/b]
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:
[quote]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.[/quote]

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, [b]if usernames in phpBB are the same as they are in wordpress[/b].
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

In the while, a correction for the above:
the [b]main verify_credentials query has been shortened and reduced to the minimum to be executed faster[/b].
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
[b]w3all sessions keys Brute Force countermeasure[/b]
option active.

Further more, the assertion on plugin admin where this option hint say:
[quote]Note: it is not required to activate this option, if you do not let users to login in WordPress side[/quote]
is NOT TRUE.
It is required that this option is active, in any case.
[b]So it will become default since 2.4.0.[/b]

[strike]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 [b]regular not logged in User[/b] 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.[/strike]

private static function verify_phpbb_credentials(){

The integration, if phpBB is [b]configured to [size=110]not allow new registrations[/size] nor profile fields updates for [size=110]email and url[/size][/b], can be set excluding the execution of the main query [i]verify_phpbb_credentials()[/i], 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
[c]return;[/c]
just after the
[code]private static function verify_phpbb_credentials(){[/code]
line, on [i]/wp-content/plugins/wp-w3all-phpbb-integration/[b]class.wp.w3all-phpbb.php[/b][/i]

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

[b]Since 2.4.0 release it is mandatory:[/b]

[b]Setup into phpBB ACP options: [size=110]do not allow users re-use email or usernames[/size] for different accounts.[/b]

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

[b]ACP -> TAB System -> User Control Panel -> click into Profile -> Edit account settings[/b], 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.