tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
Subject Re: Feedback on my project proposal
Date Fri, 03 Apr 2009 05:28:34 GMT
On Thu, Apr 2, 2009 at 10:08 PM, Rahul Saxena <
rahul.saxena.cse06@itbhu.ac.in> wrote:

> As you said "An alternative would be to just define a small interface that
> allows the filter to populate" ,does that mean defining an interface in the
> default context for that host , and the filter can be instantiated using
> servlet context for this default web app(context) and then allow users to
> explicitely define how and where to map these filters........Can't we make
> any arrangement so that the filter could work for all contexts in this
> particular host by default ??


Sure - there are ways to do this, my point is that this is a secondary issue
(IMO).
You could write a FilterToValve bridge for example, and any Filter could be
used
instead of a Valve using current config. Redefining how things are
configured
can be an interesting project, but it's a different one.

Costin


>
>
> On Fri, Apr 3, 2009 at 1:36 AM, Costin Manolache <costin@gmail.com> wrote:
>
> > I wouldn't be that concerned about configuration - tomcat can still
> > instantiate the filter
> > independent of web.xml, like it does with the valve.
> > Or the filter could be used 'user-space', i.e. user adding the filter
> > explicitly and not
> > using the declarative security.
> >
> > One of the problems with tomcat auth interfaces is that it is modeled
> > around
> > 'user database'
> > ( i.e. a store for users/credentials) and pretty tied to basic/form
> models.
> > This also makes the
> > auth implementation quite dependent of tomcat internals.
> >
> > An alternative would be to just define a small interface that allows the
> > filter to populate
> > Principal and hook into 'isUserInRole' ( this can be independent of
> tomcat
> > ). You could
> > do cool stuff like support openID/google/etc authentication, have the
> > credentials on
> > an external server (so a tomcat instance will not have access to the user
> > DB
> > ), etc.
> >
> > The good news is that you could do most of the work without change to
> > tomcat
> > source - just
> > plain filters, you can just extract interesting impl. code from the
> valves.
> > If you get this
> > to work completely user-space ( you can test that by using the filter in
> > jetty for example ), then
> > we can figure out the few HttpServletRequest methods that need extra
> > interaction.
> >
> > Costin
> >
> >
> > On Thu, Apr 2, 2009 at 7:58 AM, Rahul Saxena <
> > rahul.saxena.cse06@itbhu.ac.in
> > > wrote:
> >
> > > It was a mistake I wrote "servlet context of this particular servlet "
> .
> > >
> > > Also as we have default host for a particular engine , we can have a
> > > default
> > > context for a particular host , then pass its servlet context to the
> > filter
> > > , then can we map all servlets in this host to this filter or the
> > servlets
> > > in this particular context only can be mapped ???
> > >
> > > On Thu, Apr 2, 2009 at 3:55 PM, Mark Thomas <markt@apache.org> wrote:
> > >
> > > > Rahul Saxena wrote:
> > > > Could you clarify please? I don't understand your solution.
> > > >
> > > > > If we define a generic servlet for a particular host and then allow
> > > > > servlets(of any application) in that particular host  to implement
> > that
> > > > > generic servlet
> > > > Is "generic servlet" an interface? If so, we have no way of making
> any
> > > > application servlet implement it.
> > > >
> > > > > and then I think we can supply the servlet context of this
> > > > > particular servlet to the correponding filter of that host .....
> > > >
> > > > There is one ServletContext per web application. There isn't one
> > > > ServletContext
> > > > per Servlet.
> > > >
> > > > Mark
> > > >
> > > > >
> > > > > On Wed, Apr 1, 2009 at 4:31 PM, Mark Thomas <markt@apache.org>
> > wrote:
> > > > >
> > > > >> Rahul Saxena wrote:
> > > > >>> I have posted my application on the GSOC site for the project
> > > "Convert
> > > > >>> tomcat valves to filters" , Can anyone give their comment
on the
> > > > >> same.......
> > > > >>
> > > > >> Feedback provided in the GSOC app and repeated below. Feel free
to
> > > > discuss
> > > > >> your
> > > > >> ideas regarding these questions on the dev list.
> > > > >>
> > > > >> Mark
> > > > >>
> > > > >>
> > > > >> Feedback:
> > > > >> Good first draft. There are a couple of areas where I would like
> to
> > > see
> > > > a
> > > > >> little
> > > > >> more information:
> > > > >>
> > > > >>   1. There are many more valves than the 6 you listed.
> > > > >>   2. The filter requires a ServletContext at initialisation.
How
> > might
> > > > you
> > > > >> handle this for a filter defined at the Engine/Host level?
> > > > >>   3. Authentication will require access to Tomcat internals.
Is a
> > > filter
> > > > >> the
> > > > >> right solution for these valves? What might a better approach
be?
> > What
> > > > >> about JSR
> > > > >> 196?
> > > > >>
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > > >> For additional commands, e-mail: dev-help@tomcat.apache.org
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Rahul Saxena
> > > B.Tech Part III
> > > Computer Science and Engineering
> > > I.T. B.H.U. ,Varanasi
> > > Contact No.-09452196645
> > >
> >
>
>
>
> --
> Rahul Saxena
> B.Tech Part III
> Computer Science and Engineering
> I.T. B.H.U. ,Varanasi
> Contact No.-09452196645
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message