Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Display Session Cookie Quantity??

Status
Not open for further replies.

jwoods7

Technical User
Feb 19, 2003
36
US
I'm having some random issues with my session variables. Let me explain:

I write session variables to the users browser to keep track of who they are for that session (log in/out). Over the last week, my clients have been complaining that it is randomly 'logging them out' although, the logout script is never called. (I know this because I deleted it for testing)

The session variables should last as long as the browser is open, or the session is not destroyed, or the values aren't over-written. However, sometimes even 3 seconds after logging in (and thus setting the session variable value) it won't remember it, and redirect to login page as appropriate.

I know that in all, I only set about a dozen session variables for various things...values, preferences...

I'm thinking the issue may be something with the size limit on these session variables. I've read that a maximum of 300 can be set, or 8k space total...is this true, and how can I verify I'm not somehow going over this limit?

It seems that it is pretty random, thus very tough to troubleshoot. The only consistency I see is if I click around the pages a bunch for testing, doing it fairly quickly, it takes about 30-50 clicks, then logs out (forgets session values). If I login right away again, I only get a few pages at most, then logs out again. I have to wait for a couple mins, then login and it should last for another 30 or so pages (clicks).

If anybody has seen this, or has suggestions they would GREATLY be appreciated. I'm almost at a loss for what is causing it.

Sincerely,

Disheartened and confused
 
Hi,

I think your unlikely to be blowing the cookie limits. I asume that you are using php session and storing things in the $_SESSION array. This means you only store the session ID in the cookie, the variables in file store on the server.

I recall that with later version of PHP4 you should use $_SESSION rather than session_register (???) as it can gets confused (may be it ??)

have a look where your session files are stores (look in php.ini I think it's something like session.save_path) and see if they are disapearing.

Also coulf it be possible that another PHP application is overwrting your session value ?

Sounds an odd one.
Can you post the version and platforms your using please ?, perhaps a sample script as well ?
 
If you have MySQL available change your session handling to be database driven rather than flat files.
Read faq434-2037
It makes things easier to track.

Ingresman is right about the session vars not being in the cookie but server side. Write some pages that dump out the PHPSESSID and see if it changes randomly. That will help to ascertain if the values are overwritten or the session is lost.
 
PHP Info:

I'll include a sample script, but it's more complicated than this so I'm not sure there will be problems with the code. Obviously my login script is not done EXACTLY this way, essentially thats what is happening though.
There are about a dozen Session variables in the real script, all called and reset at various times. However, the only times the login and password variable is reset is on the logout page...that's it. I even took the FlushSession() function out, (cleans session) so nothing would affect them. The really difficult part is that it happens so randomly.


Sample Script:
========================================================

CONFIG.PHP
<?
session_register("login");
session_register("password");

session_start();
>?

LOGIN.PHP
// Set Variable
$_SESSION['login'] = $_POST['login'];
$_SESSION['password'] = $_POST['password'];

?>

SOMEPAGE.PHP
<?
$login = $_SESSION['login'];
$password = $_SESSION['password'];

echo "HELLO, your logged in as $login with password $password";
?>
 
One thing that springs out at me:

You don't need the session_register() invocations here. In fact, the online manual page on session_register() states in one of the caution blocks:

If you are using $_SESSION (or $HTTP_SESSION_VARS), do not use session_register(), session_is_registered(), and session_unregister().


And just to ask the dumb question, you are invoking session_start() in every file that's going to use session variables, right? It's not explicit in your code samples.



Want the best answers? Ask the best questions!

TANSTAAFL!!
 
I guess I should have explained a bit more.

I only added the session_start() after this problem arised and I read about it on the internet. Some people mentioned to have that before every session register. It works without it, and works with it...random problem still occurs, but that appears to not be the cause.

The other VERY important thing I should have mentioned...
To answer your not-so-dumb question:
CONFIG.PHP
<?
session_register("login");
session_register("password");

session_start();
>?

This page is included as the first line in all of the pages. It also includes the database connection strings to connect to the database. That may be of interest because I have always been under the assumption that you need to register and start every time...correct? (well, not start..thats a new addition since the problem started)

I'll take out the session_start() from the config.php code. Nothing seems to change, but if the manual says so...it MUST be the right thing to do. :)
 
Unless in your php.ini you have session.auto_start set to "1" or "on", you must invoke session_start() in each script that will use session variables. The invocation of session_start() must take place at a point in your scripts before the script has produced output.

If every script that is going to use sessions includes config.php, then invoking session_start() from there is fine.

What you don't need is session_register(). If you are manipulating $_SESSION directly (which it appears your code is), then the PHP online manual states you should not be invoking session_register().



Want the best answers? Ask the best questions!

TANSTAAFL!!
 
Interesting. So I only need
session_register("login");
session_register("password");

on the pages or in the functions that call/write/use those variables? I should delete them from the always included config.php page?

OR I should delete all session_register() calls altogether? (not needed)

I always thought that if you needed them on many pages, it's better to put them on an included page like that to ensure spelling and changes are correct. I'm not sure why there would be a difference of having them included on a page or just called when needed...especially because the login is used on every page.
 
You should delete all invocations of session_register(), as they are not needed.

session_register() is used only in the case where you have register_globals turned on and are are going to use singleton variables to reference your session variables. session_register() associates a singleton variable with a session variable. Since you're referencing elements of $_SESSION, you do not need to invoke session_register(). In fact the online manual explicitly states you should not if you are referencing $_SESSION directly.



Want the best answers? Ask the best questions!

TANSTAAFL!!
 
deleted session_register() and session_start()...


everything failed. Wouldn't remember ANY session variables without them...

put them back...whew.
 
Okay, let me try again.......

We are talking about two separate issues here.

First is your code's invocation of session_start(). Your code must, I repeat must, invoke session_start() or sessions will not work. The only exception to this rule is when your php.ini has session.auto_start set to "1" or "On". In short and to be completely explicit, [red]your code must invoke session_start()[/red].


The second issue is your code's invocation of session_register(). Your code shows explicit references to $_SESSION. The PHP online manual states that if you are referencing the elements of $_SESSION, you must not invoke session_register(). In short and to be completely explicit, [red]your code must not invoke session_register() if you are referencing the elements of $_SESSION[/red].


To overstate:

The invocations of session_start() and session_register() are separate but related issues. It is neither necessary nor recommended that you treat the two functions as part of some kind of package that you must use or not use in full. You can and I recommend that you do use one but not the other:[ul][li]Your code [red]MUST[/red] invoke session_start().[/li][li]Your code [red]MUST NOT[/red] invoke session_register().[/li][/ul]



Want the best answers? Ask the best questions!

TANSTAAFL!!
 
Ah, thanks. I'll wait to see if this works...and keep you updated.
Hopefully that was causing the issue!
 
Still getting random session losses...

In response to the post by DRJ478 above:

I have had session session_id() printing the session id as I go along. It's routinely using a new session_id...that must be the problem...however, I'm not sure why.

Check out this page too:

reload the page, a new id comes up every time.

Here is the code for that page

<?
session_start();
echo "<br>ID: $".session_id();
?>


Any ideas?
 
Also, SOMETIMES it remembers the id, keep reloading to eventually watch it change.

It seems to do it more the longer it sits...
 
Not that I know of. Even on that script, it's too simple to be doing anything with the session id.
(i'm assuming your asking if I'm setting the session_id() to a value)

<?
session_start();
echo "<br>ID: $".session_id();
?>

On the example page, that's all I have...and it will randomly show new id's. Is there a possibility that there are too many sessions on the server? (since the info is stored on the server?)
 
It's possible, but unlikely. By default session stores are stored on the server's filesystem -- if your whole filesystem were out of space, it might cause this.



Want the best answers? Ask the best questions!

TANSTAAFL!!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top