Unauthorized download does not always specify reason

[Michael Nelson]

If the store determines that a client is unable to download a snap, it does not always include enough information for the client to provide useful feedback.

Recently, due to a temporary misconfiguration on a staging charm, the staging store was incorrectly determining that people could not download the core snap, but without sending enough information to the client, the client reported that the staging snap needed to be purchased.

Details: When a client downloads a snap a 401 response can be returned with the WWW-Authenticate header set to 'Macaroon needs_refresh=1', for example, so the client can respond appropriately. But there is also a case where the ACL check may result in a 401 and currently *no* WWW-Authenticate header is set, so clients are unable to give more information. If the store sent an applicable header value for purchase_required or similar, clients could differentiate.

[Ricardo Kirkner (ricardokirkner)]

Given there is a standard http status code for this (402 - Payment required) maybe we should return that for these cases.

[Daniel Manrique (roadmr)]

Would you agree this bug would need:

- Return 402 for when the problem is actually that the snap needs to be purchased.
- Return 401 in other instances, but:
- Ensure the response contains extra details if needed to provide better feedback to humans.

It would also be good to identify the scope of store components which need work for this bug (SCA? CPI?, since that may determine which component needs to generate the HTTP status code.

[Michael Nelson (michael.nelson)]

It's important that the 401 *always* include the WWW-Authenticate header - the store should never be returning a 401 without it (illegal).

As for the 402 - as long as a 402 will be handled gracefully by existing snap clients (can this be brought up in the standup?), otherwise we may need to do a 401 with WWW-Authenticate header for older clients. Great if we can use 402 in that case.

[Facundo Batista (facundo)]

I did a generic search in both SCA and CPI projects, and found that (with the exception of some old click endpoints) every 401 response includes a WWW-Authenticate header.

Of course, as this was a generic search, I may have missed the place where the problem happens.

Could you please specify on which requests to the store you got a 401 response without the WWW-Authenticate header? Extra points for a way to reproduce it.

Thanks!!!

[Michael Nelson (michael.nelson)]

On Sat, Apr 1, 2017 at 4:30 AM Facundo Batista <email address hidden>
wrote:

> I did a generic search in both SCA and CPI projects, and found that
> (with the exception of some old click endpoints) every 401 response
> includes a WWW-Authenticate header.
>
>
Hey Facundo. As per the bug description, this is in updown when a client
downloads a snap, not sca or cpi. See:

servers/u1servers/click_updown/views.py:snap_download

you'll see there that there are multiple places we return a 401 without the
header. The particular case we had the other week was that check_sca_acl()
returns ACLResponse(allowed=False, device_refresh_required=False,
refresh_required=False), basically because the post to SCA did not result
in a 200 response.

[Facundo Batista (facundo)]

Thanks Michael, started to work on this.

[Bret Barker (noise)]

Does this cover the case that came up in https://forum.snapcraft.io/t/error-please-buy-core-before-installing-it/670/6, where the store returned a 401 when the ACL check failed due to not being able to reach dashboard.snapcraft.io? It should return a 500 in that case.

[Facundo Batista (facundo)]

The branch referred here cover the case of CUD not being able to communicate properly with SCA or SCA returning anything except a proper response, yes; in those cases it would return 502.

[Facundo Batista (facundo)]

Tested in staging ok!

$ curl -i -H 'Cache-Control: no-cache' https://public.apps.staging.ubuntu.com/download-snap/d1i2gTMtVjz4jGiN3ppyj6hswwD7WnEA_1.snap
HTTP/1.1 401 UNAUTHORIZED
Date: Fri, 26 May 2017 12:21:10 GMT
Server: TwistedWeb/14.0.2
Vary: X-Click-Token,X-GeoIP-Country-Code,Authorization,X-Device-Authorization
ETag: "d427677f596a94fef6faea0119c4c09b"
X-Bzr-Revision-Number: 7454
Cache-Control: max-age=86400
Content-Type: text/html; charset=utf-8
WWW-Authenticate: Macaroon, Oauth realm="Devportal"
Strict-Transport-Security: max-age=2592000
X-Request-Id: WSgdtn8AAQEAABjCYHoAAAAz1
Transfer-Encoding: chunked

Missing HTTP_AUTHORIZATION or HTTP_X_DEVICE_AUTHORIZATION headers, or oauth parameter in the query