gaeutilities sessions, plz to help a n00b

[Emlyn]

I'm trying the gaeutilities session library for some new apps I'm building.

http://gaeutilities.appspot.com/session

I'm using it for two things:

- basic, old school session stuff (ie: a dictionary persistent across
user visits)

- securing ajax callbacks (the session contains the indication of
whether the user is logged in; session library's cookie goes from
server to client, back through ajax call through rest interface to
server, session is reconsituted based on it, if it's not the same one
then there's no login indication, call fails)

The library is pretty cool, a bit magical actually. I'm reading the
code to try to understand the magic, and think I'm getting a handle on
it.

However, in the doc, there is this:

"In order to take advantage of the token system for an authentication
system, you will want to tie sessions to accounts, and make sure only
one session is valid for an account. You can do this by setting a
db.ReferenceProperty(_AppEngineUtilities_Session) attribute on your
user Model, and use the get_ds_entity() method on a valid session to
populate it on login."

Why would I want to do this? I'm happy for two separate logins by the
same person to have different sessions, and I'm happy for subsequent
visits to begin with an empty session dictionary each time. Am I
missing something here?

--
Emlyn

http://my.syyn.cc - Synchonise Google+, Facebook, WordPress and Google
Buzz posts,
comments and all.
http://point7.wordpress.com - My blog
Find me on Facebook and Buzz

[Matt Jibson]

gaeutilities sounds nice, but in practice it is real slow. Use
gaesessions or webapp2 sessions instead:
https://github.com/dound/gae-sessions/wiki/comparison-with-alternative-libraries

> --
> You received this message because you are subscribed to the Google Groups "Google App Engine" group.
> To post to this group, send email to google-a...@googlegroups.com.
> To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
>
>

[Emlyn]

Thanks Matt, that looks great. I'll give it a shot.

[bowman...@gmail.com]

The purpose of restricting logins to one session is to avoid session hijacking. gaeutilities has features that help your site avoid session hijacking which have been made even easier with tools like Firesheep - http://codebutler.com/firesheep

Since (as of last I checked) you can't use ssl when using your own domains cookie sniffing is simple for appengine apps.

Sure, other libraries are faster, and if all you care about is performance, then I'd suggest using them. The only reason to choose gaeutilities is it was written with security prioritized over performance, therefore is more secure than the other libraries. Not to say it's secure, without ssl it's not truly secure, but it's much more difficult to spoof a gaeutilities session if configured correctly.

[Emlyn]

On 21 September 2011 01:41, bowman...@gmail.com

<bowman...@gmail.com> wrote:
> The purpose of restricting logins to one session is to avoid session
> hijacking. gaeutilities has features that help your site avoid session
> hijacking which have been made even easier with tools like Firesheep
> - http://codebutler.com/firesheep

> Since (as of last I checked) you can't use ssl when using your own domains
> cookie sniffing is simple for appengine apps.

I don't know if I'm understanding this; why would that help? Wouldn't
a sidejacked session look exactly like the currently logged in user
anyway? How does restricting logged in users to always use the same
session help here?

What it would do, I guess, is allow you to keep stuff like profile
info in the session, and have it immediately available on login.

> Sure, other libraries are faster, and if all you care about is performance,
> then I'd suggest using them. The only reason to choose gaeutilities is it
> was written with security prioritized over performance, therefore is more
> secure than the other libraries. Not to say it's secure, without ssl it's
> not truly secure, but it's much more difficult to spoof a gaeutilities
> session if configured correctly.

I'm sticking with gaeutilities for now, because the security looks
pretty solid.

>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-appengine/-/XWaPWJ54gt8J.

> To post to this group, send email to google-a...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengi...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>

--

[bowman...@gmail.com]

The security is the rotating session token. 

It works basically like this. A session token is valid for x seconds, and then a backlog of x tokens are considered valid. The reason that multiple tokens are valid is to support sites using ajax requests which may have request/response out of sequence with each other.

Avoiding taking multiple requests per page view into account, and just doing a single page/response scenario here's how it happens. This model also assumes that each page view is generating a new token, that's not required as you can make the token expiration as long as you want for your application.

You request a page, which generates a session. Session token is set in a cookie.

Next page request, the token is valid, but expired. A new cookie is set with a new session token.

Next page request, same thing.

Now, if you lock your user profile to only accepting one session, then hijacking will create a scenario where either the hijacker or user loses their session. So..

User creates session, get's token.

Hijacker sniffs token, connects using it, and get's another token.

User makes a request, generating a new token.

Hijacker connects still using the token they had, which generates a new one.

...

Eventually either the user or hijacker has a token that's expired so a new session needs to be created. 

If it's the user, when they log in they invalidate the session the hijacker is using and reclaim their access.

Now, it's not fool proof. If the hijacker is using a complicated enough system they can keep sniffing and resetting their cookies with the victims tokens. They can at least have some access time on the users account. They can also just sniff again to jump back on the session when they get kicked off. There's no way to make it truely secure, just more difficult.

The biggest problem with gaeutilities though is it's currently pretty much unsupported. I've stopped using appengine and with having 2 kids now I don't have time to dedicate to a project I'm not using. I learned python writing gaeutilities, and have since figured out ways to improve the performance - https://github.com/joerussbowman/gaeutilities/issues/2

I'm open to pull requests, or even to someone forking the project and continuing it. I'd be happy to act as an advisor or anything required to assist as long as the contributors can deal with my limited availability. If anyone just wants to fork the entire project and carry it on as long as I'm comfortable with the approaches taken I'd even point everyone to it. The only qualification I have is that security remain a primary motivator of design. Of course if it's a fork of my code and ideas I'd also like to continue to receive credit.

[Emlyn]

On 22 September 2011 11:26, bowman...@gmail.com

Ok, that makes sense.

> The biggest problem with gaeutilities though is it's currently pretty much
> unsupported. I've stopped using appengine and with having 2 kids now I don't
> have time to dedicate to a project I'm not using. I learned python writing
> gaeutilities, and have since figured out ways to improve the performance
> - https://github.com/joerussbowman/gaeutilities/issues/2

Oh, totally understand.

> I'm open to pull requests, or even to someone forking the project and
> continuing it. I'd be happy to act as an advisor or anything required to
> assist as long as the contributors can deal with my limited availability. If
> anyone just wants to fork the entire project and carry it on as long as I'm
> comfortable with the approaches taken I'd even point everyone to it. The
> only qualification I have is that security remain a primary motivator of
> design. Of course if it's a fork of my code and ideas I'd also like to
> continue to receive credit.
>

Well, if I begin to run into issues with it that I need to patch
myself, I'll yell out, maybe get involved. Thanks for the awesome
library though, it really is smooth to use. Great stuff.