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 Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Sessions without cookies?
- Thread starter jisoo22
- Start date
sleipnir214
Programmer
PHP can perform session operations without cookies. This is called transparent sid support, in which PHP automatically edits HTML tags in the output stream to add the session id as a part of links.
The PHP online manual states ( URL based session management has additional security risks compared to cookie based session management, which sounds to me like it's less sure, not more secure.
Want the best answers? Ask the best questions: TANSTAAFL!
The PHP online manual states ( URL based session management has additional security risks compared to cookie based session management, which sounds to me like it's less sure, not more secure.
Want the best answers? Ask the best questions: TANSTAAFL!
Have anyone checked if 2 clients behind a routed IP using same SID on the querry string will see them both logged?
I'm just curios of this. i personal belive that cookie should be more secure since you dont have directly acces to it.
________
George, M
I'm just curios of this. i personal belive that cookie should be more secure since you dont have directly acces to it.
________
George, M
- Thread starter
- #4
sleipnir214
Programmer
jis0022:
All cookies are stored on the client, not the server.
A traditional cookie stores both the name of the cookie and the value of the cookie (ignoring all the expiration, domain, etc).
A session cookie is set on the client like a normal cookie, but the value of that cookie is only an index to a datastore on the server. The server software (in our case, PHP) uses that index to fetch the actual session values from the datastore.
Use of session variables is only slightly more secure than a set of regular cookies. Although an intruder does not have direct access to the information that is stored in the session variables, the intruder could steal the session cookie's index value and set up that value on his own machine. Once he connects to your server, the intruder has the ability to manipulate the session store through your server's software.
Also, session cookies by default are set to expire on browser close. Whether this is more secure would likely vary from browser to browser. Some browsers may write temporary cookies to the filesystem somewhere, which will leave tracks, even if the cookie store were deleted.
To enhance the security of session variables, make sure that your software removes unneeded values from the session store.
shaddow:
I don't think I understand your question.
When a browser connects to your server, it sends its cookies before your script is ever invoked by the web server. In the case of PHP, when you issue session_start(), one of the things the session management system does is check if a session cookie has already been sent by the browser. If not, it sends the browser a session cookie and creates a session data store. A variant of this same idea is used then you use sessions with transient SIDs.
If any two browsers present the same session ID, whether they are in the same network or not, then PHP will make the same session values available to scripts invoked by both users.
Want the best answers? Ask the best questions: TANSTAAFL!
All cookies are stored on the client, not the server.
A traditional cookie stores both the name of the cookie and the value of the cookie (ignoring all the expiration, domain, etc).
A session cookie is set on the client like a normal cookie, but the value of that cookie is only an index to a datastore on the server. The server software (in our case, PHP) uses that index to fetch the actual session values from the datastore.
Use of session variables is only slightly more secure than a set of regular cookies. Although an intruder does not have direct access to the information that is stored in the session variables, the intruder could steal the session cookie's index value and set up that value on his own machine. Once he connects to your server, the intruder has the ability to manipulate the session store through your server's software.
Also, session cookies by default are set to expire on browser close. Whether this is more secure would likely vary from browser to browser. Some browsers may write temporary cookies to the filesystem somewhere, which will leave tracks, even if the cookie store were deleted.
To enhance the security of session variables, make sure that your software removes unneeded values from the session store.
shaddow:
I don't think I understand your question.
When a browser connects to your server, it sends its cookies before your script is ever invoked by the web server. In the case of PHP, when you issue session_start(), one of the things the session management system does is check if a session cookie has already been sent by the browser. If not, it sends the browser a session cookie and creates a session data store. A variant of this same idea is used then you use sessions with transient SIDs.
If any two browsers present the same session ID, whether they are in the same network or not, then PHP will make the same session values available to scripts invoked by both users.
Want the best answers? Ask the best questions: TANSTAAFL!
What i mean is that i can place same SID on querrry string and send it to the server from same IP. And since server uses SID for retriving client Session information it should be using same session.
I wonder if this is true.
And ASP can store Session connexion variables, Arrays, etc on the server side not client side
________
George, M
I wonder if this is true.
And ASP can store Session connexion variables, Arrays, etc on the server side not client side
________
George, M
sleipnir214
Programmer
Are you reading my posts at all?
As I said before, if two clients send the same session ID to the server, then both clients will use the same session. This is true whether the session ID is sent via a cookie or via the URL. This is also true whether or not the two clients share the same IP address or not.
PHP stores the session variables and their values on the server side, just like VBScript/ASP. PHP by default sets a session cookie and uses the value of that cookie to know which session store to use on that connection, just like VBScript/ASP. PHP can store singleton variables, arrays, and objects in sessions, just like VBScript/ASP.
Want the best answers? Ask the best questions: TANSTAAFL!
As I said before, if two clients send the same session ID to the server, then both clients will use the same session. This is true whether the session ID is sent via a cookie or via the URL. This is also true whether or not the two clients share the same IP address or not.
PHP stores the session variables and their values on the server side, just like VBScript/ASP. PHP by default sets a session cookie and uses the value of that cookie to know which session store to use on that connection, just like VBScript/ASP. PHP can store singleton variables, arrays, and objects in sessions, just like VBScript/ASP.
Want the best answers? Ask the best questions: TANSTAAFL!
neilyalowitz
Technical User
I'll repeat a question in this thread that I posted elsewhere because this thread seems more relevant:
Is there a way to pass variables between PHP scripts without using cookies and without adding "?var=value" to the URL? It occurred to me to write the variable to a file, but I'm sure there must be a better way than that. I'm concerned with instances where users have cookies disabled. With all of the work that PHP accomplishes on the server-side, I'm suprised at the need for cookies and URL passing.
Is there a way to pass variables between PHP scripts without using cookies and without adding "?var=value" to the URL? It occurred to me to write the variable to a file, but I'm sure there must be a better way than that. I'm concerned with instances where users have cookies disabled. With all of the work that PHP accomplishes on the server-side, I'm suprised at the need for cookies and URL passing.
sleipnir214
Programmer
Actually, you should have started a new thread rather than adding questions to two existing ones. But I'll answer.
The short answer: Yes, but only in very limited circumstances.
The long answer follows.
HTTP is stateless. This means that unlike a desktop application where the application is in constant contact with the user, each and every time a user clicks to a page on a web site, it's as if the browser has communicated to the server for the first time. Netscape invented HTTP cookies to work around this limitation/feature of the protocol.
Keep in mind, too, that since HTTP is stateless, the current session token must be sent to the server each and every time the browser communicates with the server. Otherwise the server has no way to tell my session variables from those of another user.
It's important to know also that there are exactly three ways for data to be transported from a web browser to a web server: HTTP headers (commonly cookies), URL variables (GET-method forms), and data streams (POST-method forms).
In its default configuration, PHP uses cookies to transport the session token back and forth between server and browser. It's quick, easy, and largely transparent to the user.
But if you don't want to or can't use cookies, you can set the php.ini directive "session.use_tran_sid" to "on". PHP can automagically start adding data to links, forms, and other tags (defined in the runtime configuration directive "url_rewriter.tags"
to transport the session token.
When not using cookies, if a PHP script outputs the HTML describing a POST-method form, PHP can automatically add an input of type "hidden" which contains the session ID. This allows sessions without cookies and without URL values.
But suppose you're not using cookies and you are using GET-method form. Then the only way to communicate the session token is on the URL. Even if you add a field to the form, you'll use the URL to transport the values.
Or suppose you're not using cookies and the user clicks on a <A> tag to go to another page in your site. Again, the only way to transport the value is on the URL.
So, if you use nothing but POST-method forms for navigation around your site, then you can use session variables without cookies and without URL values.
As to your second comment. Where are you going to write these files?
On the server? That's what PHP does anyway. But you're still going to need some way to differentiate my session variables from another user's. This means you still have to pass a session token back and forth between the server and the client. Which is what PHP does anyway, either through cookies or tag-rewriting.
On the client? How? And how are you going to insure that the browser transmits this data to the server every time it communicates with your server?
Want the best answers? Ask the best questions: TANSTAAFL!!
The short answer: Yes, but only in very limited circumstances.
The long answer follows.
HTTP is stateless. This means that unlike a desktop application where the application is in constant contact with the user, each and every time a user clicks to a page on a web site, it's as if the browser has communicated to the server for the first time. Netscape invented HTTP cookies to work around this limitation/feature of the protocol.
Keep in mind, too, that since HTTP is stateless, the current session token must be sent to the server each and every time the browser communicates with the server. Otherwise the server has no way to tell my session variables from those of another user.
It's important to know also that there are exactly three ways for data to be transported from a web browser to a web server: HTTP headers (commonly cookies), URL variables (GET-method forms), and data streams (POST-method forms).
In its default configuration, PHP uses cookies to transport the session token back and forth between server and browser. It's quick, easy, and largely transparent to the user.
But if you don't want to or can't use cookies, you can set the php.ini directive "session.use_tran_sid" to "on". PHP can automagically start adding data to links, forms, and other tags (defined in the runtime configuration directive "url_rewriter.tags"
to transport the session token.When not using cookies, if a PHP script outputs the HTML describing a POST-method form, PHP can automatically add an input of type "hidden" which contains the session ID. This allows sessions without cookies and without URL values.
But suppose you're not using cookies and you are using GET-method form. Then the only way to communicate the session token is on the URL. Even if you add a field to the form, you'll use the URL to transport the values.
Or suppose you're not using cookies and the user clicks on a <A> tag to go to another page in your site. Again, the only way to transport the value is on the URL.
So, if you use nothing but POST-method forms for navigation around your site, then you can use session variables without cookies and without URL values.
As to your second comment. Where are you going to write these files?
On the server? That's what PHP does anyway. But you're still going to need some way to differentiate my session variables from another user's. This means you still have to pass a session token back and forth between the server and the client. Which is what PHP does anyway, either through cookies or tag-rewriting.
On the client? How? And how are you going to insure that the browser transmits this data to the server every time it communicates with your server?
Want the best answers? Ask the best questions: TANSTAAFL!!
- Status