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

Admin logout after deploy #2109

Closed
fnordfish opened this Issue Dec 15, 2016 · 1 comment

Comments

Projects
None yet
2 participants
@fnordfish
Contributor

fnordfish commented Dec 15, 2016

Preamble: I'm not sure if this is a bug or expected behaviour. I couldn't find anything pointing this out in the documentation, so I'm leaving this here for discussion.

I'm using padrino admin with the default cookie session store. Deployments are done via Capistrano.

Observed behavior:

Whenever we deployed a new version, everyone currently logged in into the admin interface got "logged out" / ending up on the login page.

Steps to reproduce:

  1. log in into the admin
  2. deploy application (using capistrano)
  3. reload admin page (or try to navigate to any page)

What happens:

The login information is stored as the admin-user ID the session cookie. So far nothing special. The problem is the naming of the key under which this ID is stored.
Instead of using a static key like "session_id", by default it is derived automatically like this: "_padrino_#{File.basename(Padrino.root)}_#{app.app_name}", probably to support multiple apps sharing the same session cookie.
With a default Capistrano setup each deploy will create a new "release" directory like /var/app/my_app/releases/<some_time_stamp>.
My deployment explicitly sets the PADRINO_ROOT to this release dir [^1]
The session_id default will kick in and generate a key name like _padrino_20161215111213_my_app/admin, rendering all existing session cookies invalid (because the old name was probably like _padrino_20161215101010_my_app/admin).

My current solution:

I'm setting the session_id to a (for my environment) more stable schema inside admin/app.rb: set :session_id, "_padrino_#{Padrino.env}_#{app_name}".to_sym
Alternatively, I could set up my deployment to use different PADRINO_ROOT for running the application (pointing to the current symlink) and deploy-tasks like migrations (pointing to the exact release dir)

Discussion:

Why is the "checkout" directory included in the session key name? To me this looks redundant, since app.app_name is already "name spaced" into "project_name/app_name". It probably makes sense when running the same project multiple time, using different configurations - as long as they use different names for the checkout directory (not "simply" different servers).

Anyhow this was a bit of unexpected magic behaviour. I'd ask for either document it well (maybe even put it in the auto-generated admin/app.rb) or rethink how this name is made up.

[^1]: I'm not setting it to the symlinked /var/app/my_app/current because at deploy-time it's still pointing to the old release and deploy-tasks like running migrations need to run using the new release code.

@adam12

This comment has been minimized.

Show comment
Hide comment
@adam12

adam12 Dec 15, 2016

Contributor

There's not much history behind the reasoning for session_id format. It was introduced in b278696 by @DAddYE.

I think we could safely convert the default from using the basename of Padrino.root into using Padrino.env. Likely makes more sense anyways.

Contributor

adam12 commented Dec 15, 2016

There's not much history behind the reasoning for session_id format. It was introduced in b278696 by @DAddYE.

I think we could safely convert the default from using the basename of Padrino.root into using Padrino.env. Likely makes more sense anyways.

@ujifgc ujifgc closed this in 34ffda0 Dec 28, 2016

@ujifgc ujifgc referenced this issue Mar 15, 2017

Closed

Release 0.14.0 #1971

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment