Thanks! Really good info here. Much appreciated.
On Jan 28, 10:34 am, Blixt <andreasbl...@gmail.com> wrote:
> Yup, it certainly is rather straight-forward. I'll give you a short
> history of descriptors.
>
> Before descriptors, the equivalent was to do this:
> class UserSettings(webapp.RequestHandler):
> def get(self):
> # [do stuff]
> get = require_login(get)
>
> As you can see, due to Python's very dynamic nature, you can treat
> functions just as variables and reassign them and pass them around. In
> this case, they're being sent to the require_login() method which in
> turn is expected to return another function to replace the get()
> function (furthermore, it is expected to exhibit the same behavior as
> before, but with some added functionality, which in this case would be
> requiring the user to log in.)
>
> The Python developers figured that this was so useful and commonly
> practiced that it warranted its own syntax. Not least because it was
> considered counter-intuitive to put something that relates to the
> function after it, rather than close to its definition. Having to
> write the function name three times wasn't ideal either. And so, after
> a lot of debating the syntax, they decided that putting an at-sign
> followed by a reference to a function that would replace the user's
> function in front of the user's function (quite a mouthful!) would
> replace the old way of doing it. Like so:
> class UserSettings(webapp.RequestHandler):
> @require_login
> def get(self):
> # [do stuff]
>
> So the above code is equivalent to the code before it.
>
> Now I hope descriptors make sense to you. Here's how you'd make one:
> def require_login(func):
> def check_login(request):
> if not [user is logged in]:
> request.redirect('/login')
> return
> func(request)
> return check_login
>
> On Jan 28, 3:51 pm, solidus <e.smolens...@gmail.com> wrote:
>
> > I tried looking online on how to define a descriptor and it looks
> > fairly straightforward, but I don't see how to incorporate it with the
> > @ syntax that google's @requier_login uses. Can you point me in the
> > right direction or show me a a way to do this?
>
> > Thanks again!
>
> > On Jan 28, 9:09 am, Blixt <andreasbl...@gmail.com> wrote:
>
> > > Oh and regarding your second question:
> > > This behavior can be implied to the user's browser by not sending an
> > > expiry header for the cookie that holds the session id. I don't know
> > > if gaeutilities let's you specify this, but I would assume it does.
>
> > > If you want to truly enforce it on the server side, you can add a
> > > timestamp to your sessions in the datastore and not let the user
> > > continue using a session if the session hasn't been requested for x
> > > amount of time. The timestamp would be updated every time the session
> > > is requested so that the session only expires if the user stops using
> > > the page for a while (which would imply that the user has left the
> > > page.)
>
> > > On Jan 28, 3:02 pm, Blixt <andreasbl...@gmail.com> wrote:
>
> > > > If you're familiar with Python:
> > > > If you've got separate request handlers for the parts of the site that
> > > > require login and the parts that don't, you can make a function
> > > > descriptor that checks if the user is logged in before calling the
> > > > actual function. If the user is not logged in, it redirects to a login
> > > > page. Then you can use this descriptor on the get / post methods.
>
> > > > Google provides this functionality with their @require_login
> > > > descriptor that redirects to the Google Accounts login page if the
> > > > user is not logged in, but this doesn't work when rolling your own
> > > > authentication system, obviously.
>
> > > > If you're not familiar with Python:
> > > > The simplest way is probably to just make a function you can call that
> > > > returns True if the user is logged in. If the user is not logged in,
> > > > it redirects the user to your login page, then returns False. In your
> > > > actual get / post method you check whether the result of this function
> > > > is False, and if so, you leave the method:
>
> > > > def logged_in(request):
> > > > if [user is logged in]:
> > > > return True
> > > > request.redirect('/login')
> > > > return False
>
> > > > class UserSettings(webapp.RequestHandler):
> > > > def get(self):
> > > > if not logged_in(self): return
> > > > # show page
>
> > > > On Jan 28, 3:13 am, solidus <e.smolens...@gmail.com> wrote:
>
> > > > > Hi all,
>
> > > > > I'm new to appengine and somewhat new to web development. My question
> > > > > is regarding proper ways to use sessions.
>
> > > > > I'm currently messing around using the gaeutilities sessions module. I
> > > > > have a basic login page and some content. The question is what is the
> > > > > standard/best practice way to ensure that users aren't accessing parts
> > > > > of your site (via direct URL) without first going through the login
> > > > > screen?
>
> > > > > Also, how does one go about deleting or clearing session data once the
> > > > > user leaves the site without logging out first?
>
> > > > > Thanks!- Hide quoted text -
>
> > > - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
