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 ??
On Fri, Apr 3, 2009 at 1:36 AM, Costin Manolache <cos...@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.cs...@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 <ma...@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 <ma...@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-unsubscr...@tomcat.apache.org > > > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > > > >> > > > >> > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: dev-h...@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
