On Tue, 30 Jul 2002, Ryan Cuprak wrote:
> Date: Tue, 30 Jul 2002 21:58:30 -0400
> From: Ryan Cuprak <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: Security and Struts
>
>
> Hello,
>
> I have been looking into using a filter Servlet (implementing Filter
> interface) to screen incoming requests however in Sun's api, the doFilter
> receives a ServletRequest and not a HttpServletRequest. The
> HttpServletRequest of course has the getSession where I can retrieve (if it
> exists) the login information previously stored there. I did some
> introspection and discovered in tomcat that the ServletRequest object that
> is returned is of type 'HttpServletRequest' but am unsure if this is a safe
> assumption to make. The documentation on the Sun site stated that the filter
> interface could be used for authentication but if one does not have access
> to the session information I don't see how.
In practice, every ServletRequest you get is really an HttpServletRequest
(at least if it came in via HTTP :-), so you can simply cast it to
HttpServletRequest without problems.
> The reason I am not using container authentication or the built-in role
> capabilities is because my setup is much more complicated and needs to be
> stored in a relational database (there are desktop apps which also will key
> off this information etc.)
>
One thing to look at if you're using Tomcat is whether you can configure
JDBCRealm to talk to the same database tables that your other apps do --
either because they conform to the same table structure that JDBCRealm
wants (the actual table and column names are configurable, though), or
because you can create a view in your DBMS for Tomcat's view of the world.
There's an equivalent capability (JNDIRealm) if your data is in an LDAP
based directory server instead.
> -Ryan
Craig
>
> On 7/30/02 3:33 PM, "Joe Barefoot" <[EMAIL PROTECTED]> wrote:
>
> >
> > A third option is to use a ServletFilter to do the same. This has the
> > advantage of sitting outside of the Struts framework, so you can enforce
> > security on other (non-Struts) Servlets and resources if you have them.
> > Check out the Servlet 2.3 API and tech. articles for info on ServletFilters.
> > You would have to come up with your own declarative role-resource mapping
> > configuration in this case, but that is not too difficult. Just use an XML
> > file that maps URLs to allowed role names.
> >
> > Finally, Container-managed authentication/authorization is okay, but it is
> > application-server specific and would have to be modified for any port to
> > another container.
> >
> >
> > peace,
> > Joe
> >
> > -----Original Message-----
> > From: Ryan Cuprak [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, July 30, 2002 11:53 AM
> > To: [EMAIL PROTECTED]
> > Subject: Security and Struts
> >
> >
> >
> > Hello,
> > I was hoping someone would have some advice on securing a website using
> > struts. I am developing a webapp that has to be secure (password protected)
> > and which restricts access to different parts of the site depending on the
> > roles a user possesses. The roles each user has are stored as XML in a
> > database and may be configured by an administrator. Does struts have any
> > built-in security capabilities that I could take advantage of?
> >
> >
> > Any help/pointers would be much appreciated!
> >
> > My first guess would be to put all jsp pages in WEB-INF (use only
> > ForwardAction to get to each page) and subclass ActionServlet with the logic
> > for check authentication etc. However, will this cause any problems when it
> > comes to a user book marking a page?
> >
> > Thanks,
> > -Ryan Cuprak
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
