-
Notifications
You must be signed in to change notification settings - Fork 26
"Registered for publishing" name always ends as "Unauthorized" [1] #527
Comments
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! |
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. |
I've just tried the following:
What happened:
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. |
Attached are some screenshots. There seems to be a unexpected "401 error" just after logging into the Ubuntu One Account. One difference (to your description) is that I have previously uploaded the snap directly from |
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 |
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. |
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. |
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. |
@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 |
2:08 PM fgallina: o/ anything about this ring any bells? #527 |
On page load (after logged in): Request: https://build.snapcraft.io/api/store/account?root=MDA.... Then when I enter a name and click Register Name: |
@noise Could you extract the response headers as well? |
@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:
There'll be some secret information there that you should elide, but it'd be really helpful to see the rest of it. |
@cjwatson hmm, neither reponse has an auth header, here's the full headers for the register-name request:
|
This should help to debug canonical-web-and-design#527.
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. |
* Move getCaveats to a separate helper module * Log information for register-name 401 failures This should help to debug #527.
@cjwatson here's both macaroons: discharge: identifier {"secret": "[REDACTED]", "version": 1} root: location myapps.developer.ubuntu.com |
* 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
* 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)
* 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
Having I wonder if this is a timezone issue ... |
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.
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.
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.
The text was updated successfully, but these errors were encountered: