This is a PR meant to support the addition of two forms of authorization to a single request, that is: application-based authorization (hmac-signed) and user-based authentication (token). Hitherto, endpoints have made use of one or the other, but there has not been the requirement that we use BOTH forms of authorization at once; instead, we have used token-based authentication to generate HMAC urls, which are then submitted token-free to e.g. download a file.
However, a use case has appeared: allowing Magma to control what gets copied into its bucket on metis, while the user determines whether they have access to the file or the bucket in the first place. We therefore need to amend Etna::Auth to allow this possibility.
Previously, both the token and the HMAC signature went into the "authorization" field (which could either be the header named "Authorization" or the param "X-Etna-Authorization" - no, it doesn't work to set one in the header and the other in the param). This means we can't pass in both at the same time. Here, we are instead moving the HMAC signature to the param or header "X-Etna-Signature", allowing us to send the token in the 'Authorization' header.
There are two other less significant changes which make up most of the noise:
Previously request.env['etna.hmac'] would merely be set to true by Etna::Auth. Now it saves the HMAC object instead and makes it available later in the request (allowing the controller, for example, to easily check the id of the signing application and the signature validity).
The TestAuth class is brought closer in line with the Etna::Auth class, and some more helpers are added to allow testing of HMAC features without having to correctly sign things.
This is a PR meant to support the addition of two forms of authorization to a single request, that is: application-based authorization (hmac-signed) and user-based authentication (token). Hitherto, endpoints have made use of one or the other, but there has not been the requirement that we use BOTH forms of authorization at once; instead, we have used token-based authentication to generate HMAC urls, which are then submitted token-free to e.g. download a file.
However, a use case has appeared: allowing Magma to control what gets copied into its bucket on metis, while the user determines whether they have access to the file or the bucket in the first place. We therefore need to amend Etna::Auth to allow this possibility.
The main change in this PR happens here:
Previously, both the token and the HMAC signature went into the "authorization" field (which could either be the header named "Authorization" or the param "X-Etna-Authorization" - no, it doesn't work to set one in the header and the other in the param). This means we can't pass in both at the same time. Here, we are instead moving the HMAC signature to the param or header "X-Etna-Signature", allowing us to send the token in the 'Authorization' header.
There are two other less significant changes which make up most of the noise:
Previously
request.env['etna.hmac']would merely be set totrueby Etna::Auth. Now it saves the HMAC object instead and makes it available later in the request (allowing the controller, for example, to easily check the id of the signing application and the signature validity).The TestAuth class is brought closer in line with the Etna::Auth class, and some more helpers are added to allow testing of HMAC features without having to correctly sign things.