Works fine with php4.4.3, but cannot log in with php5.2.0 enabled on my site5 hosted drupal5.1 site, but also problem with 4.7

php5 activated by having only this line in my .htaccess

AddHandler application/x-httpd-php5 .php

I've been putting printf statements in session.inc and user.module, this is the correct output from my localhost config:

session.inc->sess_read(1): $_COOKIE[session_name()] == rrrc7gcufsi4qht73l6oc19si3
session.inc->sess_read(3): $session ==
user.module->user_login_validate(): $user ==
user.module->user_authenticate(): $user == 0
user.module->user_login_submit(): $user == 1

It seems that with my site5.com hosted site, it never reaches user.module->user_login_validate(). I can't seem to find anything higher up the call stack to see exactly where it fails. Can anyone help?

also reference this thread: http://drupal.org/node/131307

Comments

paddy_deburca’s picture

Hi,

I had a problem when setting up a Drupal site with PHP 5.2. I received the login page and, after logging-in, I got access denied when trying to access content.

The solution to my problem was to replace in the index.php in the sites root directory

drupal_page_footer();

with

drupal_page_footer();
session_write_close();

I believe that this is a problem with PHP - not with Drupal - and should be finxed in a future release of PHP.

I hope this solves your problem,

Paddy.

patrickharris’s picture

I'm on site5, php5.2 (activated via htaccess, just like you), with Drupal 5.1. The login works fine for me at the moment (I did have login problems for a while - but clearing browser's sessions and cookies seemed to fix it).

mixersoft’s picture

Title: User Login bug with Drupal + php5 hosted at www.site5.com » Testing

#1: Tried adding session_write_close() to index.html, but no go. still have the same problem
#2: what site5 server are you on? I wonder if the server or server config makes a difference. I'm on archeron, if that helps. Regardless, there is at least 1 other person having the same problem with site5 as I am.

Curiously enough, I can log-in with php4 enabled, then edit .htaccess to enable php5, then drupal works fine with the session cookie from the php4 login. That is what tells me the php4/5 bug has to be somewhere between login and writing a session cookie.

If someone can tell me what the call stack looks like which invokes user_login_submit(), I can poke around an figure out where it dies.

mixersoft’s picture

Title: Testing » User Login bug with Drupal + php5 hosted at www.site5.com
isaac77’s picture

Title: User Login bug with Drupal + php5 hosted at www.site5.com » Using php5.2 and Drupal 5.1 at site5

I do not seem to have the access problems described above. I am on the "telchines" server at site5.

Here are the steps I took to enable php5:
- installed Drupal 5.1
- created admin user. logged in and out a few times. created a few nodes.
- logged out, cleared browser cache, deleted all cookies
- modified .htaccess directly on the server (ssh'd to the server and edited the file using a text editor from the command line)
-> added AddHandler application/x-httpd-php5 .php as the first line in .htaccess

Everything seems to work fine. The php version is listed as 5.2.0

marcoBauli’s picture

same problem here:

updated to Drupal 5.3 from 4.7.8, but enabling PHP 5.2.0 (AddHandler application/x-httpd-php5 .php in .htaccess) i keep getting a 500 Internal Server Error as soon as i log in.

Tryed the hint at #1 above (session_write_close(); in index.php) but no deal..

cannot get out of this, may anyone shread some light please?

paddy_deburca’s picture

Is there anything in your web server error log?

The server error could be many things, but D5 uses more memory than D4, so it could be a php_memory_limit issue. Have you tried increasing your memory_limit to 24 or 32MB?

Paddy.

nandou’s picture

Save problem, solved for my site (not site5)
see here
http://www.wanderings.net/notebook/Main/SolveDrupal5LoginProblem

marcoBauli’s picture

paddy, thanks man, you made my day

increasing the memory limit got rid of the 500 Internal Error! Jeez, it was so damn simple.. thx!

pfrenssen’s picture

Status: Active » Fixed

According to http://drupal.org/node/131307 this is resolved.

Status: Fixed » Closed (fixed)

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