Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recent change to bakery broke LXD #172

Open
stgraber opened this issue Oct 20, 2017 · 5 comments
Open

Recent change to bakery broke LXD #172

stgraber opened this issue Oct 20, 2017 · 5 comments
Labels

Comments

@stgraber
Copy link

Hi,

I just noticed the removal of the time argument to NewMacaroon and updated the LXD code to deal with this. However we're now seeing this failure:

https://jenkins.linuxcontainers.org/job/lxd-github-pull-test/3396/arch=amd64,backend=dir,compiler=golang-tip,restrict=lxd-priv/console

error: cannot get discharge from "http://localhost:21494": cannot handle form: cannot complete form: cannot read input: unexpected EOF
@stgraber
Copy link
Author

Going to run a git bisect on bakery to see what exactly broke us.

@stgraber
Copy link
Author

Digging into this, we used to be able to authenticate then do follow-up queries without having to re-authenticate. Ever since the removal of time.Time (as was identified through bisect), we seem to have some kind of instant expiry and so have to re-authenticate for every single query.

@stgraber
Copy link
Author

Adding the time caveat directly to our code base seems to fix things. Is that what we should be doing now?

@rogpeppe
Copy link
Member

Ah, that's an interesting and unexpected consequence of removing the mandatory time-before caveat. It means that by default the macaroon that's created won't have any expiry time, so I guess that the code for inferring the expiry time for the cookie is getting it wrong and expiring the cookie immediately. Short answer is: yes, you should probably always add an expiry time to your macaroons - I just didn't want that to be a hard requirement.

@rogpeppe
Copy link
Member

I'll take a look on Monday.

@rogpeppe rogpeppe added the bug label Aug 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants