| Project: | Secure Pages |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
Hi,
I decided to go for a cleaner approach to redirects and simply output the links to the correct URLs the first time (wherever possible - there may be corner cases where it doesn't work).
This greatly helps when using Boost, as it means that there's less reliance on bootstrapping Drupal to get users on the right protocol. We had a problem that when a user finishes checking out their cart, they get sent back to the site on HTTPS, but anonymous users at that point start getting Boost pages again, so remain on HTTPS even though they should've switched back.
To activate this support you need to have the url_alter module installed, which defines hook_url_alter_oubound(), a hook backported from D7. When this module isn't installed, this functionality won't work (until D7), but it won't break anything.
Thanks
| Attachment | Size |
|---|---|
| securepages.urlalter.patch | 1.34 KB |
Comments
#1
Does this patch account for
<front>? If I don't have<front>in the list of pages to secure, then $path resolves to FALSE (empty) in the second if statement, and doesn't get rewritten withouthttps://.#2
It doesn't do any specific checking, no.
On my site I don't have
<front>listed as a secure page, and my patch is working correctly.Do you mean that links to
<front>don't get rewritten back properly, or that links aren't rewriting properly from<front>?#3
"Do you mean that links to don't get rewritten back properly"
That's what I mean.
Assumptions:
<front><front>is not in the list of pages to serve securelyThe URL in the link is written as https://example.com/ All other links get rewritten (say http://example.com/about for example) properly.
#4
You're quite right, it seems
<front>isn't translated before being passed to url_alter. I've revised it to make the substitution, but it may have unwanted side effects by altering $path by reference to no longer be<front>(if some other rewrite hook was expecting it to be intact?)#5
Sorry, rerolled the patch without my custom readme.
#6
Now with this patch, links to the
<front>page not rewritten at all. That is, they are insecure if the page you're visiting is insecure, or secure if the page you're visiting is secure. The patch still works correctly for links like 'about', etc.Will the first if statement ever resolve to TRUE? When I look at $path as passed to the hook, it appears to be an empty string when the path in question is
<front>.#7
edit
#8
Rerolled with:
git diff --no-prefix --relative
#9
Awesome, works well. Fixed a bug we were having with IE not initiating HTTPS as well.
#10
Is there a way to force http:// for the frontpage?
#11
Update
With Boost enabled everything works fine with this patch.
Whenever a webform node is secured via SSL clicking on a normal not secured link it switches back to http://. Only the frontpage is just using the protocol where you came from...
Example:
Clicking from http://mysite.com >> https://mysite.com/webform works. If I know click back to home from https://mysite.com/webform >> https://mysite.com is still get the https on the homepage. This behaviour is only for
<front>- all other urls are switching exactly as supposed to.Is there a way to modify this patch, so that frontpage will load in http://? I am also using secure pages (of course) and is not in the selected list for SSL.
Any help would be really aprecciated - I tried already 3 days to find this trick.
#12
Still need help with that... :-(