could you help me to apply a patch about ssl connection:

as I'm trying to use SSL for authenticated users (Securing Drupal for authenticated users, http://drupal.org/node/53567 )...

I'm interested in the following patch: session.cookie_secure: SSL cookie gets over-written by non-SSL cookie ( http://drupal.org/node/170310 )

1 - I see that it was initially for drupal 5, may I apply to drupal 6?
in general? how can I understand when a patch is suitable for a certain version of drupal?

2 - how to actually apply it? there are several files, which ones have I to apply? in which order? only the last one or the different versions of the patch?

3 - is there a guide to understand the mechanism of the patches? is it possible to manually copy and paste the code in the target file?

I hope to get the get the general concepts about applying patches

thank you very much


txcrew’s picture

cog.rusty’s picture

If it is for Drupal 5 it probably won't apply to Drupal 6 using the standard patching methods.

You can try to apply it manually. Open the last version of the patch and look at it. The lines with a + in front must be added to the proper place in the /includes/bootstrap.inc file. The lines without a + are there just for context.

From what I can see, in Drupal 6 that should go between lines 331 and 332.

Keep a backup copy of bootstrap.inc just in case that breaks something.
If it works, take a note about this, in case you update Drupal and want to apply it again.

ganymede’s picture

thank you cog.rusty and txcrew, sorry for the delay

I'm trying to do what you suggested (I read part of the handbook and I'm applying the changes manually, because there isn't low correspondence between the patch and my file )

the first attempt had no effects, the second completely broke my local-learning-installation

now I'm re-installing (and this time I'm doing backups at every change... :-) and trying again

I will let you know, maybe I will ask you further help (this stuff is terribly important to me, and I'm not a programmer, so it also relatively difficult)

thank you very much

cog.rusty’s picture

Make sure to use a simple text editor or, if you use anything like MS-Word or Mac's TextEdit make sure to save the modified file as simple ascii text. (I just had to mention it because others have made a mistake there.)

ganymede’s picture

here I am cog.rusty, thank you

I did the key-changes, but it still doesn't work, it would be great if you could read what follows

I started with a clean installation in XAMPP , with clean urls, a sufficient PHP memory, and so on, so the basic installation works fine


1 - I added the php_value session.cookie_secure 1 in htaccess (both for PHP4 and PHP5)
2 - I added $base_url = 'https://localhost'; // NO trailing slash! in settings.php

result of 1 and 2 --> actually it turns to HTTPS when I log-in, it looses the session if I go HTTP, I log-in again and it turns to HTTPS again

3 - I added: if (ini_get('session.cookie_secure')) { $session_name .= 'SSL'; } in bootstrap.inc
as far as I understand it seems the only change to apply in bootstrap, because the previous versions of the patch were discussed, and it seems that the only right version is http://drupal.org/files/issues/cookie_secure_0.patch (or one of its minor modification, in which only the comments are updated)

result of 3 --> it has the same behavior, the additional step 3 has no additional

EDIT: please notice that I see also that every time I go HTTP and again HTTPS, I have a new session cookie (encrypted only) always with the same name (SESS421aa90e079fa326b6494f812ad13e79 for example) but different values for session (I could have a indefinite number of session cookies all with the exact same name, but different values, as follows 73d8a788e3410d3ca100f4ee2fd92230, cf0e2cb6d6ac41ade25f201d366be71e, e5866d601e8b54257b2d299106823eb5, and so on...)

one more question, I don't understand one thing:
at http://api.drupal.org/api/function/conf_init I see that the function is exactly what I get with step 3, so I'm thinking to be on the right way,
but it is different than the file I have when I simply install 6.4 without ony modification: what this means?

thank you very much for your help,


cog.rusty’s picture

I'll only answer the last question for now, because it is easy. As you can see in the following, that was added on August 18


after Drupal 6.4, which came out on August 14


Which means that
(a) it is in the 6.x-dev release, and will be included in 6.5, and
(b) what the patch does is right for Drupal 6.

ganymede’s picture

I got it, so I'm missing something else

in this moment I'm trying to do all the 3 steps at the same time, because I saw that applying for example only the first, then logging in, and finally login again, has different effects than applying both 1 and 2, and then logging in

anyway what you say seems a good news: does that means that when I will go in production (some months) 6.5 will probably be available with correct SSL support?

thanks a lot, your help is precious

cog.rusty’s picture

Obviously correct SSL support was the intention. You could try out 6.x-dev in a test site to know what to expect.

ganymede’s picture

hello cog.rusty, I tried the 6.x-dev version

I did only the two first steps, because .htaccess and settings.php seem not updated, but I get the same result

this situation is becoming difficult for me, I could be forced to use another system because a proper SSL handling is a must-requisite in my situation, very sad about that, because I'm loving drupal (despite the great effort it requires to me)

I hope this topic will become clear for me soon, so I could still come back and continue using drupal

thank you very much again,


mfb’s picture

#170310: session.cookie_secure: SSL cookie gets over-written by non-SSL cookie has already been applied to both Drupal 6 and Drupal 5, although it hasn't yet been released on either branch.

Rather than apply a patch you could just download the patched bootstrap.inc from http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/bootstrap.inc?rev... and drop it into your installation's includes directory.

ganymede’s picture

hello Mark,

thank you very much for your reply,

I followed your advice, but I had some problems to understand the behavior

anyway my manually patched bootstrap.inc, and the one found on the cvs were the same, both in content and in behaviour

now, please consider I'm not a programmer, so let me understand:

what gives me problem is the following code:

  if (ini_get('session.cookie_secure')) {
    $session_name .= 'SSL';

the ini_get() function, as I see at http://it2.php.net/manual/en/function.ini-get.php , Gets the value of a configuration option

does it get the value from the static configuration in .htaccess (where I put php_value session.cookie_secure 1 as said here http://drupal.org/node/53567 ?

but if this value is static, this code would not give the same result when the site is visited in HTTP and in HTTPS?

I would expected something different, for example some php predefined variable related to the server, could be something like here (http://it2.php.net/manual/en/reserved.variables.server.php), I don't know which of them (many could be not affordable)

in this case I could explain to myself why the behaviour is not affected at all, otherwise I'm really missing something else

thank a lot once again, both for your help and your patience

cog.rusty’s picture

Here is an (untested) idea for using both http and https:

- Apply the patch.
- Don't set a $base_url in settings.php
- Don't set php_flag session.cookie_secure 1 in .htacces, because that would affect the non-secure URLs as well.
- Try something like this in settings.php:

$is_secure = (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS']) ? 1 : 0;
ini_set('session.cookie_secure', $is_secure);

I think that should preserve the secure and the non-secure session separately.

Or you might be able to do the last one with two versions of the site, one secure and one non-secure, with separate settings.php files, but then you would need something to identify the two versions of the site, either different domain or subdomain names, or a 443 port specified in the URL of the secure one.

ganymede’s picture

thanks a lot, cog.rusty for your tips,

I can't try your code at this moment, but I wanted to reply to you, to say thanks and also to ask you what do you think about this article from Mike Perry:


he wrote some other interesting things about the subject


I hope to make new tries as soon as possible for the different aspect of this topic, then I will update this thread

cog.rusty’s picture

These look like variations of the same idea that I suggested. And since I haven't given much thought to https and never used it, they are probably more accurate.

ganymede’s picture

oh cog.rusty, I don't know, I really appreciate your contribute, I think it is fundamental, and I appreciate even more just because you gave attention to this topic even if you didn't use HTTPS

thanks again, I will let you know