Form-based authentication doesn't rely on the browser for any more than the session id. Still it's not perfect either but it's a whole lot more secure - up to the point where you get session-hijacking etc.
On 04/05/2004 09:47 AM Joe Hertz wrote:
Actually, I was thinking about the situation where someone deleted me off of a Mailman list (a whole \'nuther story, that one!), but neglected the fact I had access to the web archives (thanks to a session cookie I had already obtained) for as long as my browser remained open (weeks).
I suppose it\'s reasonable to set the session to expire after an hour, and double check in places where it \"really\" matters, but as a general rule, I hate the idea of trusting the browser to be authoritative about data the browser cannot possibly be authoritative about.
When I saw this happen with a reasonably commonly deployed piece of software which employed the whole session cookie \"blessing of the user\" concept, I decided to start being real anal about this philopsophy.
-Joe
-----Original Message-----
From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Sunday, April 04, 2004 1:30 PM
To: Struts Users Mailing List
Subject: Re: Frequently Performed Action Tasks
Go round to his house \'n reprogram his computer with an axe? ;)
My systems have never been so closely watched that this was a use-case which cropped up.
I assume you are talking about some sort of public forum or BB where the administrator of the users is a seperate person to the server administrator? i.e. he / she can\'t go in and restart the app to boot everyone off?
On 04/04/2004 06:12 PM Joe Hertz wrote:
Adam,
What would you do if someone suspended this user while he
was logged
in?
-Joe
-----Original Message----- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Sunday, April 04, 2004 6:12 AM To: Struts Users Mailing List Subject: Re: Frequently Performed Action Tasks
Hey Joe,
why don\'t you put the whole user bean in the session? I do.
It\'s not so big that it causes problems under heavy load.
You could then have a simple checkUser() in your base class
that checks if the session bean is there before calling getUser().
I actually have my checkUser() in a filter. Several of my universal
methods (like this) are in filters, and several are in the
base class.
Adam
On 04/04/2004 11:06 AM Joe Hertz wrote:
I\'m considering doing something, and I\'m trying to decide
if it\'s safe
to do. I\'m sure this particular battle has been fought before. I\'m
curious what the
results are from those who have waged it.
A typical case: At the beginning of your action, you want
to get the
current user\'s record from the database. Say the user id itself is
stored in the
httpSession.
In fact, so typical is this case, it would make sense to have this
always
happen at the beginning of the Action.
My first instinct was to declare an execute() method in my
base Action
class, get the current user\'s User object based upon the user id,
and then do a
super.execute().
Problem is, there\'s no way to pass in the user object I
got got into
super.execute.
So my options appear to be either 1) Call getUser() at the
beginning
of every Action method, or 2) In the base class\' execute() method,
call getUser() and
store the User object in a static ThreadLocal like one of
the example
Hibernate plugins does with the Hibernate Session object.
Is there any good reason not to do the latter (like, fer instance, \"Um, it won\'t work, Joe\")???
Anyway, it just seems like the base class\' execute() method
would be a
good place to call pre-\"guts\" and post-\"guts\" Action code. Is
this the way to go
about it, or is there a better one?
TIA,
-Joe
------------------------------------------------------------
---------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian
------------------------------------------------------------
---------
---------------------------------------------------------------------To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
