Closed (fixed)
Project:
443 Session
Version:
6.x-1.0-beta1
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
11 May 2011 at 22:21 UTC
Updated:
23 Jul 2011 at 04:31 UTC
Some people might want to force HTTP for server resources / SEO reasons.
However, some people might not. There are legitimate use cases where you want to force logged-in users to use HTTPS but leave anonymous people the choice to browse over an encrypted connection. Releases before 1.0-beta1 had that.
I implemented this as an option - but am not very inspired about giving a long description on the reasons to en/disable this, or opinionated on the default value. I just set it to 'off' because then the variable doesn't need to be set.
(This is a radio button only because you used a radio button for another on/off value on the page too. And I could conceivably see extra options, like "only force user agents known to be crawlers, to use HTTP")
| Comment | File | Size | Author |
|---|---|---|---|
| session443_no_force_http.patch | 2.44 KB | roderik |
Comments
Comment #1
dalinCan you shed some light on what these "legitimate reasons are"? I'd rather not make the module more complicated than it needs to be. If you have some special case that realistically only applies to your site then you can call session443_set_page_should_be_secure() from a custom module (see the docbook comments for details).
Comment #2
roderikPeople wearing tin foil hats who think the world is a police state and the NSA is spying on them, basically. I cater to some.
Then again... who's to say what is 'tin foil hat' and what is 'legitimate security concern'? (In The Netherlands, there is currently general concern about mobile telco's using Deep Packet Inspection techniques to determine what data services customers are using, and block some services like Skype. ISPs are looking into data packets, which has people worried - and not all these people are conspiracy theorists. Some are politicians.)
The basic principle is:
HTTPS encryption is meant to protect information inside a connection from prying eyes on the network.
Your module is (seemingly) taking the stand point that only logged-in users may send/receive info that needs this protection. But some people may want to protect e.g. the exact contents of comment/contact forms they fill in on a site, or even their exact browsing history, from e.g. their employer's (potential) data sniffing equipment.
......
but I'll look into your suggestion / the docbook comments sometime, and replace my patch with that.
(I'll need to do more testing to understand everything, anyway -- because on one of my servers, logged-in users going to a HTTP link are automatically redirected to HTTPS again. And on another one, they can just browse HTTP (and appear logged-out) and HTTPS (and appear logged-in again). No idea why :) )
Comment #3
dalinOkay, fair enough. I'll roll your patch in before the next release.
The situation that you describe with authenticated users hitting HTTP is up for discussion here:
#1169166: How to handle authenticated users hitting HTTP pages
Comment #4
dalinWork based on your patch is in the dev version. If you've got time to test it would be much appreciated.
I've actually come completely about face in my opinion of this. I now love the idea. It makes this module the complete HTTPS solution (i.e. it now encompasses everything that Secure Pages module does).
Comment #5
Vc Developer commentedWill this feature be in your D7? I notice the pub date of D7 is Feb 25.
Comment #6
dalinYes. The D6 version is a complete rewrite of the early alphas. First step is to get it stable, then fore-port it to D7.
Comment #7
Vc Developer commentedKewl! :)
Comment #8
roderikWorks for me. Thanks.