The latest patch is now attached to https://issues.apache.org/jira/browse/DOSGI-67
Thanks, Josh On Sat, Mar 20, 2010 at 4:44 PM, Josh Holtzman <[email protected]>wrote: > Hi David and Sergey. Since the approach looks right, I'll go ahead and > generalize the code for use in other kinds of endpoints, and I'll add the > unit tests and sample code. I should be able to get this done in the next > few days. > > Thanks, > Josh > > > On Sat, Mar 20, 2010 at 11:34 AM, David Bosschaert < > [email protected]> wrote: > >> 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 >> >> > > >>> >> >> > > >>> >> >> > > >> >> >> > > > >> >> > > >> >> > >> >> >> > >> > >
