Hi guys, You can ensure digest interceptor or filter is executed before the signature one, that digest one adds a property which supports a completion callback and if signature uses digest and the property is there it uses it - else it throws an exception requesting the user to register the digest filter. The only trick is to replace the outputstream in that case to prevent headers writing before it is computed but nothing crazy with interceptors, didnt try with filters.
Le lun. 8 avr. 2019 à 00:33, David Karlsen <[email protected]> a écrit : > Hm - came to think about this again: > * filters always run before interceptors > * Interceptors only run if there is a message-body (and digest only happens > for message-bodies) > > So I guess the most viable option is: > > * have a filter which does signing if no message-body > * have an interceptor which does digest + signing > > Or would it be possible to replace the outputstream in a filter with > a CachedOutputStream and hook into any lifecycle where the entity-body has > been written to it, but not yet streamed onto the wire? > > Also note that the digest is not strictly required by the spec: > https://tools.ietf.org/html/draft-cavage-http-signatures-10#page-8 and as > such should probably be configurable to run or not. > > WDYT? > > > lør. 6. apr. 2019 kl. 12:00 skrev David Karlsen <[email protected]>: > > > I think the signature filter should become a writer interceptor instead: > > > https://access.redhat.com/documentation/en-us/red_hat_jboss_fuse/6.2/html/apache_cxf_development_guide/JAXRS20Filters#JAXRS20Filters-Intro-FigCSFIEP > > It runs later - so that hooking into that phase - any other headers can > be > > set - including the digest one - and then adjust the @Priority of the two > > filters so that digest runs 1st, then signing. > > > > fre. 5. apr. 2019 kl. 12:21 skrev Colm O hEigeartaigh < > [email protected] > > >: > > > >> Hi David, > >> > >> Now that the digest functionality is implemented and tested properly, we > >> need to think about combining it with the signature functionality. I > added > >> an initial test to systests to use both the HTTPSignature filter + the > >> digest interceptor. The test passes, but the filter runs before the > >> interceptor, and so the filter never signs the digest header. > >> > >> We need to either make the interceptor run before the filter, or else > have > >> the interceptor as a "standalone" interceptor just supporting digest, > and > >> instead incorporate the digest functionality into the signature filter > as > >> well. > >> > >> Colm. > >> > >> On Fri, Mar 29, 2019 at 10:55 AM David Karlsen <[email protected]> > >> wrote: > >> > >> > Hi @coheigea - I noticed you are cleaning a bit in the http signature > >> > stuff lately. > >> > > >> > There are a few things I'm wondering about. > >> > > >> > > >> > > >> > https://github.com/apache/cxf/tree/master/rt/rs/security/http-signature/src/main/java/org/apache/cxf/rs/security/httpsignature/filters > >> > There are no ClientRequestInterceptor to do the digest which is > crucial > >> to > >> > the security protocol: > >> > https://tools.ietf.org/html/draft-cavage-http-signatures-10 > >> > > >> > Maybe that should be added as a WriterInterceptor (e.g. quite late in > >> the > >> > chain) - as one of the required headers is the Date header? > >> > > >> > Also - should digest + sign maybe be in one filter - as they go > together > >> > to implement the spec? > >> > > >> > Can the interceptors and filters be made non-final - this allows to > >> extend > >> > them and add additional logic - for instance I'm planning on creating > a > >> > custom annotation @IgnoreSignature to place on certain public > resources > >> - > >> > so that this can be introspected in a filter with ResourceInfo in > order > >> to > >> > determine if signature-checking should be skipped or not - of course > >> this > >> > can be implemented as a delegate pattern - but if they are non-final > it > >> > would be easier. > >> > > >> > Likewise the server-side digest-check and signature check - these > happen > >> > at different phases - could it not be bundled into one filter as the > >> same > >> > applies here. > >> > > >> > WDYT? > >> > > >> > -- > >> > -- > >> > David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen > >> > > >> > >> > >> -- > >> Colm O hEigeartaigh > >> > >> Talend Community Coder > >> http://coders.talend.com > >> > > > > > > -- > > -- > > David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen > > > > > -- > -- > David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen >
