...

View Full Version : Redirecting without destroying session.



Skippy
06-24-2010, 12:01 AM
Hey,

I have a small problem. I have a script where it'll take the link from the database and redirect it.


<?php
session_start();
require ('connect.php');

if(!isset($_SESSION['username'])){
echo 'Please <a href="login.php">login</a> to access this area!';
}

if(isset($_SESSION['username'])){
//Get Link Code
}
header( "Location:".$_GET['target'] ) ;
exit;
?>

The trouble I have is exit; destroys the session but I need the session to still be there. Is there any way I can redirect without destroying the session?

xGIHavoc
06-24-2010, 12:20 AM
Try calling session_write_close(); before the header for the correct fix and it should work correctly. Alternatively: instead of doing a header to another page, you could have it read the contents of the specified website and keep the website read on the same page. You could also use frames. A header redirect normal stops execution anyways, so it can't be exit.

Keleth
06-24-2010, 12:47 AM
Oh, thats interesting xGIHavoc... I usually have to exit my header redirects to get it to work properly. Regardless, Is that all the code? I've never had a redirect destory a ession, but yah, I'd also recommend session_write_close().

xGIHavoc
06-24-2010, 07:59 AM
A slight misunderstanding, but partially. He said the trouble was from exit, I'm sorry for my bad phrasing ^_^. Certain browsers automatically stop loading information from a page once a header redirect is sent, others DO need an exit from what I am aware of.

Keleth
06-24-2010, 02:55 PM
Yah, that makes sense.

Fou-Lu
06-24-2010, 03:25 PM
I cannot say I've ever had a destruction problem due to a header call.

Regardless of how a browser treats the header, once the script terminates a session will close. Exit or script end will flush the file. If a browser actually redirects before script end (I seem to recall hearing of this issue on some older handheld devices), the script will continue to process until it has been completed or exit is called. In the event that a session file is locked, it should stall the execution of the next attempt until it can be unlocked (until the max execution time is exceeded). Once unlocked, the next script can aquire a lock on it. It will not delete the session. This is why we force a session_write_close. Personally, I haven't had to force this since framesets went out of style.
My immediate assumption is that the session is being passed via get through the PHPSESSID. In this case, the session is not terminated, rather it becomes irretreivable when the user reconnects to your site. You can verify this by simply looking at the address bar, if PHPSESSID exists, either session.use_trans_sid has been enabled or session_id has been added to your links. If you see this, check your cookies to see if a PHPSESSID cookie has been set. If not, that is your problem right there. This can be corrected if your redirecting to your own site by appending your sid on it, but cannot be corrected for offsite redirections. Another potential fault could be the use of session_regenerate_id being called and not able to either: lock the original file, or set a new session cookie. Your error reporting should be enabled to see if this is the case.



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum