Help with sessions please!

[reportingsjr]

Right now I am developing a game and ive run into a major problem! If iframes are refreshed or anything sessions used inside them are destroyed for the iframe, they arent completely destroyed you can use them anywhere else.Also, they are two iframes nested.Why would they be so stupid as to do this?!?! So, any suggestions on what to do?So far, I have tried using the $_GET method on the iframe and carrying it, but this doesnt work at all.I also have this problem with frames, I can only use sessions in my first frame and not my second one .Im sorry but I cant give out the link as of now because its still in major development. Help needed badly and quickly!! Comeon justsomeguy .Thanks!!

[justsomeguy]

I'm not sure, I don't really use frames so I've never run into this. You will probably need to set up some test pages and set and delete things on the different frames and see if you can find a pattern.

[eguru]

why do want to use frames, use CSS instead of it and well that could make things simpler than this.

[reportingsjr]

eguru, no, I couldnt. If you have ever used frames you will see they are evil, but they are the only thing that can do what they do, I couldnt do half the stuff I am with css! You have a wrong perspective on it .I guess I will just have to keep trying , I thought using get would work, it doesnt.

[justsomeguy]

You might rethink sessions, and store the info in a database instead. Or, have a custom session handler that stores your session info in the database. That way when you delete it, it's gone. But the issue might be that the different frames have different sessions. I know that IE, for one, does not use the same session for different browser windows.

[reportingsjr]

Hmmmm, could you help me on this? How would I say, delete it?The issue I am having is saving the name. If I could figure some way to get the name in a session or something like that I have everything else in the database. But what would I keep the name in? A cookie wouldnt work because it doesnt get deleted until your exp. date. , maybe the cookie can be like a day old and is reset every time the user logs on?

[justsomeguy]

If you want to clear the name out of the session, you can set it to the empty string, use unset on it, use session_unregister to unregister the variable from the session, or use session_destroy to end the entire session. Make sure to use session_start before you do anything, and if you are having problems try ending it with session_write_close.But with frames, you may be dealing with timing issues. If you have 2 frames, and one of them unsets the name, the other one might have already read the name by the time that happens. Obviously, if you refresh one frame that changes the session, the other frames that are already loaded will not display the new information until they are reloaded also.

[reportingsjr]

I really need help with this! Maybe I will just have to stick with on frame or something .It does the same thing with cookies!! Cookies get cleared, this makes me mad!!

[justsomeguy]

Try using this function to see if the different frames are using different session IDs:http://www.php.net/manual/en/function.session-id.phpIf they are, then you may need to pass the session ID to the different frames, and use that same function to set it in the frames. If you need to set it, you will need to do so before session_start is called, and before sending any output (so a new cookie can be sent).I also found this:

Session locking (concurrency) notes:As mentioned several times throughout this section on Sessions, the default PHP session model locks a session until the page has finished loading. So if you have two or three frames that load, and each one uses sessions, they will load one at a time. This is so that only one PHP execution context has write access to the session at any one time.Some people work around this by calling session_write_close() as soon as they've finished writing any data to the $_SESSION - they can continue to read data even after they've called it. The disadvantage to session_write_close() is that your code still will lock on that first call to session_start() on any session'ed page, and that you have to sprinkle session_write_close() everywhere you use sessions, as soon as you can. This is still a very good method, but if your Session access follows some particular patterns, you may have another way which requires less modification of your code.The idea is that if your session code <b>mostly</b> reads from sessions, and rarely writes to them, then you can allow concurrent access. To prevent completely corrupted session data, we will lock the session's backing store (tmp files usually) while we write to them. This means the session is only locked for the brief instant that we are writing to the backing store. However, this means that if you have two pages loading simultaneously, and both modify the session, the <i>Last One Wins</i>. Whichever one loads first will get its data overwritten by the one that loads second. If this is okay with you, you may continue - otherwise, use the session_write_close method, above.If you have complicated bits of code that depend on some state in the session, and some state in a database or text file, or something else - again, you may not want to use this method. When you have two simultaneous pages running, you might find that one page runs halfway through, modifying your text file, then the second one runs all the way through, further modifying your text file, then the first one finishes - and your data might be mangled, or completely lost.So if you're prepared to debug potentially very, very nasty race conditions, and your access patterns for your sessions is read-mostly and write-rarely (and not write-dearly), then you can try the following system. Copy the example from session_set_save_handler() into your include file, above where you start your sessions. Modify the session write() method:<?function write($id, $sess_data){ global $sess_save_path, $sess_session_name; $sess_file = "$sess_save_path/sess_$id"; if ($fp = @fopen($sess_file, "w")) { flock($fp,LOCK_EX); $results=fwrite($fp, $sess_data); flock($fp,LOCK_UN); return($results); } else { return(false); }}?>You will probably also want to add a GC (Garbage Collection) method for the sessions, as well.And of course, take this advice with a grain of salt - We currently have it running on our testing server, and it seems to work OK there, but people have reported terrible problems with the Shared Memory session handler, and this method may be as unsafe as that.You can also consider implementing your own locks for scary concurrency-sensitive bits of your code.

[reportingsjr]

Bah, im so confused! What I got from this was that the frames might be using different session id's, but how do I fix this so they all use the same one. What happens is it works once, then it just gets wiped for that frame. Im guessing it changes the session id every time? (This has iframes that refresh every x seconds)Sooo.. how might I fix this?

[justsomeguy]

The first thing to do is check if they are using different session IDs or not.

[reportingsjr]

Would I just use echo session_id(); for this?

[justsomeguy]

Right, you can also give session_id a parameter to set the session id to something else. See that reference link I posted in post 9.

[reportingsjr]

Yes I read it, so if I set it with session_id(rand(1000000,1000000000)) will it stay that way?

[reportingsjr]

Well, the session ID stays the same.Something happened though with a session. I have it echo you power session in the menu, and after I refresh the page it echos out 'object'

[justsomeguy]

I'm not sure what you're saying. Maybe post your code.

[reportingsjr]

Well, I got another person to start helping me, he already has his own prospering game. So right now we just deleted every game file and restarted, the already has a pre built login and registration system with a few other things, so last night we started working and got the template going . Right now you can register, but thats about it lol. Something is wrong with the layout because of IE though -.- , who would have guessed?