maintaining logged in user longer outside of SessionVar

[harryh]

I want users to stay logged into my site for extended periods of time
(through server restarts, and browser restarts).  By default Lift
stores a User in a SessionVar so this doesn't get me there.  I've
configured jetty so the session cookie doesn't time out for 30 days,
and I have a database table with a session id -> user id mapping, but
keeping this up to date has proven to be kind of a pain as the session
id can change from time to time (like when I restart my servers to
push a new website version) and it's a bit more tricky than I would
like to handle all of this correctly.

Are any other lift users trying to accomplish the same goal?  How have
you gone about it?  Would it be a good feature for the framework to
have something to do this a bit more "built in"?

-harryh
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[Ross Mellgren-2]

Why not use a SessionVar that initializes from the database?

object myVar extends SessionVar[MyObj]
(loadValueFromDatabaseOrMakeANewOne)

-Ross

On Oct 19, 2009, at 2:12 PM, harryh wrote:

>
> I want users to stay logged into my site for extended periods of time
> (through server restarts, and browser restarts).  By default Lift
> stores a User in a SessionVar so this doesn't get me there.  I've
> configured jetty so the session cookie doesn't time out for 30 days,
> and I have a database table with a session id -> user id mapping, but
> keeping this up to date has proven to be kind of a pain as the session
> id can change from time to time (like when I restart my servers to
> push a new website version) and it's a bit more tricky than I would
> like to handle all of this correctly.
>
> Are any other lift users trying to accomplish the same goal?  How have
> you gone about it?  Would it be a good feature for the framework to
> have something to do this a bit more "built in"?
>
> -harryh
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[bearfeeder]

See ProtoExtendedSession

We use it in ESME and it's worked flawlessly for us.  If you need a link to the ESME code (it's Apache 2.0 licensed, so use it all you want, we'll write more), lemme know.

On Mon, Oct 19, 2009 at 11:12 AM, harryh <harryh@...> wrote:

I want users to stay logged into my site for extended periods of time
(through server restarts, and browser restarts).  By default Lift
stores a User in a SessionVar so this doesn't get me there.  I've
configured jetty so the session cookie doesn't time out for 30 days,
and I have a database table with a session id -> user id mapping, but
keeping this up to date has proven to be kind of a pain as the session
id can change from time to time (like when I restart my servers to
push a new website version) and it's a bit more tricky than I would
like to handle all of this correctly.

Are any other lift users trying to accomplish the same goal?  How have
you gone about it?  Would it be a good feature for the framework to
have something to do this a bit more "built in"?

-harryh

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[harryh]

> See ProtoExtendedSession

Ah, this is perfect!  Just hadn't noticed it before.  Thx.

-harryh

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jeppe Nejsum Madsen]

harryh <harryh@...> writes:

> I want users to stay logged into my site for extended periods of time
> (through server restarts, and browser restarts).  By default Lift
> stores a User in a SessionVar so this doesn't get me there.  I've
> configured jetty so the session cookie doesn't time out for 30 days,
> and I have a database table with a session id -> user id mapping,

Instead of using the http session id, you can maintain you own
login-session id and store this in a cookie. I.e.

1) On login, create cookie with id, add mapping id->user to table
2) On logout, clear the cookie, remove mapping from table
3) If you see a request without an http session, but with valid cookie,
lookup the user id in table and autologin the user
4) Periodically, clean table for entries more than 30 days old

/Jeppe

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[Naftoli Gugenheim]

Is it more dangerous to store the user's uniqueId in a cookie than to store another uniqueId that's associated with the user's uniqueId?

-------------------------------------
Jeppe Nejsum Madsen<jeppe@...> wrote:


harryh <harryh@...> writes:

> I want users to stay logged into my site for extended periods of time
> (through server restarts, and browser restarts).  By default Lift
> stores a User in a SessionVar so this doesn't get me there.  I've
> configured jetty so the session cookie doesn't time out for 30 days,
> and I have a database table with a session id -> user id mapping,

Instead of using the http session id, you can maintain you own
login-session id and store this in a cookie. I.e.

1) On login, create cookie with id, add mapping id->user to table
2) On logout, clear the cookie, remove mapping from table
3) If you see a request without an http session, but with valid cookie,
lookup the user id in table and autologin the user
4) Periodically, clean table for entries more than 30 days old

/Jeppe



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[Naftoli Gugenheim]

MetaMegaProtoUser has hooks -- onLogIn, onLogOut, and autologinFunc -- that you can use. autologinFunc is called when loggedIn_? is called and no user is logged in, to give you a chance to log one in.
So you can create a cookie in onLogIn, delete it in onLogOut, and read it in autologinFunc.
-------------------------------------
Jeppe Nejsum Madsen<jeppe@...> wrote:


harryh <harryh@...> writes:

> I want users to stay logged into my site for extended periods of time
> (through server restarts, and browser restarts).  By default Lift
> stores a User in a SessionVar so this doesn't get me there.  I've
> configured jetty so the session cookie doesn't time out for 30 days,
> and I have a database table with a session id -> user id mapping,

Instead of using the http session id, you can maintain you own
login-session id and store this in a cookie. I.e.

1) On login, create cookie with id, add mapping id->user to table
2) On logout, clear the cookie, remove mapping from table
3) If you see a request without an http session, but with valid cookie,
lookup the user id in table and autologin the user
4) Periodically, clean table for entries more than 30 days old

/Jeppe



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[harryh]

> Is it more dangerous to store the user's uniqueId in a cookie than to store another uniqueId that's associated with the
> user's uniqueId?

It is if your site has URLs like http://harryh.org/user/[uid]

-harryh
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[bearfeeder]

On Mon, Oct 19, 2009 at 5:02 PM, harryh <harryh@...> wrote:

> Is it more dangerous to store the user's uniqueId in a cookie than to store another uniqueId that's associated with the
> user's uniqueId?

An opaque identifier that can be revoked and is not exposed outside of a given user's session is a lot more secure than a global identifier that cannot be revoked or replaced.  For example, it would be possible to cycle the long term session identifier each time it was accessed.  That cannot be done with some sort of unqueId that's associated with the user.  Plus a browser-by-browser identifier is something that can be changed/deleted without impacting the other browsers.
 

It is if your site has URLs like http://harryh.org/user/[uid]

-harryh

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[harryh]

> See ProtoExtendedSession

It might be kind of annoying to change at this point, but "experation"
is a misspelling in this trait.

-harryh

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[Naftoli Gugenheim]

It shouldn't be such a problem. All that's needed is to rename it, and add a def with the "misspelling" that points to it, deprecated. Something like
@deprecated def experation = expiration
I guess you could file a ticket and someone will eventually get to it.

-------------------------------------
harryh<harryh@...> wrote:


> See ProtoExtendedSession

It might be kind of annoying to change at this point, but "experation"
is a misspelling in this trait.

-harryh



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[bearfeeder]

Please file a ticket.

On Mon, Oct 19, 2009 at 7:04 PM, harryh <harryh@...> wrote:

> See ProtoExtendedSession

It might be kind of annoying to change at this point, but "experation"
is a misspelling in this trait.

-harryh

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[harryh]

> See ProtoExtendedSession

After adding this to Boot.scala:

S.addAround(ExtendedSession.requestLoans)

I'm seeing request to load the User object from the database on every
request (including requests for static flies like images/css/js).  Is
there something I can do to make this not happen?  Alternately, should
this be considered a Lift bug?

-harryh
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[bearfeeder]

On Wed, Oct 21, 2009 at 1:38 PM, harryh <harryh@...> wrote:

> See ProtoExtendedSession

After adding this to Boot.scala:

S.addAround(ExtendedSession.requestLoans)

I'm seeing request to load the User object from the database on every
request (including requests for static flies like images/css/js).  Is
there something I can do to make this not happen?  Alternately, should
this be considered a Lift bug?

It's going to load the user for each stateful request.  I guess we can change it up to make the load lazy so it'll only happen in the requestvar is actually accessed.  Does that sould reasonable?

 

-harryh

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[harryh]

> It's going to load the user for each stateful request.

What do you mean by a stateful request?

> I guess we can change it up to make the load lazy so it'll only happen in the requestvar is
> actually accessed.  Does that sould reasonable?

If that makes it so I don't hit the database when loading static
files, then yes.

-harryh
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[bearfeeder]

On Wed, Oct 21, 2009 at 2:44 PM, harryh <harryh@...> wrote:

> It's going to load the user for each stateful request.

What do you mean by a stateful request?

> I guess we can change it up to make the load lazy so it'll only happen in the requestvar is
> actually accessed.  Does that sould reasonable?

If that makes it so I don't hit the database when loading static
files, then yes.

btw... all the stuff related to serving css, etc. is done outside of the user session state.  This is in SNAPSHOT.  Please give it a whirl and make sure it's suiting your needs.

 

-harryh

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[harryh]

> btw... all the stuff related to serving css, etc. is done outside of the
> user session state.  This is in SNAPSHOT.  Please give it a whirl and make
> sure it's suiting your needs.

This is totally my fault for not properly checking before M7, but I'm
still seeing a database access when serving static files (css, images,
js) when using extended sessions.

-harryh

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[bearfeeder]

On Fri, Nov 6, 2009 at 9:39 AM, harryh <harryh@...> wrote:

> btw... all the stuff related to serving css, etc. is done outside of the
> user session state.  This is in SNAPSHOT.  Please give it a whirl and make
> sure it's suiting your needs.

This is totally my fault for not properly checking before M7, but I'm
still seeing a database access when serving static files (css, images,
js) when using extended sessions.

Very, very strange.  Do you have a simple repro case?  If not, I'll see what I can whip up.
 

-harryh

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[harryh]

> Very, very strange.  Do you have a simple repro case?

No, but I'm not doing anything unusual at all.  I've got various
static files (js, gif, css, etc) in src/main/webapp/.  In Boot.scala I
have:

S.addAround(ExtendedSession.requestLoans)

ExtendedSession.scala has:

def recoverUserId = User.currentUser match {
  case Full(user) => Full(user.userIdAsString)
  case _ => Empty
}

Perhaps recoverUserId should be looking at User.curUserId instead of
User.currentUser (which will grab the whole User object from the
database)?  I was under the impression that, for static objects, it
wouldn't get this far but perhaps I was mistaken?

-harryh
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

[bearfeeder]

On Fri, Nov 6, 2009 at 11:11 AM, harryh <harryh@...> wrote:

> Very, very strange.  Do you have a simple repro case?

No, but I'm not doing anything unusual at all.  I've got various
static files (js, gif, css, etc) in src/main/webapp/.  In Boot.scala I
have:

S.addAround(ExtendedSession.requestLoans)

ExtendedSession.scala has:

def recoverUserId = User.currentUser match {
 case Full(user) => Full(user.userIdAsString)
 case _ => Empty
}

Perhaps recoverUserId should be looking at User.curUserId instead of
User.currentUser (which will grab the whole User object from the
database)?  I was under the impression that, for static objects, it
wouldn't get this far but perhaps I was mistaken?

Yeah, the recoeverUserId should be going against User.curUserId... that'll avoid the loading of the user.

Are you expecting Lift or your servlet container to serve the static files?

Are your static files in well known locations (e.g., /images, /css, etc.)?
 

-harryh

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---