Nodes with URL aliases are never matched (whether set manually or via Pathauto). Only a node's original URL may be specified for inclusion or exclusion. For example, if node #50 has a url alias of 'test', the following inclusion list will not protect it:

test
node/add*
node/*/edit
user/*
admin*
user

However, changing the first entry to the original path works:

node/50
node/add*
node/*/edit
user/*
admin*
user

This is not the case for views, whose paths seem to work fine.

CommentFileSizeAuthor
#2 securepages.module.check-path-alias-0.patch761 bytesashtonium
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pheinrich’s picture

pheinrich CreditAttribution: pheinrich commented

This was a relatively easy fix (assuming I'm not missing something obvious). I've seen others request this functionality; here's my change, in case it helps someone else:

271c271,278
< return !($secure xor preg_match($regexp, $path)) ? 1 : 0;
---
>
> $result = preg_match($regexp, $path);
> if (function_exists('drupal_get_path_alias')) {
> $path_alias = drupal_get_path_alias($_GET['q']);
> $result |= preg_match($regexp, $path_alias);
> }
>
> return ($secure xor $result) ? 0 : 1;

ashtonium’s picture

ashtonium CreditAttribution: ashtonium commented
Version: 5.x-1.6 » 5.x-1.x-dev
Status: Active » Needs review
FileSize
securepages.module.check-path-alias-0.patch761 bytes

Here's a patch file (against the latest 5.x-1.x-dev) with some changes:

  1. drupal_get_path_alias should test the passed value of $path instead of $_GET['q'] because the securepages_match function is used for more than just the current browser URL
  2. I've change the logic on the return statement back to defaulting to 0 as it was before. I don't think that change pertains to this issue and so should be submitted as a separate issue if you feel that it needs to be modified.
Leeteq’s picture

Leeteq CreditAttribution: Leeteq commented

See also: "Securepages does not work with Clean URLs enabled"
http://drupal.org/node/206864

PaulWood’s picture

PaulWood CreditAttribution: PaulWood commented

pheinrich,

Do you plan to incorporate this logic into a future revision of Secure Pages?

vivianspencer’s picture

vivianspencer CreditAttribution: vivianspencer commented

This patch works beautifully for me, a lot pages on my site weren't being secured until I installed this patch

many thanks

easp’s picture

easp CreditAttribution: easp commented

The patch also worked for me. I applied the patch to securepages-6.x-1.7-beta2 and it fixed my alias problems. Many thanks!

mrfelton’s picture

mrfelton CreditAttribution: mrfelton commented

patch at #2 also works for me on drupal 6. Can we get this committed in both version please?

sgriffin’s picture

sgriffin CreditAttribution: sgriffin commented

Bump, this patch is still not committed to 5 head.

jschrab’s picture

jschrab CreditAttribution: jschrab commented
Version: 5.x-1.x-dev » 6.x-1.7

I too have had need to apply this patch to 6.x-1.7 (release, not beta) to make Secure Pages work like I expect.

amariotti’s picture

amariotti CreditAttribution: amariotti commented

Please apply this patch to the latest versions. It worked perfectly and allows the functionality that should be there. Thanks a bunch!

gordon’s picture

gordon CreditAttribution: gordon commented
Status: Needs review » Fixed

Thanks I have committed this to dev

ashtonium’s picture

ashtonium CreditAttribution: ashtonium commented
Version: 6.x-1.7 » 5.x-1.7
Status: Fixed » Reviewed & tested by the community

Thanks for committing this to the 6.x branch. Can we get it committed to 5.x as well?

The patch was actually written against the 5.x branch. I just tested and it still applies cleanly with some line offset.

mrfelton’s picture

mrfelton CreditAttribution: mrfelton commented
Status: Reviewed & tested by the community » Patch (to be ported)

For reference: I think http://drupal.org/node/206864#comment-2649468 is related to the the change that was made in this patch.

grendzy’s picture

grendzy CreditAttribution: grendzy commented
Status: Patch (to be ported) » Closed (won't fix)

The 5.x branch is no longer supported. If this issue is still present in a current version of Secure Pages, please update the issue summary, change the version field, and re-open the issue.