Something did change again between phpBB 3.2.6 and phpBB 3.2.7 related to the login form token, but not in a way which should have affected your solution.
Instead of providing templates with the new form token through the new
template variable that was created for it, phpBB 3.2.7 actually passes the new from token through the
template variable, which already existed. This is so even if someone continues using a style which has not been updated for phpBB 3.2.6 and later, login will continue to work (for now) rather than being such a prominent phpBB 3.2.6 / phpBB 3.2.7 post-update issue.
But you're not using either the
template variables to construct the form. And the update doesn't modify anything about the login form field names or contents that ucp.php?mode=login is going to be expecting. So this phpBB 3.2.7 change really doesn't mean anything to your external login form.
I'm seeing a few different results right now:
- If I clear cookies and start at https://www.usufans.com/loginform.php, the form looks fine, the SID value in the form matches what's also saved in cookies, a valid creation time is set, etc. Submitting correct credentials from that form results in "no error". I'm simply taken to ucp.php?mode=login without any login failure message, as though I haven't made any attempt to login yet.
- At that point, in the ucp.php?mode=login page which is now being displayed to me, if I try to use your login fields up in the top header of the page, entering correct credentials results in "The submitted form is invalid." Re-attempting login using the same login fields at the top of the page will produce the same "invalid form" result again and again.
- If I stop retrying with the login fields in the header at the top of the page, and instead use "the main login fields" in the ucp.php?mode=login page, entering correct credentials will login successfully.
- Additionally, whether I clear cookies or not, if I simply use "the main login form" on the ucp.acp?mode=login page (the one in the middle of the page, presented as proSilver would also present it), entering correct credentials in this form always results in a successful login, under any of the previous scenarios.
I can't tell that anything is wrong in the https://www.usufans.com/loginform.php
case; you would have to just debug the login_box() code once ucp.php?mode=login is invoked to post the login form, and follow the code to see why the login is thought to be not successful, and maybe what code path occurred which bypassed displaying any error.
For the cases where "login form fields in the header at the top of the page result in submitted form invalid", what I see is that the calculated form_token value (the hashed data) is different between your form and the "the main login form". Your "creation time" values are the same, and the SID values are the same. But even though this means you you should have ended up calculating the same hash value given the exact same input data, you don't. So something about the data you use for your form is apparently different from the main form, in this case.
When I've cleared cookies and can successfully use the login form fields in the header at the top of the page, I also observe that the hashed form_token value is the same between the two login forms, too. So the data you used to calculate the hash was completely identical in that success case.
One thing which looks potentially wrong to me is that in the "3. Form" section of your earlier post
, you used
to put the SID value into the actual login form. As opposed to
, which is where it was obtained for the hashing of form_token. I expect the former is retrieving the session_id value currently saved in the database, which I suppose may or may not be "the session I'm currently in" (yet). The code should probably be pulling from
in both cases, to get the "live" session ID.
That doesn't seem very likely for being the root cause, though. Maybe it is if your "3. Form" code represents how you're constructing the login form fields in the header at the top of the page. (As opposed to simply using
there, since you're inside a regular style template at that point.) Hmm, I guess you must
be using your own code for the login form at the top of the page, because if you were using
for that form, there would be 0% chance of the login_key values being different. So possibly the
change could fix things.
Otherwise, if that change doesn't fix things, "debug login_box() to see why login is thought to have failed when using https://www.usufans.com/loginform.php"
, and then separately "debug why you can get a wrong/different form_token value in your header login form as compared to the main login form on ucp.php?mode=login"
, are the only suggestions I can make based on what I've seen. Because the root cause isn't obvious to me, either.