Thanks for the replies.
I am still a little confused what would happen if someone opened another browser tab(while logged in to the site correctly) and typed in a URL of a page behind the login page. Because I can't store cookies and there wouldn't be any session ID in the URL wouldn't the page look for authencication again? Wouldn't this annoy the user?
Again, sorry for sounding dumb but I've been looking at this for most of the day and my brain is about to leak out of my eye sockets! | [reply] |
It may annoy the user, but it's the proper behavior (if this is the way you're doing authentication). If all you have to go on is URLs and maybe hidden fields in POSTs, then "another browser tab" is pretty much the same as "another browser" or "a browser on another computer" for all the state it's communicating up to your server.
HTTP doesn't really give you that many levers to pull on for tracking state between requests; it's either in the headers or in the body. "Encoded into the URL" counts as "headers", "hidden field in a POST" counts as "body", and about the only other thing you have is "cookie", which is a header. And cookie is the only one that the browser itself knows anything about between requests.
To me, that boils down to: If you're not able to use cookies, you'll need to figure out a way to spin this "annoyance" as a "feature".
| [reply] |
Just to add to what mcdave said, if you are in an environment where no cookies are allowed then surely your users are aware of this so it's fair enough to tell them that opening a new tab or whatever won't work. I don't really understand why they would do this unless they knew how to construct the correct URL. Maybe they know the IDs of what they are looking for and want to tack that onto the end of the generic URL? If so then if you put the session id parameter before all other parameters in your URLs then the browser's auto-complete function will include it before the bit the user wants to replace - just might work.
| [reply] |
