url versus session 3

[deecee]

Right now i use a url to pass variables between pages -- but i want these to die after the person closes their browser -- is a session variable the only way to accomplish this and how do pass a form data via session variables?

<signature>
sometime you just gotta say &quot;WHAT THE @#*% !!&quot;
</signature>

 

[skiflyer]

If you want to keep it after they close the browser you're looking for cookies, sessions will be between pages, but not after closing.

http://www.php.net/manual/en/function.setcookie.php

 

[deecee]

here is the site

http://www.salesincentiveswork.com/index.php

click on register top left and enter what info you want to...assuming you dont enter a username that is already taken you will go to the thank you page (im having an issue with this page displaying email on my other thread right below or above this one). now once you get to that page close the browser and reopen a new browser, start typing in the url and the history will pull up all urls associated with this domain. just go to the register_pass.php one with all your info and it pulls the page up again.

I would rather this not happen and want the user to go to register.php

basically the only way i want someone to go to register_pass.php is if they were sent there from register.php.

<signature>
sometime you just gotta say &quot;WHAT THE @#*% !!&quot;
</signature>

 

[skiflyer]

Gotchya, ok... so first things first...
switch from

<form method=&quot;GET&quot;...>
to 
<form method=&quot;POST&quot;...>

on the page where you enter your information...
then, change any references in register_pass.php from $_GET to $_POST

that'll take care of the information being readily available to people. However, the enterprising individual will be able to still get there by simply writing their own page, which has a form setup to submit to your page. If this is ok by you, you're done... if you want some more protection then... at the very beginning of the register.php page put...

session_start();
$_SESSION['foo']='bar';

and at the top of the register_pass.php page put
session_start();
if ($_SESSION['foo'] != 'bar') {
  die "Stop trying to sneak on my page!";
}

Obviouslly handle it however you want...

the concept here is that form variables can be passed either in the URL or behind the scenes, but either way they're passed clearly as part of the web page request. So even if you hide them from view, a malicious user can go ahead and cheat. Sessions are much better protected, a session_id can be sent with the page request, but the information itself is stored on the server, if the id and the info don't match up, the info isn't available.... there's no way I'm aware of in which they'll be able to spoof the setting of that variable without having access to your server. (That's a seriously oversimplified explanation, but for 2 am I think it gets to the point.)

-Rob

 

[DRJ478]

&quot;Session hijacking&quot; and &quot;Session fixation&quot; are the most common spoofs for sessions. The hikjacking is the more se3rious one.
In short: a malicious user initiates a session with the server and cons an authorized user to authenticate to the server with thar preset (hence 'fixed') session id. The authorized user authenticates and the malicious user continues to use the now authorized fixed session to do whatever he wants...

However, if you are not a financial institution or keep embarassing personal data nobody should be interested so much that they would go through the trouble of setting up such a scheme.

If you POST or GET variables between pages they only live in the the originating form and the HTTP request. If you use GET then keeping the URL bookmarked will also keep the variables. With POST that is not true.

There is no deterministic way to find out when the user closes the browser. When a page is requested using HTTP it is like a phone call - when the page is delivered the server &quot;hangs&quot; up and actually forgets that you've called. With POST and GET you send your values with the request.

Sessions work a bit different. You pass your ID along and the server looks up the stored values for that ticket you have. The server keeps track of the time you last presented your ticket. If the ticket is presented later there is a calculation if the previous access was within the timeout period. If not, it is assumed it is a new session.
The server does not immediately remove the stored session data once the timeout is reached. The garbage cleanup happens when other sessions are accessed.

 

[deecee]

thanks a lot guys this was really helpful


<signature>
sometime you just gotta say &quot;WHAT THE @#*% !!&quot;
</signature>