I just enabled the module and noticed by default there is a config line to secure the url:
user/*

On my site I log in by visiting /user - which is the sort of "default" isn't it? Anyway I was able to log in without encountering an HTTPS page. So I changed the config to user* and now I can only log in over HTTPS. Shouldn't this setting be in the defaults? Isn't that the first thing you would want to secure?

CommentFileSizeAuthor
#10 securepages-n264987.patch1.3 KBDamienMcKenna
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

VM’s picture

VM CreditAttribution: VM commented

I assume you log in through user because you've disabled the login block ?

do you get an https when using the block ?

fletchgqc’s picture

fletchgqc CreditAttribution: fletchgqc commented

1. Yes, correct.
2. Haven't tried, it's not really relevant for me.

VM’s picture

VM CreditAttribution: VM commented

while it may not be relevant for you, it is relevant to the request and your question about whether or not it should be a default setting.

compudaze’s picture

compudaze CreditAttribution: compudaze commented

How would I secure login with this module?

VM’s picture

VM CreditAttribution: VM commented
Status: Active » Fixed

I'd think you would want to investigate the securelogin.module

fletchgqc’s picture

fletchgqc CreditAttribution: fletchgqc commented

Or just add /user to the pages to be viewed over HTTPS.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna commented

The v6.x-1.7 release secures the user/* pages by default.

fletchgqc’s picture

fletchgqc CreditAttribution: fletchgqc commented

"user/*" does not match "user"

The ideal solution would be two lines:
user/*
user

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna commented
Status: Closed (fixed) » Needs review
FileSize
securepages-n264987.patch1.3 KB

fletchgqc: Correct. I've attached a tiny patch for the D6 branch to add it in. It also separates the main admin page vs the sub-pages, to have them listed in the same format.

Matt V.’s picture

Matt V. CreditAttribution: Matt V. commented
Status: Needs review » Reviewed & tested by the community

I applied the patch listed in comment #10 to version 6.x-1.8 of the module. It applied without any trouble and appears to work as advertised. I think it is an important patch because someone who just accepts the defaults after installing this module could easily be under the mistaken impression that user logins are secure, when they may not be.

YK85’s picture

YK85 CreditAttribution: YK85 commented

subscribing
will this patch be committed to the core Secure Pages module?

robby.smith’s picture

robby.smith CreditAttribution: robby.smith commented

subscribing, +1 for commit

izmeez’s picture

izmeez CreditAttribution: izmeez commented

[EDIT]: Please ignore my earlier comments which are below. I have tested this again from scratch. The first thing I did was make sure that no wysiwyg editor was on in the securepages configuration. Then everything is fine. The default pages to secure and ignore appear on separate lines and the user/* seems to work but I had to add user* for cases when the url http://example.com/user is used.

Thanks for the module.

Izzy

[/EDIT]

Previous comments to disregard:

Just using securepages module for the first time. Thank you very much.

I'm also glad that I found this issue.
I am using Logintoboggan and even though it is configured to link to the login page I was having trouble getting that to be secured over SSL if I have the switch to non-secure checkbox selected.

I tried "user" but this did not work neither did "user/*", however "user*" seems to work. Not sure why?

I also found I had to edit the securepages configuration so that each item was on a separate line instead of all on a single line. I may have to test this further to confirm.

Thanks,

Izzy

nschloe’s picture

nschloe CreditAttribution: nschloe commented

subscribing, have the same issue

gordon’s picture

gordon CreditAttribution: gordon commented
Status: Reviewed & tested by the community » Fixed

* I have committed this to dev.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.