RE: What I'm looking for

Thanks for the long reply. I've been thinking about putting a filter on
/* (like securityfilter does) and using my own persistent cookie to
reconstitute the httpsession (jsessionid cookie) when a user returns in
another browser session. Then the whole webapp can continue using
portable session management and it'll be persisted to the user machine
magically by the simple filter.
 
Then, I start thinking about my own session manager class and start
drooling. :-)
 
 
 
 
-----Original Message-----
From: Max Cooper [mailto:[email protected]] 
Sent: Sunday, December 15, 2002 3:59 AM
To: Bill Ataras; (securityfilter-user
Subject: Re: [securityfilter-user] What I'm looking for
 
Hi Bill,
 
Here's some feedback on the points you listed:
 
1. We have been talking about how nice it would be to have a re-usable
solution for persistent sign-ins. However, at this point in time,
neither container-managed security or SecurityFilter provides this
feature. It may be available in future versions of SecurityFilter.
 
2. SecurityFilter solves this problem. You can link directly to your
login page, or even put a login form on every page in the site.
SecurityFilter will process these "spontaneous" or "unsolicited" login
submittals and send the user to a configurable default page. I would
like to improve the filter to send you back to the page you were on. Or
at least something more flexible than the current implementation of a
single default page. But at least you can login without being forced,
and until we have something better, the single default page might meet
your needs, or at least allow you to write your own system where the
default page would send you somewhere else.
 
3. I think you can create your own Principles with container-managed
authentication on most app servers, and you can definitely do it with
SecurityFilter. The realm interfaces for Tomcat and SecurityFilter allow
you to return whatever kind of Principal you want. I believe other app
servers let you do this, too.
 
Some of these features are under development now with SecurityFilter. If
you can't afford to wait, you might consider extending SecurityFilter to
add your features. There will be a bug fix release in the next week, so
it might be worth waiting for that if you want to stay up-to-date and
not deal with merging your extensions in.
 
The issues you raised are ones that have been a problem for others. The
persistent cookie issue (#1) is one that was discussed earlier this week
on this list, though I must admit I hadn't thought about it as a feature
for SecurityFilter before. #2 is one of the major reasons SecurityFilter
was created. WebLogic actually allows you to send unsolicited login
submittals, but it sends you to a weird place. Tomcat rejects the
request with an error. #3 might not turn out to be a problem, but I am
not really sure without doing some experimentation.
 
-Max
----- Original Message ----- 
From: Bill Ataras <mailto:bill-9m3Y62QHS9/[email protected]>  
To: (securityfilter-user
<mailto:securityfilter-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>  
Sent: Saturday, December 14, 2002 10:55 AM
Subject: [securityfilter-user] What I'm looking for
 
Should have posted this here instead of the forum. Sorry.
 
My problems with container security (I'm new to servlets, but an
experienced programmer) are below. I'm using tomcat 4+. 
 
1. No portable way to make the jsessionid cookie persistent across
browser sessions on the user's machine. Why the hell did the servlet
spec people do that? 
 
2. No way force-sign on a user without sending him to a protected
resource. 
 
3. No portable way to create your own user principle which carries info
beyond name/roles. 
 
I could be wrong about the above. But does this sound right? I'm
thinking of writing my own session manager, using my own cookies and
using a servlet filter to a) protect a tree of resources b) control the
user session cookie c) 'signon' users when and how I like. 
 
Am I the 1st person to encounter this, or the 50,000-th?