Hello, Ben.
On Saturday February 21, 2009 14:58:22 Ben Sizer wrote:
> 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.
Just like TG doesn't handle CRUD operations on databases by itself, but uses
SQLAlchemy instead, TG2 doesn't handle authentication or authorization by
itself either -- instead it uses repoze.who and repoze.what, respectively.
So, with this in mind, it's definitely a meaningful detail for someone using a
NIH Web application framework. If TG was a monolithic framework like Django,
it'd be meaningless -- but it's not.
> 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.
To be honest, that doesn't make any sense. What you propose is mix
authorization with authentication.
I want you to know that I understand your request, I think it definitely makes
sense. What doesn't make sense to me is the solution you propose -- it must be
dealt with in the authentication layer, nowhere else.
> > 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.
Just like the talk of database sessions in SA is for advanced users? There's
no such a "built-in" auth* system in TG2. TG2 itself doesn't handle
authentication, identification or authorization, unlike TG1. Have you read
http://turbogears.org/2.0/docs/main/Auth/ ?
> 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.
This won't sound like Chinese for those who bothered to take a couple of
minutes to read the relevant documentation:
http://turbogears.org/2.0/docs/main/Auth/Authentication.html
> > 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.
It's still not usual. I never said "nobody needs that".
This verification on *each* request affects performance, at least slightly.
This is why I'd prefer that people who really want it have to enable it by
themselves... Unless there's a consensus where most people think this should
be the default behavior.
If you consider this is necessary for most people, considering the performance
issue, I suggest that you start a new thread to start a poll. If you get
enough support, I'll be happy to implement it by default (in TG 2.1, it's late
for v2.0).
Cheers.
--
Gustavo Narea <http://gustavonarea.net/>.
Get rid of unethical constraints! Get freedomware:
http://www.getgnulinux.org/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
