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 >
