By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,784 Members | 1,182 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,784 IT Pros & Developers. It's quick & easy.

session variables 'disappear'

P: n/a
Hi all,

I have a strange problem. I have a login procedure that uses a mysql
database in which the users are stored.
The login procedure is pretty straightforward. In every page I unclude
my session.php.

session.php:

=============

session_start();

// if username and password were specified, fetch them
if (isset($HTTP_POST_VARS['username'])) $entered_username =
$HTTP_POST_VARS['username'];
if (isset($HTTP_POST_VARS['password'])) $entered_password =
$HTTP_POST_VARS['password'];

// check if login is neccesary
if (!isset($entered_username) && !isset($entered_password))
{
// use data from session
if (isset($_SESSION['username']))
{
$login = $_SESSION['username'];
$password = $_SESSION['password'];
}
else
{
// Display error cause we don't have a username
$_SESSION['message'] = $MsgErrAccessDenied;
require("./error.php");
exit;
}
}
else
{
// use entered data

// encrypt entered password
$login = $entered_username;
$password = md5($entered_password);

$_SESSION['username'] = $login;
$_SESSION['password'] = $password;
}

<More code>
============

On one server this works fine. On another one though the session
variables $_SESSION['username'] and $_SESSION['password'] aren't being
stored. I can tell by looking at the session_.... file in /tmp.
On the server where it works it contains the username and password
session vars, on the server where it doesn't work the file is being
created but it's empty. I checked php.ini, comparing the php.ini files
from both servers, especially the settings that have to do with
sessions. Both have the same session settings, but the problem still exists:

session.save_handler = files

session.save_path = /tmp

session.use_cookies = 1

session.name = PHPSESSID

session.auto_start = 1

session.cookie_lifetime = 0

session.cookie_path = /

session.cookie_domain =

session.serialize_handler = php

session.gc_probability = 1

session.gc_maxlifetime = 1440

session.referer_check =

session.entropy_length = 0

session.entropy_file =

session.cache_limiter = nocache

session.cache_expire = 180

session.use_trans_sid = 1

System specs:
=============

Server that works : Solaris 8 intel, Apache 1.3.26, PHP 4.2.2

Server that doesn't work : Linux 2.4.16 (Sun Cobalt), Apache 1.3.20, PHP
4.0.6

Any ideas are welcome.

Kind regards,
Ruben.

Jul 16 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
[snip original posting]

Never mind, I resolved it by upgrading to PHP 4.3.3. I still don't know
the reason of the original problem, but it works anyways now.

Ruben.

Jul 16 '05 #2

P: n/a
Ruben van Engelenburg <ru***@NOSPAMtextinfo.nl> schrieb:
On one server this works fine. On another one though the session
variables $_SESSION['username'] and $_SESSION['password'] aren't being
stored.
[...]
Server that doesn't work : Linux 2.4.16 (Sun Cobalt), Apache 1.3.20, PHP
4.0.6


The superglobal $_SESSION does not exist in 4.0.6.

http://www.php.net/manual/en/languag...predefined.php will give
you more information.

Regards,
Matthias
Jul 16 '05 #3

P: n/a
Matthias Esken wrote:
The superglobal $_SESSION does not exist in 4.0.6.

http://www.php.net/manual/en/languag...predefined.php will give
you more information.


Makes sense indeed. It worked after I upgraded to 4.3.3. Thanks for the
info.

Regards,
Ruben.

Jul 16 '05 #4

P: n/a
On Thu, 11 Sep 2003 01:53:23 +0200, Ruben van Engelenburg
<ru***@NOSPAMtextinfo.nl> wrote:
Matthias Esken wrote:
The superglobal $_SESSION does not exist in 4.0.6.

http://www.php.net/manual/en/languag...predefined.php will give
you more information.


Makes sense indeed. It worked after I upgraded to 4.3.3. Thanks for the
info.

Regards,
Ruben.


Slight change of subject, but only slight - does anyone know when the
PHP developers are going to stop screwing around with variables? I've
had to rewrite the same [expletive deleted] application 3 times now
because they can't leave anything alone! Once more and I recode it in
perl and burn my php manuals.

Mike-

Mornings: Evolution in action. Only the grumpy will survive.
-----------------------------------------------------

Please note - Due to the intense volume of spam, we have
installed site-wide spam filters at catherders.com. If
email from you bounces, try non-HTML, non-encoded,
non-attachments.
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Jul 16 '05 #5

P: n/a
Michael W. Cocke <co***@catherders.com> schrieb:
Slight change of subject, but only slight - does anyone know when the
PHP developers are going to stop screwing around with variables? I've
had to rewrite the same [expletive deleted] application 3 times now
because they can't leave anything alone!


What was the problem? If your code relies on register_globals, then you
can reactivate them.

Regards,
Matthias
Jul 16 '05 #6

P: n/a
On Thu, 11 Sep 2003 18:33:04 +0200, Matthias Esken
<mu************@usenetverwaltung.org> wrote:
Michael W. Cocke <co***@catherders.com> schrieb:
Slight change of subject, but only slight - does anyone know when the
PHP developers are going to stop screwing around with variables? I've
had to rewrite the same [expletive deleted] application 3 times now
because they can't leave anything alone!


What was the problem? If your code relies on register_globals, then you
can reactivate them.

Regards,
Matthias


Register globals was the second rewrite, and I couldn't just turn it
on because that busted another app I use. I honestly don't know what
the current problem is, but re-writing everything to use method=post
solved it. Every time the php module is updated, I have to go
recode... it's getting really old.

Mike-

Mornings: Evolution in action. Only the grumpy will survive.
-----------------------------------------------------

Please note - Due to the intense volume of spam, we have
installed site-wide spam filters at catherders.com. If
email from you bounces, try non-HTML, non-encoded,
non-attachments.
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Jul 16 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.