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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mcking’s picture

JonBob’s picture

Component: Base system » user system
jamida’s picture

Sorry, 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.

mfb’s picture

Version: » 4.6.5

I'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.

mfb’s picture

Version: 4.6.5 »
Bèr Kessels’s picture

changed version.

Bèr Kessels’s picture

http://drupal.org/node/53618 was marked duplicate of this

Bèr Kessels’s picture

Status: Active » Needs review
FileSize
5.04 KB

http://drupal.org/node/55785 was marked dupe. I copied the patch in that issue here.

chx’s picture

what stops this being a contrib module?

deekayen’s picture

Just adding a comment to subscribe to this thread since that's my patch.

forngren’s picture

chx: what stops this being a contrib module?

http://drupal.org/node/65632

drumm’s picture

Status: Needs review » Needs work

Doesn't apply.

ChrisKennedy’s picture

Version: » 6.x-dev
ChrisKennedy’s picture

See http://drupal.org/node/37932 too (long forum post).

bozo-1’s picture

Version: 6.x-dev » 5.0

I 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.

profix898’s picture

Version: 5.0 » 6.x-dev

@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.

bozo-1’s picture

I 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.

agentrickard’s picture

subscribing. interested in adding this for /admin access.

Christefano-oldaccount’s picture

subscribing

Pedro Lozano’s picture

The 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:

  $form = array(
    '#action' => preg_replace('/^http/', 'https', url($_GET['q'], drupal_get_destination(), null, true)),
  );
Pedro Lozano’s picture

Correction to my previous post.

The lines should be like:

preg_replace('/^http:/', 'https:',

to avoid getting urls starting with 'httpss' if you already are in ssl.

ddyrr’s picture

subscribing

Leeteq’s picture

Subscribing.

Leeteq’s picture

Ref. my (new) suggestion and others' relevant concerns in the discussion in this duplicate (closed) issue:
http://drupal.org/node/13240#comment-325295

Leeteq’s picture

FYI - 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.

chx’s picture

Status: Needs work » Closed (won't fix)
kkaefer’s picture

After 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.

kkaefer’s picture

Status: Closed (won't fix) » Active

After 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.

mfb’s picture

A 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.

1kenthomas’s picture

I'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...

Anonymous’s picture

Version: 6.x-dev » 7.x-dev

New features go to 7.

nationalwind’s picture

I 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.

jaharmi’s picture

I 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.

Leeteq’s picture

Ref. "I think it is also important to consider SSL support for access by XML-RPC or Atom publishing clients."

Second that.

christefano’s picture

Here's a quote from Robert Douglass' post about WordPress 2.6 features Drupal should have:

Better SSL support for the Admin: It should be easy for the (non-technical) admin to have either all of a Drupal site or just the admin and login portions go over https.

jscheel’s picture

What about having a path list for https, so that you can specify it at the path level?

Frameshift’s picture

Version: 7.x-dev » 6.x-dev

Now 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

christefano’s picture

Version: 6.x-dev » 7.x-dev

Frameshift, 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.

Anonymous’s picture

Regarding comment #20 it should look like:

$form['#action'] = preg_replace('/^http:/', 'https:', url($_GET['q'], drupal_get_destination(), null, true));

Anyway thanks for your tips. A real time saver for me.

CoolDreamZ’s picture

Subscribing

maat_fr’s picture

Hi 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

ball.in.th’s picture

Hi,

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.

mfb’s picture

PHP 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.

ball.in.th’s picture

I 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.

soxofaan’s picture

subscribing

kkaefer’s picture

As 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:

  • If SSL mode is enabled, force all logins to HTTPS. This prevents at least password theft (but not session hijacking)
  • The user gets two different session cookies: one for HTTP and one for HTTPS (which is SSL-only).
  • With the HTTP cookie, it only appears to the user as though he has all of the privileges, but actually only has a certain subset of privileges. If the user wants to perform a restricted functionality (one that is not included in the subset), the user is transparently redirected to the HTTPS version of the site. The HTTPS-session has all of the capabilities of the user and can perform said action.
  • This allows the user to surf the site via HTTP while not exposing the session ID that has the actual capabilities; if an attacker would obtain the HTTP-session ID, they still couldn’t perform any critical abilities since they don’t have the SSL-cookie. They can’t sniff the SSL cookie because the connection is encrypted.
Damien Tournoud’s picture

Title: SSL security for login/admin » Mapping privilege separation on non-SSL/SSL

@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:

  'administer content types' => array(
    'title' => t('Administer content types'),
    'description' => t('Manage content types and content type administration settings.'),
  ),

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.

kkaefer’s picture

To 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.

kkaefer’s picture

This is a mockup of a potential user interface

Secure URL:
( ) Disabled
(*) Same URL                 __________________________
( ) Custom URL:     https:// | sslsites.de/foo        |
                             ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
Automatic SSL:
( ) Don't use SSL automatically
( ) Use SSL for all users
(*) Use SSL just for these roles:
     __________________________
     | anonymous user         |
     | authenticated user     |
     | editor                 |
     |█administrator██████████|
     ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

[ ] Require SSL for security-critical actions
kkaefer’s picture

EDIT: 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.

chx’s picture

This 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.

chx’s picture

To 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?

HemangLavana’s picture

subscribe

neclimdul’s picture

interested.

chx’s picture

Status: Active » Needs review
FileSize
9.32 KB

So here is what we do for Drupal 7:

  1. Each session can have two session IDs and consequently two cookies, one SSL only and one normal.
  2. If the user logs in to a HTTPS URL we issue a cookie to the non HTTPS URL.
  3. When on HTTPS, only the secure cookie is used. If only an insecure cookie is present that can only be used to carry on an anonymous session.

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).

Status: Needs review » Needs work

The last submitted patch failed testing.

chx’s picture

Status: Needs work » Needs review

No, really, that patch failed? Big surprise :P I need reviews on the session inc parts not the rest.

kkaefer’s picture

FileSize
10.1 KB

Same patch as chx', but with an option added to url() to force a URL secure on insecure.

Status: Needs review » Needs work

The last submitted patch failed testing.

catch’s picture

Subscribing.

Patch is a little hard to review because it's not rolled with -p.

Also some debug left in:

+  watchdog('test', var_export($_COOKIE, TRUE). $unsecure_sid);
JohnAlbin’s picture

I 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.

mfb’s picture

I 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.

chx’s picture

FileSize
12.77 KB

Those 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.

kkaefer’s picture

mfb, please see #43

chx’s picture

FileSize
12.77 KB

To 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.

Charles Belov’s picture

Our 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

chx’s picture

Too 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.

catch’s picture

I like this approach, and the hook_menu() definition means if you need more security, you can add it easily enough.

boombatower’s picture

Assigned: Unassigned » boombatower
Status: Needs work » Needs review

Fixed 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.

boombatower’s picture

FileSize
14.42 KB

Should include patch.

Status: Needs review » Needs work

The last submitted patch failed testing.

boombatower’s picture

Status: Needs work » Needs review
FileSize
20.36 KB

Status: Needs review » Needs work

The last submitted patch failed testing.

boombatower’s picture

Status: Needs work » Needs review
FileSize
25.15 KB

Had 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().

chx’s picture

The 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.

Status: Needs review » Needs work

The last submitted patch failed testing.

boombatower’s picture

Status: Needs work » Needs review
FileSize
25.61 KB

'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.

Status: Needs review » Needs work

The last submitted patch failed testing.

boombatower’s picture

Status: Needs work » Needs review
FileSize
25.63 KB

- 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().

catch’s picture

Status: Needs review » Needs work
+++ modules/simpletest/tests/session.test	16 Aug 2009 21:17:24 -0000
@@ -250,3 +250,92 @@
+    // Check that password request form action is secure.
+    $this->drupalGet('user/password');
+    $form = $this->xpath('//form[@id="user-pass"]');
+    $this->assertNotEqual(substr($form[0]['action'], 0, 6), 'https:', 'Password request form action is not secure');
+    $form[0]['action'] = $this->httpsUrl('user');

The comment says it's checking that the form is secure, but the assertion confirms that it's not secure, which one is it?

+++ modules/simpletest/tests/session_test.module	16 Aug 2009 21:17:24 -0000
@@ -143,3 +143,20 @@
+ * Implement hook_form_FORM_ID_alter(): user_form.

We usually just do Implement hook_form_FORM_ID_alter(). without referencing the form itself.

+++ modules/simpletest/tests/session_test.module	16 Aug 2009 21:17:24 -0000
@@ -143,3 +143,20 @@
+ * Force the redirection to goto a non-secure page after being on a secure page

goto should be go to.

 /**
+ * Testing drupal_goto and hook_drupal_goto_alter().
+ */

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?

@@ -7,6 +7,58 @@
+function common_test_drupal_goto_redirect() {
+  drupal_goto('common-test/drupal_goto');
+  print t("Drupal goto failed to stop program");
+}
+
+function common_test_drupal_goto_land() {
+  print "drupal_goto";
+}
+
+function common_test_drupal_goto_land_fail() {
+  print "drupal_goto_fail";
+}
+
+function common_test_drupal_goto_alter(&$args) {
+  if ($args['path'] == 'common-test/drupal_goto/fail') {
+    $args['path'] = 'common-test/drupal_goto/redirect';
+  }
+}

None of these have phpdoc and the only other documentation of what's being tested here is in the assertion text itself.

+++ includes/session.inc	16 Aug 2009 21:17:22 -0000
@@ -316,11 +343,18 @@
+function _drupal_session_delete_cookie($name, $force_insecure = FALSE) {

No documentation.

+++ modules/system/system.api.php	16 Aug 2009 21:17:25 -0000
@@ -1975,7 +1975,27 @@
+function hook_drupal_goto_alter(array $args) {
+  // A good addition to misery module.
+  $args['http_response_code'] = 500;

Oh nice!

This review is powered by Dreditor.

boombatower’s picture

Status: Needs work » Needs review
FileSize
26.07 KB

Good 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.

Dries’s picture

- 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.

chx’s picture

What 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.

boombatower’s picture

Having 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.

Status: Needs review » Needs work

The last submitted patch failed testing.

chx’s picture

Status: Needs work » Needs review
FileSize
24.47 KB

Just a reroll to keep up with HEAD.

Status: Needs review » Needs work

The last submitted patch failed testing.

catch’s picture

Status: Needs work » Needs review
chx’s picture

FileSize
23.61 KB

Status: Needs review » Needs work

The last submitted patch failed testing.

kkaefer’s picture

Can you describe the main changes between patches?

chx’s picture

Status: Needs work » Needs review
FileSize
23.61 KB

supposedly none. obviously i left out https.php.

chx’s picture

FileSize
24.47 KB

D'oh!

Dries’s picture

Status: Needs review » Fixed

Committed to CVS HEAD.

Status: Fixed » Closed (fixed)

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

Charles Belov’s picture

#67 chx wrote:

Too 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.

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.)

dww’s picture

Glad 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.

YK85’s picture

Hello, I was wondering if Secure Pages module will be needed in Drupal 7 with this feature in core?
Thanks!

bkosborne’s picture

Sorry 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?

AlexisWilke’s picture

bkosborne,

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.