Re: General session questions...
Re: General session questions...
- Subject: Re: General session questions...
- From: Guido Neitzer <email@hidden>
- Date: Tue, 7 Oct 2008 20:36:25 -0600
On 07.10.2008, at 19:37, Ramsey Gurley wrote:
Lots of sessions aren't a problem as long as you don't have much
data in it (and its default editing context).
I see. So it isn't really a problem unless they are really trying
to be malicious. And at that point you've got a different sort of
problem.
At least that is my experience. Others might have seen other problems.
Well, I'm not terribly concerned about having A session... just
multiple sessions :-) As long as WO handles tab windows and such
correctly, I'm not going to be to concerned about those orphaned
sessions after your statements above.
No, WO cannot do that. Browsers normally keep only one cookie for each
domain and cookie name. So this will never work with any application
server if you don't put session ids in the url. At least with WO you
can do that.
I don't really have anything against sessions. I just try to use
direct actions whenever I can because component actions aren't
bookmark or search engine friendly.
Sessions aren't either. Depends on what you store there.
Now, when the little zombies hang around and prevent my scheduled
restarts from happening... then I like them less. (^_^)
I don't think it's the problem of session, I think it's the problem of
your code. Somewhere there are deadlocks. Do handle ALL exceptions
properly that can happen during direct action calls? Google for that,
there is code out there, that shows how to do that e.g. in
performActionNamed.
If you have a component action based application, the URLs are not
bookmarkable anyways, so I normally store only additional cookies
but still let the session id in the URL.
I'm session URL intolerant. I despise those things. It's the first
thing I do in the session constructor of every new project. Not
only do they nuke your page rank, but try to explain to my mother
why she should _not_ paste her url's into an IM window to show her
new friend from Nigeria what she's about to purchase with her Visa
ultra platinum gold titanium card. I'll just grin and listen. (^_^)
If you rely on page ranking and sessions for a public page, you should
not use sessions. For security reasons the session id might be a way,
but you can also add other cookies to prevent the scenario above.
that session cookie is going to get set on an http page. Sure,
login should happen on an https page, but if the cookie was set on
http... it isn't secure by default, or is it?
Ah? No content is secure in that respect. https handles only encrypted
transfer. Nothing else.
I guess my question is: Are session cookies secure by default if a
certificate is available?
The cookie has nothing to do with a certificate.
I ask, because it is my understanding that even if the entire site
was https, an attacker could still hijack an insecure cookie and
completely defeat my website's security...
Sure. That's exactly what might happen. That's why you can add a user
cookie in the second someone enters the https part. Than only that
browser can proceed inside the https. Then check this:
<http://developer.apple.com/documentation/MacOSXServer/Reference/WO54_Reference/com/webobjects/appserver/WOCookie.html#setIsSecure(boolean)
>
So, I have no idea whether that will do what you want, but maybe it
gives you some hints.
Well thanks for your insight so far Guido! You're always a huge
help, and I do appreciate it :-)
You're welcome. I try, but I have not much experience with cookies.
cug
--
Real World WebObjects Bootcamp at the Big Nerd Ranch:
http://www.bignerdranch.com/classes/real-world_webobjects.shtml
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden