Re: General session questions...
Re: General session questions...
- Subject: Re: General session questions...
- From: Ramsey Gurley <email@hidden>
- Date: Tue, 07 Oct 2008 21:37:30 -0400
On Oct 7, 2008, at 6:22 PM, Guido Neitzer wrote:
On 07.10.2008, at 15:12, Ramsey Gurley wrote:
If I bookmark the URL for the app when it first loads,
http://host:port/cgi-bin/WebObjects/app.woa
I get a new session anytime I load the page using that bookmark.
Yeah, it's like that. Override the default action request handler to
be the directAction request handler and return a page that will not
create a session if you want to get rid of that.
It seems that would leave me exposed to a very low tech DOS attack.
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.
But conceivably, someone could just sit there clicking a bookmark
over and over and over until my server dragged to a halt with
thousands of sessions in memory.
That's why the startpages of my app are always direct action based
pages.
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.
If I load from browser history, then the session is not generated.
Naturally, if I close the window, reload it with the bookmark and
then go into browser history before that bookmark, I then get
"backtracked too far" error pages. That doesn't seem very
elegant... and it's a potentially huge waste of resources, no?
Depends. You can override that behaviour as you have seen.
I'm using component actions, but I've experienced similar behavior
using direct actions as well.
Only if your direct actions create sessions!
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. Now, when the little zombies hang
around and prevent my scheduled restarts from happening... then I like
them less. (^_^)
And that does solve the initial problem, but I've noticed I also
have numerous zombie sessions that *never* die.
They are probably deadlocked. Get a stacktrace from the application
when you have these hanging sessions and check what it's doing. It
might be an editing context deadlock or a session store deadlock.
But I'm getting off track there... I'm really left wondering how
everyone else addresses this problem, if at all?
I only create sessions if I have to. My startpages and the publicly
available pages are normally direct action based. And only when a
login is confirmed I create a session for that user. But it totally
depends on the situation.
Furthermore, since I'm storing sessions in cookies... sessions do
not seem to fail to generate/automatically expire if the browser
does not accept cookies. Loading a page with cookies disabled just
gives me a session timeout page.
Sure, as your browser does not return the cookie to the app, but a
context id. So the app can't get a session from the store for the
context, which means for the app, that the session has expired.
Where would be a good place to check to see if cookies are
disabled, warn the user that they need to change that, and
terminate the currently useless session?
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. (^_^)
Anyway, it sounds like I can handle that at the application's
handleBadStuffHappened() methods and just ignore the orphaned sessions
and let them expire.
Finally, I also have questions about how sessions are handled from
a security standpoint. How do you go about setting a secure
session cookie? Is there an easy hook for that? I mean, there
doesn't seem to be any point in having a secure login or secure
anything else if the session cookie isn't secure to begin with.
What do you mean by secure cookie? The cookie is transferred via
https if it is that you mean. You can do more by attaching a given
session id to specific logged in user and keep track of that and
validate it always during session awake or so.
For one app I have added a login cookie in addition to the session
id that contains the encrypted user id - if the user of the current
session and that cookie don't match, I throw an exception that is
handled on the application level by showing the appropriate error
page for security related errors.
But it all depends on your situation.
cug
I haven't generated a certificate and tried this, so maybe my concerns
are premature... but I plan on setting a session cookie the moment
visitors hit my page. And that's pretty much always going to be the
case with me. Unless the sessions misbehave, I _like_ sessions. So
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?
I guess my question is: Are session cookies secure by default if a
certificate is available? I know, I should just generate a certificate
and test it, but was hoping you guys could save me that effort until
I'm ready to mess with it :-) 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...
http://fscked.org/blog/fully-automated-active-https-cookie-hijacking
Well thanks for your insight so far Guido! You're always a huge help,
and I do appreciate it :-)
Ramsey
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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