When you set up a site using the securepages module, this will basically only protect specific pages (as intented).
For site admins this means that they can only connect over secure networks because otherwise their session could be stolen.
The attached patch offers an option to keep selected roles behind SSL all the time. This behaviour is mandatory for user No. 1.
This patch is untried as I currently don't have a setup to test.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | securepages.patch | 6.19 KB | gerhard killesreiter |
| #1 | securepages.patch | 3.71 KB | killes@www.drop.org |
| securepages.patch | 2.61 KB | killes@www.drop.org |
Comments
Comment #1
killes@www.drop.org commentedPrevious patch was incomplete
Comment #2
aclight commentedI briefly tested this patch and it did not completely break the site. I was able to disable secure pages and then re-enable it. I realize this isn't much of a review, but I'm testing on a live production site, so best not to try to break it too much.
Also, I would change
to
Comment #3
gordon commentedThanks for this, and I am going to be doing this. This patch is a good start but the cookie can still be hijacked.
Since if you go to a http page the cookie will be past and the session can be taken.
What needs to be done is that the session cookie needs to be rewritten to add the secure flag if it is one of the roles or user/1
Comment #4
gerhard killesreiter commentedThe patch has grown a bit, it now also enables the module to work behind a proxy (if somebody backported the proxy patch) and also the user login forms will also POST to https.
I need this patch for various subsites of drupal.org where we want to have admins behind SSL, but not Joe average user.
WRT to session stealing: I am aware of this, there's a patch proposed here:
http://drupal.org/node/170310
The patched module is currently runnign on association.drupal.org.
Comment #5
gerhard killesreiter commentedAlso, I changed the wording as proposed by aclight.
Moreover, I think the session stealing should not affect protected roles since they'll always be behind SSH and the cookie will be regenerated when logging in. Not 100% sure though.
Comment #6
killes@www.drop.org commentedThe patch is still incomplete, as an authenticated user, I still can get to the SSL-less version of the site. Also, my statement about protected user roles is most likely not correct because of this. There's no way how we currently can have two different session.
Comment #7
christefano commentedThere's no need to restrict this to admins only.
Comment #8
vivianspencer commentedIs any news on this patch, I really would love this functionality
Comment #9
grendzy commentedThe 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.