On Tue, Sep 8, 2009 at 10:20 PM, ristretto.rb<ristretto...@gmail.com> wrote: > > Hi > > I want to have a guest concept. You get instant access to my app. > There are limits. But, you will be allowed to come back multiple > times before I require you to register.
How do you plan to tell if the guest "came back"? The only reasonable mechanism I can think of is to use a session cookie (you can't rely on things like IP address ... like most folks with a home router, all the computers in my household will appear to have the same IP address to a service we contact, and the same would be true for most business situations). And even if you rely on a session cookie, your restrictions are easily bypassed by the user who simply clears their cookie cache. Until you can solve this problem reliably (good luck!), the implementation details are not really worth thinking about. But things like using a session cookie are no more or less secure for this use case than they are for the usual approach to keep a user logged on to a web app, other than the fact that you'd probably need to keep your session alive a lot longer. Craig PS: The typical solution I've seen for a "guest" concept is to offer only a limited subset of the overall functionality to non-registered users, with lots of teasers about "if you would only bother to register, you could do FOO and BAR and BAZ!". Example: ESPN's web site has a bunch of "freely available" stories accessible to anonymous users, but the (presumbably) good stuff requires a login. Figuring out the balance point is a challenge -- for me, for example, I'm not a fantasy football junkie, so the extra subscribers-only analysis doesn't have enough value for me to bother to register (or pay, as the case may be). > > When a user comes in as a guest, I will create a user with a bogus > username, password and email, and put the user_id in the session, so > that when the user comes back I can read it and restore saved state. > > I'm mildly concerned that it's unsafe to put the user_id in the > session. I can imagine a hacker faking that somehow, and getting > access to other guest accounts. I'm not sure the risk is that big, > and once users register, the risk goes down. But, I'm wondering if > this is at all foolhardy. Is there a better way to approach this? > > Perhaps a hash key or something that isn't sequentially too > guessable. Or some encryption. > > This guest concept has inherent security issues with shared computers: > labs, cafes, etc. The user will made aware of this when logging in as > Guest. Also there will be no sensitive or private data in this guest > account that if seen by another user would make much difference. > > Thanks for any insight > Gene > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
