On Feb 21, 1:12 pm, Gustavo Narea <[email protected]> wrote:
> Checking whether the user really is authenticated (and "authenticated" means
> that the user account really exists and the user provided the right
> credentials on login) is a task specific to the authentication framework, not
> to the authorization framework. If the authentication framework says the
> current user is authenticated, the authorization framework must not question
> that -- that's out of its scope.
This may all be true, but you have to appreciate that it's meaningless
detail to me, the TurboGears user, who is looking at decorators to
gate access to certain controllers. That's why I've posted here,
because I don't believe it's a problem with repoze, more a problem
with the way TurboGears users would expect it to operate when applying
it to their controllers. It's reasonable for them to assume that a
check that ensures that a user is not anonymous is checking that they
are a user known to the system - not a user who may have been known to
the system at some point in the past - and that they can safely access
the User object and query it.
We need a controller decorator that will say "only allow access to
this resource if the user actually exists and is logged in".
not_anonymous may well be the wrong one for this. But there needs to
be a 'right one' because I would argue not_anonymous is not really
very useful to TurboGears if it cannot guarantee that the
authenticated user actually exists.
> But as you said, it's no big deal because it's just a session cookie. But if
> this really bothers you, use the following repoze.who metadata provider (must
> be passed as the last MD provider to repoze.who):
>
> # I've not tested this, but theoretically it will work as you'd expect
> from zope.interface import implements
> from repoze.who.interfaces import IMetadataProvider
> from paste.httpexceptions import NotAuthorized
>
> class UserStillExists(object):
> implements(IMetadataProvider)
>
> def add_metadata(self, environ, identity):
> if identity.get('user') is None:
> raise NotAuthorized()
So, can someone wrap up the above and put it in TG2 under an intuitive
name? (And then add to the docs?) All the talk of metadata and
providers is fine for advanced users but there should be a basic and
built-in system in TG for this simple and common use-case. The
philosophy of "make easy things easy, and hard things possible" should
mean that the absolutely most common case - where you simply want to
confirm that someone has entered a username and password which matches
up to an existing User in the database - should be 'easy', and not
involve learning about metadata providers etc.
> But given that deleting an user is not something usual
I think there are several good reasons to delete users, such as
privacy laws. It may be illegal in some jurisdictions to keep a user
in the database once they have expressed a wish to be deleted, even if
the data is only their username and email address. Or you may want to
free up usernames for future use by different users.
--
Ben Sizer
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
