GitLab

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

In general, this change enables the specification of a prioritized list of
alternative for headers. In particular for the Date header, this change
specifies a the list ['X-Cubicweb-Date', 'Date'] as an alternative to the Date
header; meaning that when looking for the Date header, one should first look
at the X-Cubicweb-Date header, and then if not present at the Date header. Doing
so, it should be possible to emit signed requests from the context of a browser
by specifying a X-Cubicweb-Date header, overriding the Date header that the
browser may or may not set by itself.

- move cube files to new cube directory
- update setup.py, MANIFEST.in, __pkginfo__.py
- use new import form: "from cubicweb_signedrequest" instead of "from cubes.signedrequest"
- fix wrong imports and make tests pass

We already allow requests in the future for 300 seconds, why not in the past too ?
This avoid a AuthenticationError() when client live in the past for a few seconds.

Requests can now be replayed during 5 minutes in case of MITM but this is
already the case when the client live in the future or server in the past.

In this particular case I think it's ok to trade a bit of security against a
lot of reliability.

Date issues can occur, we want to log them.
We usually send logs >= ERROR to sentry, so using logging.error() here allow to
send such errors to sentry.

This is symmetrical to changeset 84943f333ac0 about tests.

On the one hand, we encode the result of tools.build_string_to_sign()
which will be passed down to tools.authenticate_user() (where hmac.new
call happens); we document that expected value in authenticate_user for
"signed_content" should be bytes. On the other hand, we encode the
"secret_key" value which is retrieved from database (as a unicode
string) before passing it to hmac.new as well.

According to its test suite, cubicweb-signedrequest is now
Python3-compatible.

CubicWeb expects (and asserts, see
CubicWebPublisher.main_handle_request()) an instance of
six.bynary_types.

In _build_string_to_sign(), we return an encoded string. In
_build_signature, we encode the token value extract from the result set.

At the moment, few tests pass on python3. This will improve in following
changesets.

Same test count after/before (28).

On my stretch system, it breaks import of "webob" from "webtest". Also
this is better practice to have isolated tox environment.

This is needed since CubicWeb 3.25, in which the default value for this
setting was turned to False (see 477a59a45786).