[PATCH cube signedrequest] Support new protocol version for signed requests coming from a browser

Denis Laxalde denis.laxalde at logilab.fr
Fri Jun 21 09:50:22 CEST 2019

Laurent Wouters a écrit :
> >> The current protocol for signed request requires the use of the Date HTTP
> >> header. Although this works fine for clients that have full control over the
> >> HTTP headers they send, this is not working in the context of web browser where
> >> the Date HTTP headers are forbidden to be programmatically set (and therefore
> >> used in any meaningful way)
> >> https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name
> > I'm a bit surprised that one may want to allow an application to use
> > signed requests from the browser. Can't this be achieve through proper
> > CORS configuration? Can you provide more details on the intended usage?
> The intended use case is be able to execute requests to a cubicweb
> instance from a third site. For example, the cw instance is accessible
> at mydomain.com but my third web application is served from other.com
> (the client is making the requests). In this scenario, CORS indeed need
> to be correctly configured, but the problem I was facing was that the
> cookie handling authentication for cubicweb at mydomain.com is tagged
> with samesite
> (https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#SameSite_cookies),
> thus preventing it being sent by the browser from a web application
> served from other.com.
> Maybe there is a simpler solution, but I did see it.

I honestly have no clue about this. We'd need the opinion of a cookie
specialist :)

> >> To avoid this issue, this changeset introduces a new protocol version that use
> >> custom HTTP headers (X-Cubicweb-Foo) for non-standard, or otherwise forbidden
> >> HTTP headers. Instead of a date, this version of the protocol relies on the
> >> client generating a cryptographically-secured nonce that is passed in a header
> >> and included in the signature computation.
> > I think we'll need a bit more details on the security aspects of this
> > proposal. I'd, for one, appreciate any kind of external references
> > demonstrating that this is a good practice.
> Well, according to this draft from the IETF
> (https://tools.ietf.org/id/draft-cavage-http-signatures-08.html), it
> looks like the Date HTTP header SHOULD be used (noted in § 2.3) so we
> should try to keep it that way. Also in §3, it is noted that there is
> indeed an assumption that the client is able to send a Date header ...
> It looks like that amazon supports a custom header for dates
> (x-amz-date) precisely for this scenario :
> https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html
> at § Time Stamp Requirement.
> So would you think a solution of simply allowing a X-Cubicweb-Date
> header as an alias for Date when it is not present would be OK ? I think
> this solves the above problem and keeps the current protocol
> quasi-unchanged.

This indeed looks convincing and so better. Thanks for the

More information about the cubicweb-devel mailing list