Hello
I have been searching with google and other tools for the last couple of hours, and can not find any similar situations.
Problem: Drupal in a multisites configuration, does not seem to be sending cookies to the browser.
Symptom and Steps: I first logged in to https://sub.domain.com/install.php, to get the database populated, etc.. Note that I am using SSL, and a basic auth .htaccess requiring a username and password, to protect the drupal directory. All of that seems to be working fine.
That done, I selected the "create admin account" (or similarly named) link, entered "admin" as the user name, and my email address. When selecting "create account", I was presented with a 403 forbidden error. However, the email with password was sent, and when I entered the username and password, the "create admin account" step was gone from the initial page.
The link to configure the system now generates a 403 and the message "You are not authorized to access this page." if I do not log in. Also, between the time of selecting that link, and actually getting the page, nearly 20 seconds passes for some reason--nothing else it does takes that long. If I attempt to log in from there, it appears that the login is successful, and it attempts to redirect to the page after a successful login, but when it reloads the page it ends up with the same 403.
No cookies are being sent at any point during this process, which is almost certainly my problem.
Environment: Ubuntu Feisty Apache 2 PHP 5 MySQL 5 Drupal 5.1
I checked the sessions table, and do see a single session for admin.
I have not tried this with the "default" installation of Drupal, because I have no intent to use, and therefore have not bothered to configure, that version.
I would appreciate greatly any advice on this issue.
Thanks and regards,
Luke
Perhaps it is related to your PHP configuration? Could you set up another directory to check that out? See if you can run some php that sets session state? Is that within your experience as a developer.
Also I can't help bug notice you indicate a 403 forbidden error. I wouldn't expect this from drupal. Drupal's language normally indicates "Access Denied". It sounds to me like you have a problem in the .htaccess, or apache configuration. This is an apache message not a drupal message that you're receiving?
Is the apache allow overrides directive enabled for this drupal site?
Without seeing the error messages exactly its always hard to tell. So let me know if you think I'm off base.
-----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Luke Sent: Thursday, February 21, 2008 4:55 PM To: support@drupal.org Subject: [support] No Cookies Being Sent with 5.1
Hello
I have been searching with google and other tools for the last couple of hours, and can not find any similar situations.
Problem: Drupal in a multisites configuration, does not seem to be sending cookies to the browser.
Symptom and Steps: I first logged in to https://sub.domain.com/install.php, to get the database populated, etc.. Note that I am using SSL, and a basic auth .htaccess requiring a username and password, to protect the drupal directory. All of that seems to be working fine.
That done, I selected the "create admin account" (or similarly named) link, entered "admin" as the user name, and my email address. When selecting "create account", I was presented with a 403 forbidden error. However, the email with password was sent, and when I entered the username and password, the "create admin account" step was gone from the initial page.
The link to configure the system now generates a 403 and the message "You are not authorized to access this page." if I do not log in. Also, between the time of selecting that link, and actually getting the page, nearly 20 seconds passes for some reason--nothing else it does takes that long. If I attempt to log in from there, it appears that the login is successful, and it attempts to redirect to the page after a successful login, but when it reloads the page it ends up with the same 403.
No cookies are being sent at any point during this process, which is almost certainly my problem.
Environment: Ubuntu Feisty Apache 2 PHP 5 MySQL 5 Drupal 5.1
I checked the sessions table, and do see a single session for admin.
I have not tried this with the "default" installation of Drupal, because I have no intent to use, and therefore have not bothered to configure, that version.
I would appreciate greatly any advice on this issue.
Thanks and regards,
Luke
On Fri, 22 Feb 2008, Metzler, David wrote:
Perhaps it is related to your PHP configuration? Could you set up another directory to check that out? See if you can run some php that sets session state? Is that within your experience as a developer.
Yeah.
Also I can't help bug notice you indicate a 403 forbidden error. I wouldn't expect this from drupal. Drupal's language normally indicates "Access Denied". It sounds to me like you have a problem in the .htaccess, or apache configuration. This is an apache message not a drupal message that you're receiving?
Drupal message. It was indicating "access denied" or similar, but the HTTP code was 403. I should have made that more clear.
Is the apache allow overrides directive enabled for this drupal site?
Yes.
Without seeing the error messages exactly its always hard to tell. So let me know if you think I'm off base.
The impression I'm getting, is that 5.1 is buggy, that I shouldn't be using 5.1, and if I'm going to keep using it, I must resign myself to lynx failing. Links is working, but I really should support lynx as well. So I probably have to upgrade.
Luke
Not that it helps you much, but just so you don't get too bad of an impression with Drupal's stability...
The session based bug, if I recall correctly had to do with particular versions of PHP, I think it was PHP 5.2.x (that's where I ran into it).
Good luck,
Dave
-----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Luke Sent: Friday, February 22, 2008 2:32 PM To: support@drupal.org Subject: Re: [support] No Cookies Being Sent with 5.1
On Fri, 22 Feb 2008, Metzler, David wrote:
Perhaps it is related to your PHP configuration? Could you set up another directory to check that out? See if you can run some php that sets session state? Is that within your experience as a developer.
Yeah.
Also I can't help bug notice you indicate a 403 forbidden error. I wouldn't expect this from drupal. Drupal's language normally
indicates
"Access Denied". It sounds to me like you have a problem in the .htaccess, or apache configuration. This is an apache message not a drupal message that you're receiving?
Drupal message. It was indicating "access denied" or similar, but the HTTP code was 403. I should have made that more clear.
Is the apache allow overrides directive enabled for this drupal site?
Yes.
Without seeing the error messages exactly its always hard to tell. So let me know if you think I'm off base.
The impression I'm getting, is that 5.1 is buggy, that I shouldn't be using 5.1, and if I'm going to keep using it, I must resign myself to lynx failing. Links is working, but I really should support lynx as well. So I probably have to upgrade.
Luke
On Fri, 22 Feb 2008, Metzler, David wrote:
Not that it helps you much, but just so you don't get too bad of an impression with Drupal's stability...
I'm pretty happy with it so far--it just doesn't work with lynx, which unfortunately I require.
The session based bug, if I recall correctly had to do with particular versions of PHP, I think it was PHP 5.2.x (that's where I ran into it).
Bugger. I have 5.2.1. Now that, I really can't upgrade.
I realize that this may be an unanswerable question, but if you know: will upgrading Drupal make much of a difference, if the session issue is the fault of PHP itself?
I guess I should attempt to prove that by writing something to test sessions.
Luke
I decided to go ahead and test the PHP session handling capability outside of Drupal, using lynx as the web browser.
I started with this:
<?php session_start(); if (!isset($_SESSION['count'])) { $_SESSION['count'] = 0; } else { $_SESSION['count'] += 32; }
echo "<html><body>{$_SESSION['count']}</body></html>"; ?>
As I expected, not only did lynx receive a cookie, but the page incremented by 32 every time I reloaded it, as one would expect from this code.
Okay, so not a basic sessions problem between PHP and Lynx.
So then I moved on... I pulled the INI changes from the settings.php file, and added them to the mix:
ini_set('arg_separator.output', '&'); ini_set('magic_quotes_runtime', 0); ini_set('magic_quotes_sybase', 0); ini_set('session.cache_expire', 200000); ini_set('session.cache_limiter', 'none'); ini_set('session.cookie_lifetime', 2000000); ini_set('session.gc_maxlifetime', 200000); ini_set('session.use_only_cookies', 1); ini_set('session.use_trans_sid', 0); ini_set('url_rewriter.tags', '');
Installing those options made no difference--the cookie was still sent to lynx, and the number incremented.
Lastly, I added this, also from settings.php:
if (isset($_SERVER['HTTP_HOST'])) { $domain = '.'. preg_replace('`^www.`', '', $_SERVER['HTTP_HOST']); // Per RFC 2109, cookie domains must contain at least one dot other than the // first. For hosts such as 'localhost', we don't set a cookie domain. if (count(explode('.', $domain)) > 2) { ini_set('session.cookie_domain', $domain); } }
and boom: no cookie, no incrementing number.
So I commented out the identical section in settings.php, as the comments therein suggest, with no joy.
I then tried manually setting the cookie domain, but still no joy.
Back now to square one.
The only thing different between what I ran and what Drupal is running, seems to be the following directive:
ini_set('session.save_handler', 'user');
I would not expect that to be the problem, but my knowledge is limited.
Luke
What's up with your system clock? Time stamp says 10:54pm at 8am.
Luke wrote:
I decided to go ahead and test the PHP session handling capability outside of Drupal, using lynx as the web browser.
I started with this:
<?php session_start(); if (!isset($_SESSION['count'])) { $_SESSION['count'] = 0; } else { $_SESSION['count'] += 32; } echo "<html><body>{$_SESSION['count']}</body></html>"; ?>
As I expected, not only did lynx receive a cookie, but the page incremented by 32 every time I reloaded it, as one would expect from this code.
Okay, so not a basic sessions problem between PHP and Lynx.
So then I moved on... I pulled the INI changes from the settings.php file, and added them to the mix:
ini_set('arg_separator.output', '&'); ini_set('magic_quotes_runtime', 0); ini_set('magic_quotes_sybase', 0); ini_set('session.cache_expire', 200000); ini_set('session.cache_limiter', 'none'); ini_set('session.cookie_lifetime', 2000000); ini_set('session.gc_maxlifetime', 200000); ini_set('session.use_only_cookies', 1); ini_set('session.use_trans_sid', 0); ini_set('url_rewriter.tags', '');
Installing those options made no difference--the cookie was still sent to lynx, and the number incremented.
Lastly, I added this, also from settings.php:
if (isset($_SERVER['HTTP_HOST'])) { $domain = '.'. preg_replace('`^www.`', '', $_SERVER['HTTP_HOST']); // Per RFC 2109, cookie domains must contain at least one dot other than the // first. For hosts such as 'localhost', we don't set a cookie domain. if (count(explode('.', $domain)) > 2) { ini_set('session.cookie_domain', $domain); } }
and boom: no cookie, no incrementing number.
So I commented out the identical section in settings.php, as the comments therein suggest, with no joy.
I then tried manually setting the cookie domain, but still no joy.
Back now to square one.
The only thing different between what I ran and what Drupal is running, seems to be the following directive:
ini_set('session.save_handler', 'user');
I would not expect that to be the problem, but my knowledge is limited.
Luke
Isn't it obvious? I was writing from the future.
On my local system here, I have a buggy version of gpsd, which adjusts the date incorrectly during February. I ran it yesterday to fix the time, and it messed up the date.
Luke
On Sat, 23 Feb 2008, sasha karlik wrote:
What's up with your system clock? Time stamp says 10:54pm at 8am.
Luke wrote:
I decided to go ahead and test the PHP session handling capability outside of Drupal, using lynx as the web browser.
I started with this:
<?php session_start(); if (!isset($_SESSION['count'])) { $_SESSION['count'] = 0; } else { $_SESSION['count'] += 32; } echo "<html><body>{$_SESSION['count']}</body></html>"; ?>
As I expected, not only did lynx receive a cookie, but the page incremented by 32 every time I reloaded it, as one would expect from this code.
Okay, so not a basic sessions problem between PHP and Lynx.
So then I moved on... I pulled the INI changes from the settings.php file, and added them to the mix:
ini_set('arg_separator.output', '&'); ini_set('magic_quotes_runtime', 0); ini_set('magic_quotes_sybase', 0); ini_set('session.cache_expire', 200000); ini_set('session.cache_limiter', 'none'); ini_set('session.cookie_lifetime', 2000000); ini_set('session.gc_maxlifetime', 200000); ini_set('session.use_only_cookies', 1); ini_set('session.use_trans_sid', 0); ini_set('url_rewriter.tags', '');
Installing those options made no difference--the cookie was still sent to lynx, and the number incremented.
Lastly, I added this, also from settings.php:
if (isset($_SERVER['HTTP_HOST'])) { $domain = '.'. preg_replace('`^www.`', '', $_SERVER['HTTP_HOST']); // Per RFC 2109, cookie domains must contain at least one dot other than the // first. For hosts such as 'localhost', we don't set a cookie domain. if (count(explode('.', $domain)) > 2) { ini_set('session.cookie_domain', $domain); } }
and boom: no cookie, no incrementing number.
So I commented out the identical section in settings.php, as the comments therein suggest, with no joy.
I then tried manually setting the cookie domain, but still no joy.
Back now to square one.
The only thing different between what I ran and what Drupal is running, seems to be the following directive:
ini_set('session.save_handler', 'user');
I would not expect that to be the problem, but my knowledge is limited.
Luke
Yes, it will help it. It has to do with drupal's session save handler not being invoked properly.
Here's a link to an example problem.
I'm not 100% sure the upgrade will solve your problem, since I don't know that drupal has been tested with Lynx, but it's definitely worth a try and a lot better than changing your PHP rev, as you've already pointed out.
Dave -----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Luke Sent: Saturday, February 23, 2008 9:50 PM To: support@drupal.org Subject: Re: [support] No Cookies Being Sent with 5.1
On Fri, 22 Feb 2008, Metzler, David wrote:
Not that it helps you much, but just so you don't get too bad of an impression with Drupal's stability...
I'm pretty happy with it so far--it just doesn't work with lynx, which unfortunately I require.
The session based bug, if I recall correctly had to do with particular versions of PHP, I think it was PHP 5.2.x (that's where I ran into
it).
Bugger. I have 5.2.1. Now that, I really can't upgrade.
I realize that this may be an unanswerable question, but if you know: will upgrading Drupal make much of a difference, if the session issue is the fault of PHP itself?
I guess I should attempt to prove that by writing something to test sessions.
Luke
-
Luke -
Metzler, David -
sasha karlik