commands endpoint hangs when providing an invalid macaroon
Bug #1915429 reported by
Jeff Pihach
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Canonical Juju |
Fix Released
|
High
|
Ian Booth | ||
Bug Description
When sending a command to the /commands endpoint if you provide an invalid macaroon the connection will hang.
After some investigation it was found that it had entered an interactive session for getting a valid macaroon. However that information is not fed back across the request.
It would be nice if we could get a response back indicating that the macaroon is invalid and that we need to go get another.
Maybe it could also be done non-interactively if possible but I think we'll want to discuss in detail how this might work as if we're sending an invalid macaroon we'll want to update the one we have locally as well.
| Changed in juju: | |
| milestone: | none → 2.9.1 |
| status: | New → Triaged |
| importance: | Undecided → High |
| Changed in juju: | |
| milestone: | 2.9.1 → 2.9.2 |
Revision history for this message
| Ian Booth (wallyworld) wrote | #1 |
| Changed in juju: | |
| assignee: | nobody → Ian Booth (wallyworld) |
| status: | Triaged → In Progress |
| Changed in juju: | |
| status: | In Progress → Fix Committed |
| Changed in juju: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
This PR ensure the error is surfaced in the result struct
https:/
To handle a discharge workflow where login is done again over the embedded CLI websocket is a significant amount of extra work and design. For now, the dashboard / client will need to login again out of band to get a new macaroon to use.