login and logout need "returnto" #106

dennishall opened this Issue Sep 6, 2011 · 3 comments

3 participants


The default "returnto" should be "/".

Right now, it's strange that the login page lands you back on the login page after log in.

  1. "returnto" will be set to a cookie by client js when the user clicks "log in".
  2. either server handler for login post -- or /user/login client js -- reads the cookie value - and if present, unsets it and then redirects.
@dennishall dennishall was assigned Sep 6, 2011

Does this need to be done via a cookie?

We can just pass returnTo to the login form via a url param, and then set it in the login form in a hidden field, it then goes along with the post and then a successful login just sends back a 302 to the returnTo?


It does not 'need' to be done via cookie. Some might even argue that the cookie method is inferior. I might be wrong, but it is the way I've done it for the sake of improved page cacheability. There could basically be an infinite number of possible returnTo's, leading to many, many "different" login pages, from a caching perspective. I endorse using a temporary cookie for this functionality.

A similar change that I'm working on is to move a couple of user details into a cookie so that client javascript can take care of page personalization. For instance, if username is in a cookie, then all content pages can be much more simply cached. It is somewhat likely that a given project may require that absolutely no user information is stored in a cookie, so it would be good to make this a config option. However, for the typical expected calipso use-case, putting username in a cookie should be ok, and thus I recommend that it is the default config.

It might be nice to allow the entire site to function without cookies, but I'm not particularly in favor of it since that is rarely a project requirement (probably hasn't been a requirement in years).

d7p commented Sep 4, 2012

it would be nice to have the option not to have usernames etc in cookies, for instance if the user is on a public pc.

instead of the username or anything else being stored in cookie, a GUID could be placed in the cookie and a table of loged in users. the session GUID and what ever user data needed stored for quick look up on each request.

When a user requesting a page the GUID would be checked and the users data added to the request object, so it can be used.

As for page personalization an ajax request could be maid after login and data saved in local storage or if it is a public pc in a client side object.

I may have missed something as i am new to this project but i would like to help

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