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.
It would be nice to allow the login info to be sent to an https url instead of a plain http url to wrap the login in SSL. I tried it manually and it worked just fine. Logging in via SSL and then redirecting the user back to the regular non-encrypted site works, so there would need to be an option to stay in SSL mode or drop back to unencrypted mode after login.
The admin module also needs a setting to require SSL for that module.
Comment | File | Size | Author |
---|---|---|---|
#94 | 1577-https.patch | 24.47 KB | chx |
#93 | 1577-https.patch | 23.61 KB | chx |
#90 | 1577-https.patch | 23.61 KB | chx |
#86 | 1577-https.patch | 24.47 KB | chx |
#81 | 1577-https.patch | 26.07 KB | boombatower |
Comments
Comment #1
mcking CreditAttribution: mcking commentedComment #2
JonBob CreditAttribution: JonBob commentedComment #3
jamida CreditAttribution: jamida commentedSorry, I'm new here. Is this area for "voting"? If so... I would like this feature. Also apparently lots of others would too. Just search for "https login page" or "ssl login page" and notice all the discussion activity in this area.
SSL for admin is also an excellent idea, but IMHO the main thing there I want encrypted is the user passwords and an SSL login page will provide a work-around for that.
Comment #4
mfbI'd agree this would be a very useful addition. I have used apache redirects to force certain paths to use https:// as the $base_url, but I've noticed issues with some modules when the $base_url varies between http:// and https:// -- e.g. the module cannot get a drupal path from the referer_uri() because a different $base_url was in effect on the previous page.
See bugzilla as an example of a web app with an option to force SSL for user logins.
Comment #5
mfbComment #6
Bèr Kessels CreditAttribution: Bèr Kessels commentedchanged version.
Comment #7
Bèr Kessels CreditAttribution: Bèr Kessels commentedhttp://drupal.org/node/53618 was marked duplicate of this
Comment #8
Bèr Kessels CreditAttribution: Bèr Kessels commentedhttp://drupal.org/node/55785 was marked dupe. I copied the patch in that issue here.
Comment #9
chx CreditAttribution: chx commentedwhat stops this being a contrib module?
Comment #10
deekayen CreditAttribution: deekayen commentedJust adding a comment to subscribe to this thread since that's my patch.
Comment #11
forngren CreditAttribution: forngren commentedhttp://drupal.org/node/65632
Comment #12
drummDoesn't apply.
Comment #13
ChrisKennedy CreditAttribution: ChrisKennedy commentedComment #14
ChrisKennedy CreditAttribution: ChrisKennedy commentedSee http://drupal.org/node/37932 too (long forum post).
Comment #15
bozo-1 CreditAttribution: bozo-1 commentedI haven't found anything so far that wound allow Drupal 5.x to redirect a login request to SSL, so I made a quick (and dirty) hack to user.module :
- adds a "Secure Login" entry in the admin pages, with a checkbox to activate SSL logins and a field to submit the https version of the site's base_url (no automatic grabbing so far)
- if SSL login is activated, prefixes the target URL with the https base_url when login is submitted
That's all (which means in particular that changing a user's password through the user profile page isn't redirected).
The patch can be found here, no warranty implied, blah blah blah. Again, this is for 5.x ONLY, this problem in 4.7.x can adequately be addressed via Apache redirection.
Comment #16
profix898 CreditAttribution: profix898 commented@bozo: Sorry, but new feature patches will never be commited for existing releases - Drupal 5 in this case. I'd be happy to see basic SSL support in Drupal core though.
Comment #17
bozo-1 CreditAttribution: bozo-1 commentedI didn't really mean it as a feature patch (the code would most certainly need some serious review!), it's rather a small workaround.
I shouldn't have posted it in an issue thread, though, my mistake.
Comment #18
agentrickardsubscribing. interested in adding this for /admin access.
Comment #19
Christefano-oldaccount CreditAttribution: Christefano-oldaccount commentedsubscribing
Comment #20
Pedro Lozano CreditAttribution: Pedro Lozano commentedThe way I did it.
Edit file modules/user/user.module
For the login block. In the function user_login_block replace the following line:
'#action' => url($_GET['q'], drupal_get_destination()),
with
'#action' => preg_replace('/^http/', 'https', url($_GET['q'], drupal_get_destination(), null, true)),
That's it for the login block to send its data over SSL.
For the user login page modify the function user_login and add the following code before the return line:
Comment #21
Pedro Lozano CreditAttribution: Pedro Lozano commentedCorrection to my previous post.
The lines should be like:
to avoid getting urls starting with 'httpss' if you already are in ssl.
Comment #22
ddyrr CreditAttribution: ddyrr commentedsubscribing
Comment #23
Leeteq CreditAttribution: Leeteq commentedSubscribing.
Comment #24
Leeteq CreditAttribution: Leeteq commentedRef. my (new) suggestion and others' relevant concerns in the discussion in this duplicate (closed) issue:
http://drupal.org/node/13240#comment-325295
Comment #25
Leeteq CreditAttribution: Leeteq commentedFYI - This issue is also (again) brought up in discussing the next release:
"Drupal 6 usability suggestions":
http://drupal.org/node/141043#comment-229103
Many people are concerned about this. I really hope we can make a better-than-nothing solution for this.
Comment #26
chx CreditAttribution: chx commentedhttp://drupal.org/project/securepages
Comment #27
kkaefer CreditAttribution: kkaefer commentedAfter a brief talk with chx, I decided to reopen this issue. Logging in over SSL is something that is security-critical and that way too few websites use. Inclusion in core (possibly with the option to use an "SSL proxy" like it is offered for many shared hosts) could therefore enhance security.
Comment #28
kkaefer CreditAttribution: kkaefer commentedAfter a brief talk with chx, I decided to reopen this issue. Logging in over SSL is something that is security-critical and that way too few websites use. Inclusion in core (possibly with the option to use an "SSL proxy" like it is offered for many shared hosts) could therefore enhance security.
Comment #29
mfbA related issue I'd like to fix in d7: http://drupal.org/node/170310
Recent versions of drupal make PHP's session.cookie_secure setting difficult to implement (if you use the same hostname for your SSL and non-SSL sites), because they force these sites to use the same session name. If a logged-in user goes back to the non-SSL site, their SSL session cookie will be overwritten and they'll have to login again. This was easily implemented in the past by using different session names for the different sites, but drupal core no longer allows the session name to be customized.
Comment #30
1kenthomas CreditAttribution: 1kenthomas commentedI'd like to pipe in that this is really critical. I see a lot of sites gathering personal info (US Social Security #, birthdate, etc) that, within various legal contexts, need to be securely protected and/or purged at specified intervals. I see no obvious paths to implementations that achieve these requirements, and serious legal liability to Drupal sites if they do not implement secure transactions in these instances... this requirement extends quite a bit beyond just login/admin, to needing to provide SSL encryption on any page that transmits "private" data and/or potentially exposes that data...
Comment #31
Anonymous (not verified) CreditAttribution: Anonymous commentedNew features go to 7.
Comment #32
nationalwind CreditAttribution: nationalwind commentedI wonder how this wasn't put into Drupal 6.x core... It seems many people have been requesting such a feature for five years! I understand there's a lot of features and updates and all to be done with a new release, but this one seems to be among the more important, as it involves critical security for many types of websites, as 1.kentthomas pointed out.
Comment #33
jaharmi CreditAttribution: jaharmi commentedI also think this is important to have. It should also be understood that many Drupal sites are on shared hosting and so there should be some accommodation of such hosts (especially when they provide a per-server SSL certificate shared amongst several accounts).
I think it is also important to consider SSL support for access by XML-RPC or Atom publishing clients.
Comment #34
Leeteq CreditAttribution: Leeteq commentedRef. "I think it is also important to consider SSL support for access by XML-RPC or Atom publishing clients."
Second that.
Comment #35
christefano CreditAttribution: christefano commentedHere's a quote from Robert Douglass' post about WordPress 2.6 features Drupal should have:
Comment #36
jscheel CreditAttribution: jscheel commentedWhat about having a path list for https, so that you can specify it at the path level?
Comment #37
Frameshift CreditAttribution: Frameshift commentedNow that all have chimed in on the need/necessity for this feature... (wait for it...)
When can we expect to see this in Core for 6.x etc...?
(Swerving off topic for a brief second) As far as code train maintenance/feature adds, dels, changes, Are the 5.x, 6.x, actively maintained as separate parallel trains, or does 6 supersede 5 etc.? That is does all maintenance stop on the previous version?
Thanks.
Steve
Comment #38
christefano CreditAttribution: christefano commentedFrameshift, only bug fixes go into the current release (which is 6.x). New features go into the next release (which is 7.x).
Sorry to be short, but end of life questions should be asked elsewhere.
Comment #39
Anonymous (not verified) CreditAttribution: Anonymous commentedRegarding comment #20 it should look like:
Anyway thanks for your tips. A real time saver for me.
Comment #40
CoolDreamZ CreditAttribution: CoolDreamZ commentedSubscribing
Comment #41
maat_fr CreditAttribution: maat_fr commentedHi all,
I have submitted a tiny patch for securepages (6.x) that enforces ssl encryption for forms that include at least one password field :
http://drupal.org/node/346873
hope that can help :)
Maât
Comment #42
ball.in.th CreditAttribution: ball.in.th commentedHi,
I would like to see this feature as well. However, from http://drupal.org/node/286499#comment-1081286, securing just the login/admin page is not enough, a method to prevent or detect session hijacking is also needed.
Comment #43
mfbPHP gives you everything you need to prevent session hijacking, you just turn on the PHP session.cookie_secure flag for your HTTPS virtual host and login via HTTPS. As I mentioned above in #29, there was temporarily a bug in core which made session.cookie_secure a bit of a PITA to use with Drupal, but this has since been resolved.
Comment #44
ball.in.th CreditAttribution: ball.in.th commentedI am under an impression that setting session.cookie_secure flag would be enough if a user stays on HTTPS all the time but would not be enough if he/she drops back to unencrypted mode after login. Of course, a module like Secure Pages (plus a patch which implements this) is needed for the user to be able to switch back and forth between HTTP and HTTPS with a single login.
Comment #45
soxofaan CreditAttribution: soxofaan commentedsubscribing
Comment #46
kkaefer CreditAttribution: kkaefer commentedAs already mentiond in this thread, to really make the site secure, the cookie has to be secure as well. This poses several problems: When the user goes to a non-HTTPS version of the page, it appears as though they are logged out. Additionally, browsing the entire site with HTTPS is problematic from a site performance point of view because requests over HTTPS are a lot slower than unencrypted requests, so users tend to prefer non-secured pages.
Here’s an (incomplete) solution idea:
Comment #47
Damien Tournoud CreditAttribution: Damien Tournoud commented@Konstantin: I think this is the only solution that makes sense, but it would mean changing the permission system quite a bit.
Now that we have a full "permission" array like this:
We could add other values in the permissions, like adding a 'secure' parameter. At the end of the day, the implementation details are probably for the contrib domain. We should only make sure that core has the proper hooks to do that.
Comment #48
kkaefer CreditAttribution: kkaefer commentedTo make this work, we could split up
user_access()
into a function that serves for display-purposes only (e.g. that is queried when the system has to decide whether it displays a link or renders the form) and a function that is called when the activity is actually performed. That way, we could deny to the HTTP session a certain activity while allowing it for the HTTPS user. The HTTP user still sees these links, though. Now we add a redirection system that ensures that actions requiring the HTTPS session to be sent via HTTPS directly.Comment #49
kkaefer CreditAttribution: kkaefer commentedThis is a mockup of a potential user interface
Comment #50
kkaefer CreditAttribution: kkaefer commentedEDIT: I wrote here that Drupal already supports the two different cookie system. While Drupal /does/ support two different cookies, it does not "connect" the http and https session, so you have to log in twice.
Comment #51
chx CreditAttribution: chx commentedThis will need a hook_perm_alter beause it is changing from site to site what permission should be secure. It's a nice security improvement. I think we could simply set a HTTPS only cookie and store the value in $_SESSION and check the value before performing something secure.
Comment #52
chx CreditAttribution: chx commentedTo clarify i see this as posting the login credentials to HTTPS, getting a session cookie which is not restricted for HTTPS and a security token which is restricted to HTTPS. This way.... even if you manage to steal the session cookie, you do not get too far.
Also, I would consider doing every POST to HTTPS. That would simplify vastly coding and maybe that should be the first step before all the permissions magick?
Comment #53
HemangLavana CreditAttribution: HemangLavana commentedsubscribe
Comment #54
neclimdulinterested.
Comment #55
chx CreditAttribution: chx commentedSo here is what we do for Drupal 7:
What I attached works to some extent -- your devsite is presumed to be reachable at the same URL for HTTP and -- and you can log in once. After that, deleting your cookies is in order. I am working on this part. I believe most of this will live in contrib -- as you can see the changes that makes the POST-to-HTTPS-redirect-to-HTTP cycle works are not pretty (nor they are long for the matter).
Comment #57
chx CreditAttribution: chx commentedNo, really, that patch failed? Big surprise :P I need reviews on the session inc parts not the rest.
Comment #58
kkaefer CreditAttribution: kkaefer commentedSame patch as chx', but with an option added to url() to force a URL secure on insecure.
Comment #60
catchSubscribing.
Patch is a little hard to review because it's not rolled with -p.
Also some debug left in:
Comment #61
JohnAlbinI talked to chx about this issue in IRC.
I had never thought about this fix before. Very nice!
Previously, I had only thought about setting a single session cookie when on either HTTP or HTTPS. Of course, that meant if you had a HTTPS “logged in” cookie, you appeared to be suddenly logged off when you switched to HTTP (i.e. you lost all your special privileges until you returned to HTTPS.)
So the idea of setting both a HTTP and HTTPS cookie when you login via HTTPS is elegant. That way a user has the same session identifier regardless of accessing the site via HTTP or HTTPS.
chx also mentioned in IRC about having a checkbox to control this behavior. At first I thought, “well if the user logs in via HTTPS, why would we need a checkbox? it should be the default behavior.” But actually, we also need something in core that says "always use HTTPS for this form if possible". And, of course, core won't know if HTTPS is possible unless we have a checkbox.
I'm envisioning a checkbox for this similar to core's "clean URLs" checkbox; although I don't know if the same is possible with auto-checking HTTPS connections, but it would be nice.
Comment #62
mfbI would just like to make sure all the security implications of this feature are documented (whether in the UI or README). I would say that a site that allows authenticated HTTP access will never be as secure as one that restricts authenticated users to HTTPS.
There will probably always be some privilege escalation vulnerability when an eavesdropper hijacks an authenticated HTTP session. You could prevent the hijacker from carrying out actions that require a POST like changing passwords, editing content or modifying the text formats, but he/she would still be able to access content that is otherwise restricted, view users' private info, etc. Also, some modules (like flag) allow actions to be performed via GET (with an authentication token), so it's not enough to simply force all POST requests to be made via HTTPS.
Another issue is that a form (e.g. login form) on a HTTP URL is not "secure" even if it posts to HTTPS, because the form itself could have been spoofed. It could pass your login credentials to a malicious 3rd party site. This is why various consumer education campaigns have taught people to look for the padlock icon before they enter their password or other personal info.
Comment #63
chx CreditAttribution: chx commentedThose campaigns have failed, check last week news, noone cares about SSL warnings... But anyways, in a followup I want to provide a hook_menu key 'secure' (no UI) to enforce a page is only visible for HTTPS and also some override mechanism in user_access so a contrib can add SSL only permissions too. There won't be a solution that fits everyone -- you are balancing security and performance. Sometimes the only acceptable solution is to make every page for logged in HTTPS, sometimes that's too slow and only a select few pages (flag voting, node/user edit etc) are necessary. The task of core is to provide this two cookie mechanism and enough API/alter points so that every need can be satisfied.
Attached is the work in progress. Needs to honor and document base_(in)?secure_url in settings.php, needs an UI for the https variable and quite probably more comments. I have used (and thought of it myself) konstantin's idea of a secure option for url() albeit using a different implementation.
Comment #64
kkaefer CreditAttribution: kkaefer commentedmfb, please see #43
Comment #65
chx CreditAttribution: chx commentedTo test for real, make your webserver answers on HTTP and HTTPS on the same path, ie http://localhost/drupal and https://localhost/drupal . To write a simpletst, add a module that changes the is_https global. Finally we need a very simple UI that allows flipping on the "log in to HTTPS" feature. Adding an alter to drupal_goto would be cool as well.
Comment #66
Charles BelovOur secure and non-secure URIs have different host names. The path portion is the same, e.g.,
http://www.sfmta.com/cms/home/sfmta.php
vs.
https://sfmta.securesites.net/cms/home/sfmta.php
Comment #67
chx CreditAttribution: chx commentedToo bad! This approach wont work for you. The session cookie domains dont overlap, there is nothing I can help you with.
Also, having such a shared certificate (*.securesites.net, MYNAMESERVER LLC) is ... well, nearlyfreespeech called this "on a level of cheesiness of 1-10 this is 14". I agree.
Comment #68
catchI like this approach, and the hook_menu() definition means if you need more security, you can add it easily enough.
Comment #69
boombatower CreditAttribution: boombatower commentedFixed an issue with a warning due to a missing global line and added a settings page.
Lets see what the bot thinks...I'm working on a test.
Comment #70
boombatower CreditAttribution: boombatower commentedShould include patch.
Comment #72
boombatower CreditAttribution: boombatower commentedComment #74
boombatower CreditAttribution: boombatower commentedHad a ton of fun figuring out why session handling got an edge case...but turned out the default value of ssid was '' and should be NULL due to MySQL index.
Merged in #547594: Provide a hook_drupal_goto_alter().
Comment #75
chx CreditAttribution: chx commentedThe patch now is stricly API only. We provide a https option on urls, a hook_drupal_goto_alter and a #https on top form elements. The only thing that is a bit missing ia menu addition but that's really a followup and not even strictly necessary as that's already doable from contrib but it still worths considering. We provide the double cookie handling and these APIs and that's it. I do not want to provide a UI for this for two reasons. One, what and needs to be forced to HTTPS (all logged in users? admin users? POST requests? The checkout page even for anonymous?) are varying too widely so I let contrib build on the APIs we provide. Two, if we provide an UI and one sets up to log in on HTTPS and HTTPS is not available (and checking that is quite hard) then she will be locked out and hard. No point in going there.
Comment #77
boombatower CreditAttribution: boombatower commented'absolute' => TRUE
was removed from drupal_goto() when chx and where going through it...and so it was comparing a relative URL to an absolute URL.
very nice tests...they catch everything.
Comment #79
boombatower CreditAttribution: boombatower commented- Removed debug.
- Removed unused global $is_https from url().
- Corrected issue with redirect only working on servers with https...which mine does since I am manually testing as well (of course). Bot does not so I turned it off locally and got this to fail and figured out how to "hack" in session_test.module using the new hook_drupal_goto_alter().
Comment #80
catchThe comment says it's checking that the form is secure, but the assertion confirms that it's not secure, which one is it?
We usually just do Implement hook_form_FORM_ID_alter(). without referencing the form itself.
goto should be go to.
One of the test classes has phpdoc, the other doesn't. Can't remember what the standard is but one must be wrong. Shouldn't it also be DrupalGotoTestCase?
None of these have phpdoc and the only other documentation of what's being tested here is in the assertion text itself.
No documentation.
Oh nice!
This review is powered by Dreditor.
Comment #81
boombatower CreditAttribution: boombatower commentedGood comments.
A lot of problems with the merged patch :).
Corrected everything...and an issue found by cwgordon7...I commented out // exit. in https.php for debug.
Comment #82
Dries CreditAttribution: Dries commented- It would be great to have some higher level documentation about how to make a page secure, how to make a form secure, maybe an example or two, as well as any disclaimers that kkaefer pointed out. That would help patch review, but it would also make it slightly easier to evaluate the DX of the proposed API changes.
- So, it is not clear from the documentation what happens when I declare the login block form as secure. Does that mean that the form API would force all pages that have the login block to become secure, or just the follow-up page. Looking at the code, it sounds like it might only be the follow-up page. If so, it is unclear what other API changes are required, and what that means for the elegance and DX experience if we want to make the form entry page protected too. Until then, maybe we should focus on securing individual pages rather than forms? There seems to be little value in securing forms if you don't secure the form entry page. (Maybe I misunderstood the code and/or maybe that last assessment is wrong.)
- I need to give the two session approach some more thought. Technically, it looks elegant, but I'm trying to think through possible side effects. It could result in having to complicate other pieces of Drupal that depend on there being a one to one mapping of sessions and an active user. I can't think of anything at this point though, so we might be good.
- I still want to look at the code a bit closer.
Comment #83
chx CreditAttribution: chx commentedWhat do you mean by form entry page? If you make the login form #https TRUE then the POST request will go to the HTTPS page and two Set-cookies will be issued. So if you altered all forms to #https TRUE , then you need to have the HTTPS cookie to change anything. You will be able to see the forms with just the insecure cookie, yeah. Once again, HTTPS pages can be very costly to produce, hence this idea of protecting just POST.
Comment #84
boombatower CreditAttribution: boombatower commentedHaving two session cookies is necessary to maintain any sort of security between HTTP and HTTPS. I am not sure if that is what you are referring to my "two session approach", because it doesn't generate two sessions, just two session cookies.
/me is still ecstatic that we were able to write a test for this without requiring HTTPS to be enabled on the testing server.
Comment #86
chx CreditAttribution: chx commentedJust a reroll to keep up with HEAD.
Comment #89
catchComment #90
chx CreditAttribution: chx commentedComment #92
kkaefer CreditAttribution: kkaefer commentedCan you describe the main changes between patches?
Comment #93
chx CreditAttribution: chx commentedsupposedly none. obviously i left out https.php.
Comment #94
chx CreditAttribution: chx commentedD'oh!
Comment #95
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD.
Comment #97
Charles Belov#67 chx wrote:
Actually, I don't send the public to the secure server; it is for internal use only. Therefore, budgetary considerations - we are a government agency with a deficit - override cheesiness concerns.
If all site and administration updates are only made in secure mode, then I'm not sure why I would care about session cookies being transferrable between secure and insecure modes. Agency staff would have to go to secure mode when they wanted to update the Web site, so why would they need cookies in insecure mode? (I'm a Drupal newbie and suspect I am missing something here.)
Comment #98
dwwGlad to see this made it in, although it's still got a bunch of problems. See #607008-18: Fix bugs in https support and force using https for authorize.php if available for more info (and a patch that fixes lots of them). We still desperately need a UI for this. See #616744: Add a UI for if the site supports https for more on that.
Comment #99
YK85 CreditAttribution: YK85 commentedHello, I was wondering if Secure Pages module will be needed in Drupal 7 with this feature in core?
Thanks!
Comment #100
bkosborneSorry for posting to an old thread. Does this patch still apply? I'm new to drupal and trying to secure my site because I'm using ubercart. The final patch seems to have cleared testing - do I apply it to the Secure Pages module?
Comment #101
AlexisWilke CreditAttribution: AlexisWilke commentedbkosborne,
It was applied to Drupal 7. I would imagine that you are using Drupal 6 if you consider creating an e-Commerce site. This does not apply to D6.
Alexis Wilke
P.S. for Drupal 6, you may want to look at http://drupal.org/project/securepages which has had similar problems as discussed in this issue.