Skip to content
This repository has been archived by the owner on Jun 11, 2020. It is now read-only.

"Registered for publishing" name always ends as "Unauthorized" [1] #527

Closed
mwinter-osr opened this issue Mar 20, 2017 · 17 comments
Closed
Assignees
Milestone

Comments

@mwinter-osr
Copy link

Trying to build snap with the "build.snapcraft.io".
Registering the project through the github works fine, but then when I try to register the snap name, I always get "Unauthorized". The snap already exists and is registered to my account. But trying to use some new (unregistered) name doesn't work either.
There is no other error - just the "Unauthorized" response.

(This is on repo Github:mwinter-osr/frr-snapcraft-io, trying to register to "frr" snap)

While it is blocking me from using build.snapcraft.io, it is not an urgent issue anymore as I moved to use launchpad directly and all works fine from within launchpad.

@evandandrea
Copy link
Contributor

Hi @mwinter-osr,

When did you try this? I cannot reproduce this, but it sounds like a duplicate of #444 which landed a few days back.

Thanks!

@mwinter-osr
Copy link
Author

In my case, I never managed to register a name at all. I've tried with a name which is registered to me (didn't work) and a name which didn't exist yet (didn't work).

The other scenarios describe all a case where registering a name (at least once) worked.

So I think this is a different issue.

@evandandrea
Copy link
Contributor

I've just tried the following:

  1. Registered a name outside of build.snapcraft.io
  2. Changed my snapcraft.yaml in GitHub to use the new name
  3. Added the repo on build.snapcraft.io

What happened:

  • The repo showed up with the name "not registered"
  • Clicking on "not registered" gave me the option to register with the name from the snapcraft.yaml pre-filled
  • Clicking the sign in button to register the name took me back to the dashboard with the name showing as registered

Are you experiencing something else? What happens when you try with a name that doesn't exist yet? Can you take a screenshot of the error state with the javascript console open?

I'll admit it's confusing that the UI doesn't show the name as registered to you initially. At this early point we just know your GitHub identity. We don't know what account you're registered in the store as.

@mwinter-osr
Copy link
Author

Attached are some screenshots.
One is from before I click the register name and the 2nd from afterwards.

There seems to be a unexpected "401 error" just after logging into the Ubuntu One Account.
I have verified that the login is fine and going to "https://login.ubuntu.com/" even shows me
the last access from build.snapcraft.io" and my snap registered.

One difference (to your description) is that I have previously uploaded the snap directly from
the https://myapps.developer.ubuntu.com/dev/click-apps/ web - so there is already an existing snap.

screen shot 2017-03-21 at 3 39 28 pm
screen shot 2017-03-21 at 3 40 38 pm

@come-maiz
Copy link
Contributor

I'm also getting unauthorized when trying to build ipfs. I already own the ipfs name, so I shouldn't even have to click a button called register.

@bartaz
Copy link
Contributor

bartaz commented Mar 23, 2017

Seems like some issue with macaroons used to authorize API calls to store.

Hard to say much without reproducing it but it looks like macaroons we get after signing in to Ubuntu One are then not accepted by the store when we try to register the name.

@noise
Copy link

noise commented Mar 27, 2017

I encountered this as well, trying to add a new repo and register a new name to go with it, consistently Unauthorized regardless of what name I try to use.

@evandandrea evandandrea added this to the GA milestone Mar 28, 2017
@cjwatson
Copy link
Contributor

cjwatson commented Mar 28, 2017

Could somebody who can reproduce this please use devtools to extract the full content of the 401 response (headers and body) and show it to us? It's possible it won't help much, but it may let us narrow things down a bit.

@ghost ghost changed the title "Registered for publishing" name always ends as "Unauthorized" "Registered for publishing" name always ends as "Unauthorized" [1] Mar 28, 2017
@ghost ghost modified the milestones: Beta launch, GA Mar 28, 2017
@ghost
Copy link

ghost commented Mar 28, 2017

@developer please investigate this issue and timebox it to 1 day. Then please correct the estimate if more work needed, and we can discuss the priority

@earnubs
Copy link
Contributor

earnubs commented Mar 28, 2017

2:08 PM  fgallina: o/ anything about this ring any bells? #527
2:47 PM  beowulf: so, from the report it looks like a 401? that means that it doesn't even get as far as preconditions_check (i.e. checking if the macaroon has package_upload_request or package_upload and agreement and namespace checks) Is the HTTP_AUTHORIZATION passed correctly? are you sure it's being passed a valid macaroon?
2:48 PM  beowulf: that's all I can think of.

@noise
Copy link

noise commented Mar 28, 2017

On page load (after logged in):

Request: https://build.snapcraft.io/api/store/account?root=MDA....
Response: 401 / {"error_list":[{"message":"Authorization Required","code":"macaroon-permission-required"}]}

Then when I enter a name and click Register Name:
Request: https://build.snapcraft.io/api/store/register-name
Response: 401 / {"error_list":[{"message":"Authorization Required","code":"macaroon-permission-required"}]}

@cjwatson
Copy link
Contributor

cjwatson commented Apr 3, 2017

@noise Could you extract the response headers as well? WWW-Authenticate in particular, but we might as well get a dump of anything non-sensitive if possible.

@cjwatson
Copy link
Contributor

cjwatson commented Apr 3, 2017

@noise The other thing you could usefully do, if possible, would be to extract your raw macaroon from the request and run it through something like this:

from pymacaroons import Macaroon
print(Macaroon.deserialize(raw_macaroon).inspect())

There'll be some secret information there that you should elide, but it'd be really helpful to see the rest of it.

@noise
Copy link

noise commented Apr 3, 2017

@cjwatson hmm, neither reponse has an auth header, here's the full headers for the register-name request:

HTTP/1.1 401 Unauthorized
Date: Mon, 03 Apr 2017 19:58:34 GMT
Server: Apache/2.4.18 (Ubuntu)
X-VCS-Revision: f4e5b8b787607a3d29bf994c6ff37707ce19121d
X-DNS-Prefetch-Control: off
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=15768000; includeSubDomains; preload
X-Download-Options: noopen
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Type: application/json; charset=utf-8
Content-Length: 91
ETag: W/"5b-qoE5SHVchDWgGWCgEVy+HA"
X-Request-Id: WOKpan8AAQEAAErDZW4AAABf1
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive

cjwatson added a commit to cjwatson/build.snapcraft.io that referenced this issue Apr 4, 2017
@cjwatson
Copy link
Contributor

cjwatson commented Apr 4, 2017

As well as the PR here to log more information on the BSI side, I've proposed https://code.launchpad.net/~cjwatson/software-center-agent/log-macaroon-failures/+merge/321848 to see if we can get more logging of this on the SCA side.

cjwatson added a commit that referenced this issue Apr 4, 2017
* Move getCaveats to a separate helper module

* Log information for register-name 401 failures

This should help to debug #527.
@noise
Copy link

noise commented Apr 4, 2017

@cjwatson here's both macaroons:

discharge:

identifier {"secret": "[REDACTED]", "version": 1}
cid login.ubuntu.com|account|[REDACTED]
cid login.ubuntu.com|valid_since|2017-04-04T17:56:58.365224
cid login.ubuntu.com|last_auth|2017-04-04T17:56:58.365224
cid login.ubuntu.com|expires|2018-04-04T17:56:58.365284

root:

location myapps.developer.ubuntu.com
identifier MyApps
cid myapps.developer.ubuntu.com|valid_since|2017-04-04T17:56:57.458495
cid {"secret": "[REDACTED]", "version": 1}
vid [REDACTED]
cl login.ubuntu.com
cid myapps.developer.ubuntu.com|channel|["edge"]
cid myapps.developer.ubuntu.com|expires|2017-04-04T15:56:56.895000
cid myapps.developer.ubuntu.com|acl|["package_upload_request", "edit_account"]

bartaz added a commit that referenced this issue Apr 6, 2017
* 495: CSRF tokens (#553)

* 495: CSRF tokens

- Added new Express middleware to generate and verify CSRF tokens
- Added global window.__CSRF_TOKEN__ variable for application to consume
  token from server
- Added new API_CALL redux middleware to encapsulate API requests and pass tokens
- Migrated FETCH_SNAPS and REMOVE_SNAPS chain of events to API_CALL
- Fixed snaps reducer to work with API_CALL middleware
- Added unit tests

* 495: Remove TODO

* 495: CSRF Tokens

- Removed redux-mock-store from snaps unit tests
- Removed thunks from snaps actions

* 495: CSRF tokens

- Revised payload shape for CALL_API middleware

* 495: Added test for callApi middleware

* 495: CSRF Tokens

- Rearranged some server routes
- Removed a duplicate route

* Add metric for builds released to edge (#566)

* Add metric for builds released to edge

We do this by configuring a webhook on Launchpad snaps and counting
events where `store_upload_status` is "Uploaded".  (We could use the
information provided by this webhook for some more things in future to
reduce polling, although that would also require putting some more
thought into ordering guarantees; since "Uploaded" is a terminal status
we don't need to think about that too hard in this case.)

Of course there are lots of existing snaps that need to have the webhook
added, and it's also possible that we might create the snap and then
fail to create the webhook.  We don't currently have any infrastructure
for running scripts or periodic jobs, which would be a better way to
handle this; but as a reasonably lightweight workaround for these
problems, `/api/launchpad/snaps/list` also ensures that the necessary
webhook exists for each of the snaps it returns, and we make a note in
memcached that we've done so to avoid hitting the Launchpad API too
often.

Fixes #517.

* Break up webhook handler into separate functions

* Document lp:has_webhook:<snap>

* describe → context

* Replace node uuid (#577)

* replace-node-uuid

- Updated shrinkwrap against master

* replace node-uuid

- Installed uuid module
- Uninstalled node-uuid

* Don't generate CSRF token if there is no session (#576)

* Log information for register-name 401 failures (#575)

* Move getCaveats to a separate helper module

* Log information for register-name 401 failures

This should help to debug #527.

* update-react (#547)

- Updated react and react-dom to 15.4.2

* Adjust the alignment of the beta flag (#573)

* Drop next-route fallthrough from universal handler (#586)

This has recently started causing `HEAD /` requests to fail on staging.
I'm not clear on why this has only started happening recently, but I
think this code has been wrong for some time: `handleMatch` is always
called and emits a response in all cases, so there's no reason to fall
through to other routes here (except for error-handling middleware,
which will still be called on unhandled exceptions).

Fixes #583.

* 30 seconds beta notification delay (#591)

* New tag manager container id for tracking (#595)

* Fixing passing snaps to entities and ids

* Cleaning up some merge comments
earnubs added a commit that referenced this issue Apr 6, 2017
* 495: CSRF tokens (#553)

* 495: CSRF tokens

- Added new Express middleware to generate and verify CSRF tokens
- Added global window.__CSRF_TOKEN__ variable for application to consume
  token from server
- Added new API_CALL redux middleware to encapsulate API requests and pass tokens
- Migrated FETCH_SNAPS and REMOVE_SNAPS chain of events to API_CALL
- Fixed snaps reducer to work with API_CALL middleware
- Added unit tests

* 495: Remove TODO

* 495: CSRF Tokens

- Removed redux-mock-store from snaps unit tests
- Removed thunks from snaps actions

* 495: CSRF tokens

- Revised payload shape for CALL_API middleware

* 495: Added test for callApi middleware

* 495: CSRF Tokens

- Rearranged some server routes
- Removed a duplicate route

* Add metric for builds released to edge (#566)

* Add metric for builds released to edge

We do this by configuring a webhook on Launchpad snaps and counting
events where `store_upload_status` is "Uploaded".  (We could use the
information provided by this webhook for some more things in future to
reduce polling, although that would also require putting some more
thought into ordering guarantees; since "Uploaded" is a terminal status
we don't need to think about that too hard in this case.)

Of course there are lots of existing snaps that need to have the webhook
added, and it's also possible that we might create the snap and then
fail to create the webhook.  We don't currently have any infrastructure
for running scripts or periodic jobs, which would be a better way to
handle this; but as a reasonably lightweight workaround for these
problems, `/api/launchpad/snaps/list` also ensures that the necessary
webhook exists for each of the snaps it returns, and we make a note in
memcached that we've done so to avoid hitting the Launchpad API too
often.

Fixes #517.

* Break up webhook handler into separate functions

* Document lp:has_webhook:<snap>

* describe → context

* Replace node uuid (#577)

* replace-node-uuid

- Updated shrinkwrap against master

* replace node-uuid

- Installed uuid module
- Uninstalled node-uuid

* Don't generate CSRF token if there is no session (#576)

* Log information for register-name 401 failures (#575)

* Move getCaveats to a separate helper module

* Log information for register-name 401 failures

This should help to debug #527.

* update-react (#547)

- Updated react and react-dom to 15.4.2

* Adjust the alignment of the beta flag (#573)

* Drop next-route fallthrough from universal handler (#586)

This has recently started causing `HEAD /` requests to fail on staging.
I'm not clear on why this has only started happening recently, but I
think this code has been wrong for some time: `handleMatch` is always
called and emits a response in all cases, so there's no reason to fall
through to other routes here (except for error-handling middleware,
which will still be called on unhandled exceptions).

Fixes #583.

* 30 seconds beta notification delay (#591)

* New tag manager container id for tracking (#595)
earnubs added a commit that referenced this issue Apr 6, 2017
* refactor repositories state, fixes #464

* fix add-repos spinner post rebase

* Fix pageSlice failing when there are no pageLinks (#574)

* Whitelist and camelCase props from GH API (#578)

* remove typo/skipped tests causing parse failure (#579)

* Updated action names for adding repo (#580)

* Better select-repository-list component test coverage (#581)

* more test coverage for select-repositories-list

* update for action name changes

* use length from fixture

* use new action creator names (#584)

* use new action creator names

* Update t_repositories.js

* skip failing tests, temporarily (#585)

* skip failing tests, temporarily

* skip failing metrics test

* silence

* Cleaning up entities reducer code (#587)

* fix select-repository-row tests (#588)

* fix success response fixture (#589)

* Drop __ prefix from internal entities props (#590)

* shonkwrap from fresh install (#594)

* add comment on normalizr use in lp handler (#593)

* add comment on normalizr use in lp handler

* Update launchpad.js

* update selector to use new state (#592)

* More test coverage for repository actions and reducers (#597)

* entities default test

* repository entity tests

* Update t_entities.js

* Update t_entities.js

* keep entity collection reducers together

* use repoPayload fixture

* Merge master into refactor redux part i (#598)

* 495: CSRF tokens (#553)

* 495: CSRF tokens

- Added new Express middleware to generate and verify CSRF tokens
- Added global window.__CSRF_TOKEN__ variable for application to consume
  token from server
- Added new API_CALL redux middleware to encapsulate API requests and pass tokens
- Migrated FETCH_SNAPS and REMOVE_SNAPS chain of events to API_CALL
- Fixed snaps reducer to work with API_CALL middleware
- Added unit tests

* 495: Remove TODO

* 495: CSRF Tokens

- Removed redux-mock-store from snaps unit tests
- Removed thunks from snaps actions

* 495: CSRF tokens

- Revised payload shape for CALL_API middleware

* 495: Added test for callApi middleware

* 495: CSRF Tokens

- Rearranged some server routes
- Removed a duplicate route

* Add metric for builds released to edge (#566)

* Add metric for builds released to edge

We do this by configuring a webhook on Launchpad snaps and counting
events where `store_upload_status` is "Uploaded".  (We could use the
information provided by this webhook for some more things in future to
reduce polling, although that would also require putting some more
thought into ordering guarantees; since "Uploaded" is a terminal status
we don't need to think about that too hard in this case.)

Of course there are lots of existing snaps that need to have the webhook
added, and it's also possible that we might create the snap and then
fail to create the webhook.  We don't currently have any infrastructure
for running scripts or periodic jobs, which would be a better way to
handle this; but as a reasonably lightweight workaround for these
problems, `/api/launchpad/snaps/list` also ensures that the necessary
webhook exists for each of the snaps it returns, and we make a note in
memcached that we've done so to avoid hitting the Launchpad API too
often.

Fixes #517.

* Break up webhook handler into separate functions

* Document lp:has_webhook:<snap>

* describe → context

* Replace node uuid (#577)

* replace-node-uuid

- Updated shrinkwrap against master

* replace node-uuid

- Installed uuid module
- Uninstalled node-uuid

* Don't generate CSRF token if there is no session (#576)

* Log information for register-name 401 failures (#575)

* Move getCaveats to a separate helper module

* Log information for register-name 401 failures

This should help to debug #527.

* update-react (#547)

- Updated react and react-dom to 15.4.2

* Adjust the alignment of the beta flag (#573)

* Drop next-route fallthrough from universal handler (#586)

This has recently started causing `HEAD /` requests to fail on staging.
I'm not clear on why this has only started happening recently, but I
think this code has been wrong for some time: `handleMatch` is always
called and emits a response in all cases, so there's no reason to fall
through to other routes here (except for error-handling middleware,
which will still be called on unhandled exceptions).

Fixes #583.

* 30 seconds beta notification delay (#591)

* New tag manager container id for tracking (#595)

* Fixing passing snaps to entities and ids

* Cleaning up some merge comments

* drop union (#601)

* Merge master (#602)

* 495: CSRF tokens (#553)

* 495: CSRF tokens

- Added new Express middleware to generate and verify CSRF tokens
- Added global window.__CSRF_TOKEN__ variable for application to consume
  token from server
- Added new API_CALL redux middleware to encapsulate API requests and pass tokens
- Migrated FETCH_SNAPS and REMOVE_SNAPS chain of events to API_CALL
- Fixed snaps reducer to work with API_CALL middleware
- Added unit tests

* 495: Remove TODO

* 495: CSRF Tokens

- Removed redux-mock-store from snaps unit tests
- Removed thunks from snaps actions

* 495: CSRF tokens

- Revised payload shape for CALL_API middleware

* 495: Added test for callApi middleware

* 495: CSRF Tokens

- Rearranged some server routes
- Removed a duplicate route

* Add metric for builds released to edge (#566)

* Add metric for builds released to edge

We do this by configuring a webhook on Launchpad snaps and counting
events where `store_upload_status` is "Uploaded".  (We could use the
information provided by this webhook for some more things in future to
reduce polling, although that would also require putting some more
thought into ordering guarantees; since "Uploaded" is a terminal status
we don't need to think about that too hard in this case.)

Of course there are lots of existing snaps that need to have the webhook
added, and it's also possible that we might create the snap and then
fail to create the webhook.  We don't currently have any infrastructure
for running scripts or periodic jobs, which would be a better way to
handle this; but as a reasonably lightweight workaround for these
problems, `/api/launchpad/snaps/list` also ensures that the necessary
webhook exists for each of the snaps it returns, and we make a note in
memcached that we've done so to avoid hitting the Launchpad API too
often.

Fixes #517.

* Break up webhook handler into separate functions

* Document lp:has_webhook:<snap>

* describe → context

* Replace node uuid (#577)

* replace-node-uuid

- Updated shrinkwrap against master

* replace node-uuid

- Installed uuid module
- Uninstalled node-uuid

* Don't generate CSRF token if there is no session (#576)

* Log information for register-name 401 failures (#575)

* Move getCaveats to a separate helper module

* Log information for register-name 401 failures

This should help to debug #527.

* update-react (#547)

- Updated react and react-dom to 15.4.2

* Adjust the alignment of the beta flag (#573)

* Drop next-route fallthrough from universal handler (#586)

This has recently started causing `HEAD /` requests to fail on staging.
I'm not clear on why this has only started happening recently, but I
think this code has been wrong for some time: `handleMatch` is always
called and emits a response in all cases, so there's no reason to fall
through to other routes here (except for error-handling middleware,
which will still be called on unhandled exceptions).

Fixes #583.

* 30 seconds beta notification delay (#591)

* New tag manager container id for tracking (#595)

* keep selected state on success (#603)

* keep selected state on success

* Update repository.js
@cjwatson
Copy link
Contributor

Having expires be earlier than valid_since is certainly exotic.

I wonder if this is a timezone issue ...

@cjwatson cjwatson self-assigned this Apr 10, 2017
cjwatson added a commit to cjwatson/build.snapcraft.io that referenced this issue Apr 10, 2017
Without this, people in a timezone sufficiently far west of UTC will get
macaroons that expire before the start of their validity period.

I experimented with some timezone mocking libraries, but couldn't get
anything to work very well.  The easiest approach seems to be to just
run the whole test suite in `TZ=US/Pacific`, which should be enough to
shake out most timezone handling bugs.

Fixes canonical-web-and-design#527.
cjwatson added a commit that referenced this issue Apr 10, 2017
Without this, people in a timezone sufficiently far west of UTC will get
macaroons that expire before the start of their validity period.

I experimented with some timezone mocking libraries, but couldn't get
anything to work very well.  The easiest approach seems to be to just
run the whole test suite in `TZ=US/Pacific`, which should be enough to
shake out most timezone handling bugs.

Fixes #527.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants