I also had a look at the patch. While the code looks fine to me I'm concerned that there is no unit tests with it.
David On 19 March 2010 14:54, Sergey Beryozkin <[email protected]> wrote: > Hi Josh > > On Fri, Mar 19, 2010 at 7:09 AM, Josh Holtzman <[email protected]>wrote: > >> Hi Sergey, >> The more I think about this, the more I believe that DOSGi is the right >> place to put in a hook for applying security. The ability to apply >> security >> to the DOSGi endpoints should work regardless of the HttpService >> implementation, IMO. >> >> So, I put together a patch that addresses my needs, and I think would be a >> good addition to the DOSGi project in general. See >> https://issues.apache.org/jira/browse/DOSGI-67 >> >> The basic approach is this: when registering a CxfNonSpringServlet, a >> DelegatingHttpContext is used to handle security (everything else is >> handled >> with the HttpService's default HttpContext). This HttpContext looks for >> any >> Filters registered with a specific property, builds a filterChain of those >> filters, and allows the request to pass only when the filters have had >> their >> chance at returning an HttpServletResponse. >> > > > S.B : I think it is a good patch and agree it can be a very useful > enhancement in general. I'll try to find some time next week to change it a > bit so that all DOSGI endpoints can get the benefit and apply it. IMHO it > should definitely go to 1.2 > > >> >> There's also a switch (BundleContext property >> "org.apache.cxf.rs.httpservice.requirefilter" = true) to force DOSGi >> endpoints to return 403 if there are no filters registered. This way, >> start >> order isn't an issue... DOSGi endpoints only start serving requests when >> the >> security filters are in place. >> >> sounds good > > >> Let me know if you have any concerns about this approach, of if there's >> anything I can do to get this patch into shape. >> > > I have no concerns at all. Hope all DOSGi RI contributors agree this patch > can add some edge to the RI. And if you could at some time add some sample > (by attaching some config, etc to the JIRA) showing how to apply the spring > security to DOSGI endpoints or blog about it then it would be super :-) > > thanks a lot, Sergey > > >> >> Thanks, >> Josh >> >> On Wed, Mar 17, 2010 at 12:06 PM, Sergey Beryozkin <[email protected] >> >wrote: >> >> > Hi Josh >> > >> > apologies for a late response... >> > >> > On Mon, Mar 15, 2010 at 7:17 PM, Josh Holtzman <[email protected] >> > >wrote: >> > >> > > I'm picking up this old thread again in hopes that my use case can be >> > > addressed in CXF. I modified pax-web to look for and, if available, >> use >> > a >> > > custom HttpContext as the default context. I then defined and >> registered >> > > the HttpContext in another bundle. However, CXF isn't able to register >> > > servlets properly using this HttpContext. This might be because that >> > > HttpContext can't properly implement the "public URL getResource(String >> > > name)" method, since it doesn't have access to the right classloader. >> > > >> > >> > S.B : it is probably a better solution, having pax-web checking for a >> > custom >> > HttpContext...But the problem you're seeing with a custom one could show >> up >> > even if CXF detects a custom context, as suggested earlier on. Do you see >> > some stack trace from CXf DSW or paxweb reporting some exception ? >> > >> > >> > > So I'm going to ask my question in a slightly different way in hopes >> that >> > > the details of this experiment don't send us off track: if you needed >> to >> > > apply spring security filters to all DOSGi endpoints, how would you do >> > it? >> > > >> > > >> > S.B. My limited experience with SpringSecurity tells me a CXF servlet >> > should >> > have a Spring security filter for a start, is it possible to set up >> pax-web >> > such that adds a filter to all servlets ? >> > Next, you can probably register a Spring DM context and rely on the >> > URI-related Spring Security configuration >> > >> > Let us know please how it goes on... >> > >> > thanks, Sergey >> > >> > >> > > Thanks, >> > > Josh >> > > >> > > On Thu, Feb 18, 2010 at 10:30 AM, Josh Holtzman < >> [email protected] >> > > >wrote: >> > > >> > > > Checking the osgi service registry for a custom HttpContext makes >> sense >> > > to >> > > > me, but it introduces a startup order problem. If CXF can handle >> that, >> > > then >> > > > we're in good shape. >> > > > >> > > > I'll have a look at pax web to see what I can do there in the >> meantime. >> > > > >> > > > Thanks, >> > > > Josh >> > > > >> > > > >> > > > On Thu, Feb 18, 2010 at 8:35 AM, Sergey Beryozkin < >> > [email protected] >> > > >wrote: >> > > > >> > > >> Hi Josh >> > > >> >> > > >> We've chatted with David a bit about it... >> > > >> Are you actually proposing for CXF DSW to check for a custom >> > HttpContext >> > > >> implementation registered as an OSGI Service ? It would make >> > sense...It >> > > >> would probaly make sense to have an additional list property passed >> > > along >> > > >> during the custom HttpContext registration, which will list custom >> > > >> interfaces (possibly with wildcards) and which CXF DSW will check to >> > > ensure >> > > >> it does not attach a 'foreign' HttpContext to a given servlet >> > > endpoint... >> > > >> >> > > >> In meantime, may be paxweb can let users specify a custom >> HttpContext >> > in >> > > >> the system properties which it will use instead of the default impl >> ? >> > If >> > > it >> > > >> were possible then it could help till the proper fix goes in. >> > > >> >> > > >> Cheers, Sergey >> > > >> >> > > >> >> > > >> DOSGi seems to publish JAX-RS endpoints using a null HttpContext, >> > which >> > > >>> means that the HttpService will create a default context. This >> makes >> > > it >> > > >>> hard to add pluggable authentication handlers using >> > > >>> httpContext.handleSecurity(). Does anyone have suggestions for >> > hooking >> > > >>> into >> > > >>> the request before it's sent to the JAX-RS resource methods? I'd >> > > prefer >> > > >>> to >> > > >>> bind to the OSGI APIs rather than to CXF, and it seems like the >> > > >>> httpContext >> > > >>> should be a good way of doing that. >> > > >>> >> > > >>> If there isn't a convenient plact to hook in, I suppose I'll have >> to >> > > >>> provide >> > > >>> a custom HttpService that overrides >> > > >>> HttpService.createDefaultHttpContext(). >> > > >>> >> > > >>> Thanks, >> > > >>> Josh >> > > >>> >> > > >>> >> > > >> >> > > > >> > > >> > >> >
