On Tue, Jan 20, 2009 at 10:40 PM, jeremy wrote:
> can anyone recommend / mention a session manager other than the one in
> gaeutilities?
>
Beaker works with GAE: http://beaker.groovie.org/
--
Ian Bicking | http://blog.ianbicking.org
--~--~-~--~~~---~--~~
You
> can anyone recommend / mention a session manager other than the one in
> gaeutilities?
app-engine-patch [1] supports Django sessions [2]
[1] http://code.google.com/p/app-engine-patch/
[2] http://docs.djangoproject.com/en/dev/topics/http/sessions/
--~--~-~--~~~---~--
thanks for the suggestions.
does beaker really work out of the box with gae?
On Jan 21, 1:06 am, Ian Bicking wrote:
> On Tue, Jan 20, 2009 at 10:40 PM, jeremy wrote:
> > can anyone recommend / mention a session manager other than the one in
> > gaeutilities?
>
> Beaker works with GAE:http://be
Does beaker store all session information as cookies?
I'm just trying to figure out the value in the signed cookie approach,
because if I can figure out a way for it to make sense I would
consider moving gaeutilities to that approach.
gaeutilities stores only a temporary session token in the bro
Bowman - I think my issue with gaeutilities may largely be that the
default settings seem excessive. Looking at the cookies google.com
hands its visitors, their SID cookie lasts a good decade and seems to
rotate every few hours, not seconds. So at the moment i'm thinking
I'll see if changing the d
I think it's a case of it's been that way for so long I haven't
realized I need to change it. The put on every write to update the
last activity, I mean. I'll look into modifying it so that it only
writes when the session token changes.
As for google though, every time I load up my igoogle page,
Ok. I actually modified Session.__init__ locally to do the
last_activity on sid rotation (i also refactored it a bit to reduce
repeated code blocks). Regarding google.com's SID cookie - i'm not
seeing the sid update within minutes. I'm not sure why yours rotates
so quickly, but it's something enti
I've gone with a different approach that currently achieves similar
results, that's now available in the trunk. A new variable,
last_activity_update has been added. It's the amount of seconds that
needs to pass before that field needs to be updated by doing a put().
It defaults to 60 seconds, whic
Hmm, I'm not sure what "session timing" is.
I have an idea to reduce writes. Instead of updating the sid of every
session individually, give each session a random value between 0 and
C, and have one application-wide value R randomized every
session_token_ttl seconds to an integer between 0 and C,
By session timing I was referring to how long a session is valid for.
For example, a session is valid for 2 hours. This means the session is
valid for last_activity + 2 hours. Completely separate from the
session token process. So, if you leave the site and come back 90
minutes later, what happen
By the way, I really am not concerned with analysis attacks. It's
sniffing/spoofing attacks that are most common for session hijacking.
I simply sniff the network and find out what the name and value of the
cookie are, and what user agent you are sending. I then duplicate
those 2 things and if I'm
"What I see as a concern with your approach is what happens when the
server wide variable R gets out of sync with someone's version that
was crypted based off of it? The original reason the 3 valid token set
"
that's why i mention that "you can store the last 3 values of R as is
done now for each
Yea but R would be rotated every 15 seconds which would decrease the
window in which a session is really valid by a large margin.That's why
the session token needs to be tied to every account.
On Jan 23, 1:04 am, jeremy wrote:
> "What I see as a concern with your approach is what happens when th
aah, i see.
On Jan 23, 10:08 am, "bowman.jos...@gmail.com"
wrote:
> Yea but R would be rotated every 15 seconds which would decrease the
> window in which a session is really valid by a large margin.That's why
> the session token needs to be tied to every account.
>
> On Jan 23, 1:04 am, jeremy
I have some ideas now that I think will help out over all. Keep an eye
out for the next release. It won't be perfect, but unless Google can
provide some sort of mechanism for session tokens via their User API,
or possibly give us another less write heavy storage mechanism to
handle tasks like thes
Maybe store a secure token locally on gears or flash, then send one
time token by javascript. But the initial token still need to be
delivered by ssl.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google App Engi
The problems I see what that approach is:
- 1 time token can be sniffed. We have limited ssl support with
appengine which is why the session token client side needs to change.
- Relying on gears, flash, or even javascript creates client side
dependencies. gaeutilities already has a dependency o
Http digest auth is another option. But without ssl, I can't see any
practical reason to elevate session security level.
On Jan 24, 1:37 pm, "bowman.jos...@gmail.com"
wrote:
> The problems I see what that approach is:
>
> - 1 time token can be sniffed. We have limited ssl support with
> appengi
18 matches
Mail list logo
