I also did a bit of a hack and combined the two interceptors into one, which seems to work:
https://paste.apache.org/D9q4 David, please experiment with both approaches, and see what works best. Colm. On Wed, Apr 10, 2019 at 8:50 AM Romain Manni-Bucau <[email protected]> wrote: > Hi David, > > I can't share the signature/digest code since it is not OS but I did a > quick prototype to try to share the idea: > https://github.com/rmannibucau/signature-digest-cxf-arch > > Hope it makes sense > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le mer. 10 avr. 2019 à 00:21, David Karlsen <[email protected]> a > écrit : > >> Hmm, do you have any example code which does this? >> >> man. 8. apr. 2019 kl. 06:43 skrev Romain Manni-Bucau < >> [email protected]>: >> >>> 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 >>>> >>> >> >> -- >> -- >> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen >> > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
