There's been some ongoing discussion about the approach I and others have been taking to session management in our appengine applications. I always rank security over performance, but with how heavy datastore writes are, this can be problematic and eventually expensive for applications.
I've been thinking though, since users can log in with their Google accounts using the User API google offers, I was wondering if there was a layer to this that could be tied into for all applications, whether they choose to implement the full stack for user management? Since we can host our own domains, I'm assuming that Google has figured out a way to tie their own cookies into being readable through the stack somehow? While I respect the fact you may not want to go into detail how the full process works, I was wondering if the User API could be expanded to allow applications to whatever identifier you're using client side to uniquely identify browser sessions? This would then allow the various developers working on their own session implementations to build off of that to maintain session state, and gain the security of a real revolving session token that doesn't require a put. A full API for session data management doesn't need to be provided, thought it would be nice. Just access to a token that I'm assuming somehow exists. --~--~---------~--~----~------------~-------~--~----~ 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-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
