The change in phpBB 3.2.6 which made "you must have the same session ID between receiving the login form and submitting the login form" a requirement (albeit indirectly via add_form_key() and check_form_key()) seems like it may have given us a preview for some of the challenges phpBB users could encounter here.
We now routinely have "I cannot login due to form invalid" reported in the public forum, even when cookie settings are correct, as though there is still some lurking behavior if not bug that still puts people into a "guest doesn't get the same session twice" scenario. Or, we see cases where even though the cookie settings were already correct, we have to delete the current cookies before login starts working. As though logic for "the existing cookie needs to be updated" was either missing or misfiring, or something more subtle we're just not identifying yet.
The point being, we have an initial taste or "warning" of how sensitive new requirements in the login area can be. Handling the implementation of PHPBB3-16207 well could prevent an unnecessary additional fundamental frustration for phpBB operators, when something as basic as "I just want to login to my new board" potentially becomes more brittle "due to increased security."
Ideas that come to mind for trying to mitigate against this:
- Make installation actually test the cookie settings, and don't allow advancing to next install phase without achieving a working cookie configuration as confirmed by Set-Cookie and subsequent cookie values received by the install app's own pages. If something is blocking the cookies from working correctly, you'll be unable to proceed with the installation until you identify and eliminate this. Not just "Here is where you enter your cookie settings. Next."
- Make the login itself actually test cookies, and if they're not working, create a very clear description of why the login is failing. Even going so far as the PHP-side code checking what we think the current board URL, path, and access protocol are, and advising whether the issue appears to be in the phpBB cookie configuration (something the user definitely cannot solve), versus the cookie settings "look fine for how you're accessing this board" and there may be some local browser blocking or issue (not withstanding that it could also be a server-side issue even in that case, too).
- When in the guest session scenario like login, if the site cookie settings look correct yet we seem unable to get the correct canary/test values we're using to verify cookie operation, have phpBB issue a deletion of the cookies as a standard part of the failed login response. i.e. Don't wait for the user to be frustrated and finally start looking for troubleshooting steps. It may or may not resolve whatever issue is actually happening, but its something we could be trying programmatically instead of waiting for the user to be educated enough to try this same action.
- Perhaps ship some kind of non-session-based bare metal UI (like the cookies.php script the KB article offers) which can be enabled on-demand (e.g. "rename shipped fix_cookes.disabled to fix_cookies.php") long enough for the site operator to use a simple form to change cookie configuration. To give admins a readily accessible, if not still less-than-ideal, in-box method to address cookie configuration changes. Since once the new sessions-need-cookies and no-append_sid-fallback changes have been implemented, the admin can no longer use ACP to fix cookie configuration settings.
