| Project: | Secure Pages |
| Version: | 6.x-1.8 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
Although I saw some bug fixes related to language issues, we are still having problems with secure pages in our multi language sites. Some pages that are recognized as secure pages in the default site language, are not secure anymore when switching to another language. This seems to be related (again) to the language prefix.
In issue #382042: Language prefix repeatedly added by Secure Page, there has been suggested a fix for this problem, but this still doesn't seem to cover all situations. This fix does not add the language prefix anymore, which solves a part of the problem, but when the language prefix is already present in the url or path trying to be matched, the secure page is still not recognized.
I don't know whether this is a known problem or if there is already a new patch for this, but I couldn't find any new issue related to this problem. I attached a patch which solved all language related issues with secure pages for me. (even when secure pages is disabled I have a problem in combination with the toboggan module: there are still multiple language prefixes in the login form action when a user tries to access an unauthorized page. I did not look any further for this issue since I will always use it in combination with secure pages)
The patch changes the securepages_match function: if there is already a language prefix in the path, it will be removed before matching the path. The patch also contains (a slightly modified version of) the http://drupal.org/files/issues/securepages-462438_2.patch (issue #462438: Alter #action of login block form). If this is not wanted, then only the second part of the module patch is important.
I don't know if this is the right approach for this solution, but it seems to be the clean solution working for me without modifying any core modules or files. I hope this could be helpful to someone.
Tom
| Attachment | Size |
|---|---|
| securepages.install.patch | 395 bytes |
| securepages.module.patch | 1.51 KB |
| securepages.admin_.patch | 888 bytes |
Comments
#1
subscribing
#2
I'm seeing this too, for example:
Trying http://www.example.com/node/1/edit I get redirected to the https version. But, trying http://www.example.com/es/node/1/edit I do not get redirected. On the other hand, http://www.example.com/es/node/add does get redirected to https correctly.
I am going to work-around this in my module - MultiLink Redirect as I'm currently testing to make sure it doesn't conflict with Secure Pages.
#3
After further research, it seems that bug is also related to the "switch back" option - if that is turned off then behaviour is correct. Could the maintainer please get in touch with me if and when this issue is going to be addressed - I have code in MultiLink Redirect specifically to work-around this problem. In addition, since MutliLink provides alternative redirection (dependent on availability of a translation for a node) I'd like to agree how integration between the two modules should work. Currently, MultiLink Redirect "takes over" by disabling Secure Pages and then calling SP's internals to decide how to re-direct. It works fine, but a better way would probably be for SP to call a defined MR function instead.
#4
Netgenius,
I sent a request to Gordon to take over the module. He has not worked on it for 6 months... 8-)
I don't think you should have a need for another module to make the HTTPS/SSL work on your website! I have nothing against your module, but it would not make sense to me to have to install it just so Secure Pages works.
And I checked out the patches, they look good to me.
Thank you.
Alexis
#5
@AlexisWilke - It seems I failed to explain - MultiLink is not designed to *replace* SecurePages, it provides completely different functions, primarily for multi-language sites. But it does *integrate* with SecurePages, and that's why I needed to include work-around code. The patches will be fine, once committed.
#6
We are getting near a year after the patches & I don´t see any confirmation here that the issue has been resolved.
Are the patches still not incorporated to the latest release of Secure_pages ??!
Like to be sure before I start messing around with applying patches that might cause other problems, especially if patches already have been applied in this way or another.
Here is a new securepages release: http://drupal.org/project/securepages
6.x-1.x-dev Download (12.55 KB) 2010-May-11 Notes
So does it have the patches as it should and then why this issue hasn't been closed?
#7
ClearXS x 2,
Some authors like to keep issues open until they generate the next version (1.9 in this case). That way they can keep track of what needs to be put in when creating the full version.
I'd rather use the CVS comments and mark issues as "patched applied" or something of that order... 8-) I'm surprised Gordon did not post anything though.
Thank you.
Alexis Wilke
#8
well, nothing/nobody is perfect and there is some good work done, but I´m going through a shipload of installed modules and finally after 3 years I succeeded to have a complex site that has no real errors. Now is the time to go through many possible patches and enhancements. But I´m not that good in PHP at all, so making a little mistake in changing code that doesn´t result immediately in a drupal derailment, could led to undetected and dangerous changes. Plus after patches I have to keep an eye on that file thinking about what has to happen with those files on upgrades.
(+ title partially changed back; thought I was only changing the title of my reply...)
#9
I didn't need the other changes, but I was experiencing a redirection loop when users switched languages (eg: via language switcher block).
This patch is a re-roll of the OP's securepages.module.patch but focused on the path cleaning.
#11
Patch above didn't work for me.
Drupal 6.20
Two languages set up.
i18 module installed.
Attached patch removes the language prefix before evaluating if the path matches a configured include/ignore setting.
#12
Subscribe.
#13
subscribe
#14
#1145292: Problem with i18n/improper redirect