We have a custom access denied page that uses PHP to output the existing login form. In this case, Secure Pages does not secure the login form.
I'd suggest modifying line 103:
FROM
if (securepages_match('user/login') && $form_id == 'user_login_block' && !$is_https) {
TO
if (securepages_match('user/login') && $form_id == 'user_login_block') {
This resolved the issue for me, and didn't appear to break anything obvious. I didn't want to make this a patch myself because I'm not well versed in all that Secure Pages does, and wasn't sure if this breaks intended operation somewhere I'm not considering.
This is because for whatever reason, my login block on the custom page produces a fully qualified URL for the form action. This means that if I mis-enter the password, the second attempt will be from an SSL page but will submit to a non-SSL page. Another solution would be to check if the action URL is https (rather than the current page), and rewrite if not.
Comments
Comment #1
srees commentedI additionally noticed that this strips arguments from the form action, when replacing it with a secure URL.
Replacing line 104 with the following handles this:
Comment #1.0
srees commented*Edited to remove !$is_https*
This is because for whatever reason, my login block on the custom page produces a fully qualified URL for the form action. This means that if I mis-enter the password, the second attempt will be from an SSL page but will submit to a non-SSL page.
Comment #2
srees commentedUpdating the title to better reflect the real issue.
Comment #2.0
srees commentedAdjust a logic error that was resulting in all forms being secure (thus making anything ajax highly difficult) and explain the root cause of issue.
Comment #3
astonvictor commentedI'm closing it because the issue was created a long time ago without any further steps.
if you still need it then raise a new one.
thanks