On Feb 21, 1:44 pm, Gustavo Narea <[email protected]> wrote:
> On Saturday February 21, 2009 19:23:35 Ben Sizer wrote:
>
> > A poll with which options? What would the choices be? All I want is
> > for repoze to be wrapped and documented in such a way that it is no
> > harder to use than Identity was, in the default case of simple name/
> > password => User systems. I doubt there is anybody at all who would
> > vote against it, saying "no, I like the additional complexity, it
> > makes me feel like a better programmer". The issue is whether it's
> > practical to change and/or extend it or not. Hence this discussion.
>
> The options would be:
> A) Verify that the user still exists on the database, on every request, by
> default.
> B) Implement the metadata provider I wrote in repoze.who.plugins.sa and then
> let TG2 users that it exists.
> C) Do nothing.
>
> I'd vote for Option B.
>
> If Option A is the winner, that would be implemented in TG 2.1 (as I said,
> it's late to go in V2.0).
>
> > I'm not surprised that you fully support your own work in repoze.what,
> > and indeed I have no criticism of what repoze.what does or how it does
> > it.
>
> I don't think I'm supporting my work on repoze.what. I'm just saying that it'd
> be out of its scope.
>
> > My only concern is that a typical TurboGears 2 user will have an
> > expectation that if they enable auth in their quickstarted application
> > then it will be simple to use for the simplest task, ie. guarding
> > access to controllers via username/password combinations, and getting
> > hold of the User in that situation. As it stands, the first works
> > almost all the time apart from the flaw where you can log in despite
> > your User having been deleted, and the second appears to me to be
> > undocumented.
>
> I agree with you on this. I know that's what the user would expect. To be
> honest, not even I had realized of this issue, so I thank you for bringing
> this up ;-)
>
> However, verifying this on each request is something that I would not like for
> performance reasons. But if most of you want it, I'll be happy to implement it
> -- and first I want to make sure people really want it, in spite of the
> performance issue.
>
> PS: Sorry for not replying to the other part of your response. I don't have
> much time, but wanted to reply to the most important points.
> --
> Gustavo Narea <http://gustavonarea.net/>.
>
Just to chime in here:
(I am not familiar with the repoze.who/what code, nor TG2 very much in
general yet. So, my comments may be a bit off-base.)
Basically:
It sounds like, for performance reasons, the default TG2 setup is
doing some "application layer" caching of parts of authenticated user
sessions. (Completely separate from the auth datastore... an external
LDAP server, or custom SQL based system, for instance.)
This is not inherently bad. Far from it.
But, it does seem to be implemented in a non-obvious way. This is the
problem. (And yes, it IS non-obvious.)
Though, I am presuming, that in the original poster's code, if the app
were to check for specific user permissions/rights, an errror of some
sort would be generated? (I hope I am correct here?)
Also, I think we can safely say that checking for a "user name" is
really an "implied checking of permissions" of sorts. (i.e. "Does
this connection I am seeing have the right to identify with a
particular user-name..." )
Thus, while permission checks can be cached, the caching (and it's
lifetime) should only be done explicitly by the developer of the
application, and never automatically by the framework.
Am I understanding the way repoze is working correctly?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
