Anonymous sessions and $_SESSION

By easyfit on 2 Jan 2009 at 09:26 UTC

It seems like it's not possible to use $_SESSION to store data when the current session is anonymous, but it works fine if it's an authenticated session. Does anyone know why this is and if it's changeable (preferably without changing core code of course)?

Comments

$_SESSION data has nothing

keesje commented 2 January 2009 at 15:57

$_SESSION data has nothing to do with being logged in to Drupal AFIAK. An anonymous session is still a session, it will be lost when closing your browser in most cases (depending on browser and settings).

Your browser establishes a session with the webserver on a specific domain.
Could it be session loss due to domain changes? E.g. www.domain.tld / domain.tld.

Yes that's exactly what I

easyfit commented 5 January 2009 at 07:50

Yes that's exactly what I was thinking as well, it shouldn't matter since even if you're not logged into drupal you're still running a session - it's just an anonymous one from drupals perspective, but I don't see why that should matter for $_SESSION, you should still be able to store things there temporarily. But for some reason you can't, not when the session is anonymous, but you can when you're authenticated by drupal.

So I'm wondering why this is and if there's anyway to change it.

Same problem here

barrya commented 8 January 2009 at 11:25

I'm having exactly the same problem.

Drupal Version 6.8

With an "Anonymous" user I am unable to access $_SESSION

When logged in then I am able to access $_SESSION fine.

I have tried tweaking the settings.php file with different php.ini settings to no avail.

Any other ideas?

Thanks.

I may have fixed my own problem here.

barrya commented 8 January 2009 at 11:48

I had a quick look at sess_read(), function that reads the session information.

It runs a query with a join against the users table. obviously an anonymous user does not have an account, so I assumed this would attempt to makea join against user "0". I took a look in my users table and noticed that there wasn't a user 0. I seem to recall on install this user is created. I recreated this user and it appears to be working fine now.

Hope this fixes your problem, as it has fixed mine.

Fantastic! That seems to be

easyfit commented 21 January 2009 at 08:53

Fantastic! That seems to be the fix! Adding the anonymous user (which apparently I had accidentally removed as well) seems to have fixed the problem. This has been pestering me for a long time so thank you very much barrya!

Small clarification

uhsarp commented 11 February 2010 at 20:40

Small clarification. I have the same problem and what do you guys mean by 'adding anonymous user'?

I've checked my Drupal Mysql's users table. I see an entry for uid with value 0. But the other fields are completely empty. Should I set

name = anonymous
pass = somestring
email=
.
.
.
signature_format=____

Thanks!
Prashu.

Thanks for the Information, Very Helpful!

mpruitt commented 27 October 2009 at 14:14

Hey barrya, just wanted to say thanks for the information in your post. I was having a tough time figuring out why I couldn't use $_Session variables, and while doing research, came across your response. I check my users table, and sure enough, I had deleted user 0 for some reason. Doh!

You can easily loose the #0

keesje commented 28 October 2009 at 09:33

You can easily loose the #0 user entry when moving/migrating database tables by export/import. It happened to me a few times too. Simply add it again.
This is not incidental: http://www.google.nl/search?q=drupal+user+0

Fix and more info: http://drupal.org/node/315830

------------
Handdoek kopen, huishoud textiel online

Good to Know

mpruitt commented 28 October 2009 at 12:16

I don't remember deleting the 0 user, but assumed I did since it wasn't in the user table. This particular database has been exported/imported a number of times on different production and development machines. It's certainly something I'll keep an eye on going forward. I'm adding this little gem of info to my Drupal Notebook on my desk!

Thanks a lot! I was having

jonigual commented 7 September 2010 at 08:53

Thanks a lot! I was having the same problem, you saved my life!

Meeeeeeeeerci!

DanielFbrg commented 21 January 2011 at 16:47

THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU !!!!

thankssssssssssssssssssss

candelas commented 18 May 2011 at 07:53

i was going crazy!!!

//trying to answer one question for each one that i make.
//this way, drupal will be more friendly and strong

Thank You!

lurkerX commented 24 July 2011 at 18:13

Not in a million years and a day would have I figured that one out. Thanks again!

It works!

lmeurs commented 14 March 2012 at 22:04

An allmost empty record showed up when one of my scripts queried the user table. I thought this record was created by mistake, so deleted it. Re-creating solved the problem, I now have to alter the queries in my scripts. Thank you!

Laurens Meurs
wiedes.nl

Edit settings.php

kovalev commented 5 January 2009 at 17:19

You, probably, have to play with /sites/default/settings.php file, in Drupal 6 - around line 140.
I'm talking about this:

....
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.save_handler', 'user');
ini_set('session.use_only_cookies', 1);
ini_set('session.use_trans_sid', 0);
....

You can find some explanations for this, here: http://www.php.net/manual/en/ini.list.php

------------------------------------------------------------------------------------------------------------------------------------
Sergata - פיתוח תוכנה

This can also be a result of caching

PhilDHD commented 5 February 2010 at 22:04

This behaviour can also be caused by drupal caching differently for anonymous and authentucated users). Try disabling caching and see if your session variables persist. If this sloves the problem you can stop caching an individual page by including: $GLOBALS['conf']['cache'] = FALSE;

Different session id's on different pages cause empty $_SESSION

lsiden commented 30 April 2010 at 20:23

My site has a custom front page with a registration form. If the user registers with an existing name/email, the submit callback calls drupal_set_messages('You already have an account. Please log in.') and sends him to /user. However the message is not displayed.

Investigation showed that $_SESSION is empty on the /user page. Then, in sess_read (session.inc) I var_dump($key). The result shows that the session id for the /user page is different than the session id for my custom front page, even though in both cases, the user is the same (uid == 0) and both pages have the same domain.

Can anyone tell me what I might be missing here?

Caching is disabled on my dev server and uid=0 is present in the 'users' table.

I had a different problem,

Sinan Erdem commented 6 January 2012 at 12:32

I had a different problem, and fixed it by disabling cache for my module. I added $GLOBALS['conf']['cache'] = FALSE; in my hook_init.

My module is a multi page form. When the user fill it first time, the variables in the session are correct. But if he fills it immediately again, the old values remained. So, this is fixed by disabling cache.

Thanks...

Problem here was related to caching

jurgenhaas

he/him

German

Gottmadingen

commented 29 November 2010 at 14:43

I've had the very same problem and I thought it was the missing user 0 but it wasn't. Also, the session table contained the expacted values, just that not all pages got delivered as expected.

My problem here was, that the pages I had trouble with got delivered from cache and not individually following different session values. Turning off caching solved the problem.

Well, OK. I now have to find a way to use cache and only produce the pages individually when there is a need according to my session values.