ok, let me start over a little bit...
what I meant by the session data getting stored locally is that it is local to the web server, not locally on the client browser. I understand how session variables work. I just said local, and i was thinking server...sorry about that...
what i meant by "no one can spoof it" is that no one knows what session variables are stored with what data that is being used to authenticate that session (ie additional digests to authenticate the request), and none of those variables and values are set in a cookie or in URL's.
Nice article by the way, and I am indeed already using those same methods to secure the user session. (I use SHA1 on the IP,PHPSESSIONID,user agent, and a secret...)
So, it sounds like the only way for it to set a new cookie is by opening a new browser app, which would allow you to send a new cookie different than your other windows, and it doesn't look like I can do that from an existing window, cause it will always send the same cookie...
darn...I guess I'll have to live with that...hmmmm...maybe I can set it on a different cookie path...that might work...
anyways, thanks for the discussion chris.
Tim.
At 08:16 PM 3/8/2004, Chris Shiflett wrote:
--- Tim Traver <[EMAIL PROTECTED]> wrote: > I sent a new session ID with the link to the new window like this : > > <a href="?PHPSESSID=123456789" target="_blank"> > > but all it does is change the current session id to the new one, so if > I go back to the main window, it carries the new session into it.
Yeah, you're only using one browser, so you can only have one set of cookies. To do this, you can't rely on cookies at all, which can be a hassle. Otherwise, the session identifier will always be the most recent one used, because that's what the cookie will reflect (unless you add some logic to do otherwise).
I still think it might be better to approach this with programming logic. As I said, this strategy will work, but it's ugly.
> The reason I'm doing the access control through sessions is so that I > don't have to pass any info in URL's and re-authenticate a user every > time they hit a page.
We're only talking about propagating the session identifier on the URL. This has nothing to do with authentication and everything to do with identification.
> By saving that information locally in session variables, none of that > info gets out, and no one can spoof it.
Yikes, that's a lot of misinformation in one sentence! Cookies are saved locally, and they can make session identifier propagation seem transparent for both the user and the developer. However, just as with URL data, cookies are just something sent along in the request, so they're being provided by the client. So, this information most definitely "gets out".
Sessions are not stored locally; they are stored on the server. It is very important that you understand this, in fact, if you want to implement secure session management. You should leverage this fact to strengthen your mechanism.
Lastly, anyone can spoof this. The session identifier has to be provided by the client, but a secure session mechanism will treat it with some skepticism. Nothing from the client should ever be blindly trusted, which is what I interpret "no one can spoof it" to be suggesting.
I have an article that elaborates much more on this topic that you can read for free:
http://shiflett.org/articles/the-truth-about-sessions
Hope that helps.
Chris
===== Chris Shiflett - http://shiflett.org/
PHP Security - O'Reilly Coming mid-2004 HTTP Developer's Handbook - Sams http://httphandbook.org/ PHP Community Site http://phpcommunity.org/
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
SimpleNet's Back ! http://www.simplenet.com
