On Thu, Apr 2, 2009 at 10:08 PM, Rahul Saxena < rahul.saxena.cs...@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 <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 >
