Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I want every page secure. So I checked "Make secure every page except the listed pages." and left the listed pages blank. Logically, that should do it. But it doesn't. So to achieve what I want, I had to check "Make secure only the listed pages." and leave a * in the listed below. It works that way but obviously there is something wrong in the module. I haven't looked at the source yet to determine the issue.
Comment | File | Size | Author |
---|---|---|---|
#13 | all_pages-566632-13.patch | 3.09 KB | Deciphered |
#8 | securepages-empty-page-list.patch | 3 KB | David_Rothstein |
Comments
Comment #1
mstef CreditAttribution: mstef commentedMy guess at first glance..
Comment #2
fjroman CreditAttribution: fjroman commentedI just want some pages secure, but I found out that my Securepages only works when there is just one page on the box. I tried with \n, same line, different line... but nothing... Any clue?
Comment #3
jamesfk CreditAttribution: jamesfk commentedGetting the same issue, fixed it by putting in a non existing page into the show all apart from box.
Comment #4
mstef CreditAttribution: mstef commentedYeah I did the same thing too but felt it still should be address in the module.
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedSame problem here. subscribing.
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commentedCouldn't reproduce this problem.
Please reopen if your still experiencing problems and i'll see if i can help.
Best,
Paul Booker
Comment #7
pkiff CreditAttribution: pkiff commentedI ran into the same issue as the original poster. I have a site that I want to be delivered entirely, and exclusively, through encrypted (secure) pages, including the front page. I am unable to use a regular server redirect or other server control to force this via the server, so secure_pages is the next best solution.
I used the following base URL settings (with my actual domain, of course):
Non-secure Base URL: http://subdomain.example.com
Secure Base URL: https://subdomain.example.com
Then selected "Make secure every page except the listed pages." And listed nothing in the remaining boxes.
But pages were not redirected or forced to https versions. I tried just inserting
<front>
into the list of exceptions, but that also did not fix the issue. As with the OP, I solved the issue by checking "Make secure only the listed pages." and leave a * in the list of pages. Then it works as designed.Notes on my config:
- IIS 7
- PHP 5.2x
- firewall in use
- also using the following modules that could potentially be affecting things:
Path redirect:
http://drupal.org/project/path_redirect
PathAuto:
http://drupal.org/project/pathauto
CustomError:
http://drupal.org/project/customerror
I'm happy with the solution offered by the OP as it stands now, and am not in a position to investigate the code myself, but wanted to re-open this as a bug report in case other newcomers run into the same issue.
Phil.
Comment #8
David_Rothstein CreditAttribution: David_Rothstein commentedI ran across this bug today. Here's a patch for Drupal 7 (with tests).
Since the buggy part of the code is the only part of the securepages_match() function that ever returns NULL (and as far as I can tell, it never should), this patch removes that from the allowed list of return values as well.
Comment #9
David_Rothstein CreditAttribution: David_Rothstein commentedComment #10
grendzy CreditAttribution: grendzy commentedWow! With Tests! ♥♥♥
I thought there was a reason for the tri-state return value (0,1,null). I'll check it out.
Comment #11
sobi3ch CreditAttribution: sobi3ch commentedI had version 6.x-1.9 and the problem is similar. I've selected "Make secure only the listed pages." and I put
(..of course I wasn't aware of empty line)
then each front page request was redirecting me to https:// scheme. Is there any solution (patch?) for it?
Comment #12
pkiff CreditAttribution: pkiff commentedI don't think this is the same issue as others in this thread. Certainly, for us, using 6.x-1.9, these kinds of settings work as designed. The issue in this thread relates to cases where you have a "Null" value in your list to exclude/include. I don't follow what your reference to the empty/blank line is intended to mean: did you try removing the blank line?
Regardless, I would recommend starting a new issue to address your specific case.
Phil.
Comment #13
Deciphered CreditAttribution: Deciphered commentedRe-rolled patch from #8
Comment #14
nerdcore CreditAttribution: nerdcore commentedPatch in #13 did not fix this issue for me.
Using "Make secure every page except the listed pages" with an empty "Pages" textarea still results in pages loaded via HTTP.
The workaround of "Make secure only the listed pages" with "Pages" set to "*" does function as expected.
Another workaround which seems functional is to specify SOMETHING in the "Pages" list with the "Make secure every page except the listed pages" option. I used "/non-existent-page" and every page comes up HTTPS.
Would be nice to be able to leave that field blank and have HTTPS forced everywhere though, as that is the intuitive solution.
Comment #15
nerdcore CreditAttribution: nerdcore commentedI've just seen another issue with this option. I'm not convinced it works at all.
I've used "Make secure every page except the listed pages" and specified one real page which I do not require HTTPS for, "/careers". This page loads with HTTPS every time. This option does not seem to be providing the functionality it suggests, with or without the patch in #13.
Comment #16
nerdcore CreditAttribution: nerdcore commented*sigh*
Patch in #13 works fine for me it turns out. When I applied it once locally it worked. When I applied it on my testing server nothing happened, so all my testing was without the patch.
However, my comment in #15 still stands - the excepted pages which should be allowed to load via HTTP still force HTTPS.
Patch in #13 is RTBC'ed. Sorry for the confusion.
Comment #17
hussainwebI would say this is critical as it is confusing and hampers essential operation if not configured. I am just settling for major now.
Comment #18
aaron.ferris CreditAttribution: aaron.ferris commentedAnother +1 for the patch in #13