Re: General session questions...
Re: General session questions...
- Subject: Re: General session questions...
- From: Guido Neitzer <email@hidden>
- Date: Tue, 7 Oct 2008 16:22:57 -0600
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).
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.
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!
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.
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
--
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