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

Users of new teams can't un-pause their first pipelines #2882

jama22 opened this issue Nov 28, 2018 · 3 comments


Copy link

@jama22 jama22 commented Nov 28, 2018

This is a regression that came about because of our RBAC work. Users of new teams can't unpause their first pipelines, they get 403 errors.

Steps to Repro

  1. docker-compose up a new concourse
  2. Login as the main user test/test
  3. Execute a fly -t ci set-pipeline
  4. In the UI, try to unpause your pipeline

You should be able to do this

You can't! You have to logout and log back in again. Un-pausing from fly seems to work fine though

@jama22 jama22 changed the title Users can't un-pause their first pipelines Users of new teams can't un-pause their first pipelines Nov 28, 2018
@jama22 jama22 added bug web-ui labels Nov 28, 2018

This comment has been minimized.

Copy link
Member Author

@jama22 jama22 commented Nov 29, 2018

Additional detail: on step 2 I log in using the browser flow, NOT with the flags


This comment has been minimized.

Copy link

@pivotal-jamie-klassen pivotal-jamie-klassen commented Nov 29, 2018

@pivotal-jwinters I would really like to better understand the choice to store CSRF tokens in browser localStorage. The cause of this issue is that during the fly browser login flow, the following happens:

  1. Fly listens for the auth token on<random port>
  2. The user visits <concourse url>/sky/login?redirect_uri=<random port>/auth/callback
  3. User authenticates, and skyserver redirects the browser to<random port>/auth/callback?token=<auth token>&csrf_token=<CSRF token>
  4. Fly saves the auth token in ~/.flyrc, ignores the CSRF token and redirects the browser to <concourse url>/public/fly_success.

Thus the CSRF token doesn't end up saved in localStorage like it would in the web login flow, and so if you keep using that browser to access the web UI, you will get 401s for CSRF violations on any state-changing action (like unpausing a pipeline).

For the time being, I plan to change the last step so that fly will instead redirect the browser to <concourse url>/public/fly_success?csrf_token=<CSRF token> and fly_success will call some Javascript to save the CSRF token in localStorage appropriately, but it feels kludgy. I might just be unfamiliar with the security world and find this unpleasant, but maybe it's worthwhile to revisit this strategy? Hopefully you will enlighten me.

pivotal-jamie-klassen added a commit that referenced this issue Nov 29, 2018

Signed-off-by: Jamie Klassen <>

This comment has been minimized.

Copy link

@pivotal-jamie-klassen pivotal-jamie-klassen commented Nov 29, 2018

@jama-pivotal a note about acceptance - right after you hit 'login' after typing in your username and password, you may need to do a (cacheless) hard-refresh on the 'success' page (the one with url /public/fly_success that just says You've successfully logged in! You can now close this tab and return to fly.) before continuing.

This is mostly of concern if you perform the test on a browser that has cached this file before -- there's a very long cache policy on stuff under /public. I decided this was OK because one day, eventually, the browser's cached old version of this page will go stale and load the new-and-improved javascript version.

(tl;dr - I noticed you reproducing this issue using incognito mode, which might be enough to avoid this caching hiccup)

@jama22 jama22 added the accepted label Dec 3, 2018
@jama22 jama22 closed this Dec 3, 2018
@vito vito added this to the v5.0.0 milestone Jan 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.