simple guard question
How does one get the username for a given request? Bearing in mind that a guard sessions username may have been gathered via an HTML form and not be present on subsequent requests.
On Fri, 20 Jul 2007 00:03:33 +0100, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
How does one get the username for a given request? Bearing in mind that a guard sessions username may have been gathered via an HTML form and not be present on subsequent requests.
What is a username? What if the HTML form presents a CAPTCHA image as a challenge instead of a username/password login? The IResource which is responding to a request (either by satisfying a locateChild call or a renderHTTP call) _is_ the user. For requirements beyond that (and they should be few and far between), you have to impose a limit on exactly what kind of authentication your code will work with and supply a realm which will create avatars (IResource providers) with whatever additional information you need them to have (eg, an HTTP auth username, or the username field of an HTML form, or the CN field of an SSL certificate, or whatever). Jean-Paul
On Thu, 2007-07-19 at 19:15 -0400, Jean-Paul Calderone wrote:
On Fri, 20 Jul 2007 00:03:33 +0100, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
How does one get the username for a given request? Bearing in mind that a guard sessions username may have been gathered via an HTML form and not be present on subsequent requests.
What is a username? What if the HTML form presents a CAPTCHA image as a challenge instead of a username/password login?
The username is the avatarId, which is always a string and always present, is it not? Anyway, never mind - I get the idea - the page is the avatar and should be acting on the users behalf. I don't *agree* with the idea, but I get it. I think I'll just override the nevow traversal mechanism with something more to my liking on, and attach my principal "object" (which *I* think is the avatar, not the web page) to the request during locateChild on the root object. Thanks for the rapid reply. Cheers, Phil
On 12:05 am, p.mayers@imperial.ac.uk wrote:
On Thu, 2007-07-19 at 19:15 -0400, Jean-Paul Calderone wrote:
How does one get the username for a given request? Bearing in mind
On Fri, 20 Jul 2007 00:03:33 +0100, Phil Mayers <p.mayers@imperial.ac.uk> wrote: that
a guard sessions username may have been gathered via an HTML form and not be present on subsequent requests.
What is a username? What if the HTML form presents a CAPTCHA image as a challenge instead of a username/password login?
The username is the avatarId, which is always a string and always present, is it not?
No, we use the term "avatarId" on purpose, to distinguish from other common ideas about "username". It doesn't necessarily match any significant input to your system, nor any particularly interesting data on the back-end. It will be a string, but it might end up just being the str() of an integer primary key in a database somewhere. The fact that this differing from the visibly obvious "username" is so rarely is unfortunately confusing, and treating it as a username is a convenience that many, many deployments can count on, but should not be a core assumption of Twisted Web or Nevow.
Anyway, never mind - I get the idea - the page is the avatar and should be acting on the users behalf. I don't *agree* with the idea, but I get it.
This is certainly a controversial idea, and one that is frequently criticised, often in this manner. Although I don't *agree* with the criticism, I don't object to it ;). Its design rationale should be better documented, and for that I apologize. However, although you may want a "user object" that is different than the page -- and in that case the top-level page should probably wrap that object -- the term "avatar" has a specific meaning. To be an avatar for HTTP, you must implement IResource. You can disagree about whether this is the most generally useful design, but it *is* the specific design to which the jargon term "avatar" refers in the context of cred. Trying to re-define it so that it doesn't mean that makes an already confusing topic even more difficult to discuss. So please don't.
This is certainly a controversial idea, and one that is frequently criticised, often in this manner. Although I don't *agree* with the criticism, I don't object to it ;). Its design rationale should be better documented, and for that I apologize.
Grin. There's no need to apologise - Twisted is a fantastic (free) system, and better documented than a whole lot of APIs I've had the (mis)fortune to use over the years.
However, although you may want a "user object" that is different than the page -- and in that case the top-level page should probably wrap that object -- the term "avatar" has a specific meaning. To be an avatar for HTTP, you must implement IResource.
You can disagree about whether this is the most generally useful design, but it *is* the specific design to which the jargon term "avatar" refers in the context of cred. Trying to re-define it so that it doesn't mean that makes an already confusing topic even more difficult to discuss. So please don't.
That was not my intention, and if you feel I've made a confusing statement then I'm sorry - let it be purged from the internets! By way of explanation regarding the basis of my thinking; the majority of the large web-app work I've done to this point is on Zope. It of course has the basic architecture of a tree of object instances. It would be unusual (to the best of my, admittedly not encyclopedic, knowledge) to spawn new instances of the entire page/object hierarchy when a user logs in. Instead the object-publisher walks the same tree, applying both zopes inbuilt permissions and making the user info available to pages/code on the request object. It's a model I like (along with a lot of other things about Zope, offset by some things I despise) and will have to give some thought as to whether to emulate or move away from.
On 09:05 am, p.mayers@imperial.ac.uk wrote:
There's no need to apologise - Twisted is a fantastic (free) system, and better documented than a whole lot of APIs I've had the (mis)fortune to use over the years.
Thank you :)
You can disagree about whether this is the most generally useful design, but it *is* the specific design to which the jargon term "avatar" refers in the context of cred. Trying to re-define it so that it doesn't mean that makes an already confusing topic even more difficult to discuss. So please don't.
That was not my intention, and if you feel I've made a confusing statement then I'm sorry - let it be purged from the internets!
I'll go get the memory hole.
By way of explanation regarding the basis of my thinking; the majority of the large web-app work I've done to this point is on Zope. It of course has the basic architecture of a tree of object instances. It would be unusual (to the best of my, admittedly not encyclopedic, knowledge) to spawn new instances of the entire page/object hierarchy when a user logs in. Instead the object-publisher walks the same tree, applying both zopes inbuilt permissions and making the user info available to pages/code on the request object.
The key thing to realize about Twisted's resources is that they are "light". They are very small objects that just implement a few methods. By contrast - Zope, and lots of other traditional web frameworks, have resources that are "heavy" - you need to back them with an object in a database, a file on disk, or some other similar construct. These two models don't have to be an either-or proposition. The IResource-as-avatar design is, to my mind, the most flexible way to implement differing authenticated content, but one often does not want to make use of all that flexibility. It is certainly a "design pattern" in web-based Twisted apps to have an underlying common resource hierarchy that the authenticated hierarchy is a lightweight "overlay" onto. In other words, the IResource avatar is *how* you implement authentication, it is not necessarily *what* you implement for an authenticated system. It is lower-level than the resource hierarchy that Zope provides. However, I think it's an important level of the infrastructure to be able to plug in to: I'm not sure if Zope does this, but there are certainly plenty of web-based systems that *require* you to present exactly the same hierarchy of objects (or files, or scripts), albeit with perhaps different behavior, to different users.
It's a model I like (along with a lot of other things about Zope, offset by some things I despise) and will have to give some thought as to whether to emulate or move away from.
You might have a look at the resource hierarchy in the Divmod application server, Mantissa, and see how that maps to your expectations. (It may be a bit under-documented, so feel free to ask questions if something is not obvious.)
On Fri, 20 Jul 2007 16:21:22 -0000, glyph@divmod.com wrote:
It's a model I like (along with a lot of other things about Zope, offset by some things I despise) and will have to give some thought as to whether to emulate or move away from.
You might have a look at the resource hierarchy in the Divmod application server, Mantissa, and see how that maps to your expectations. (It may be a bit under-documented, so feel free to ask questions if something is not obvious.)
Same goes for my pseudo-framework: http://hg.stiq.it/starter/ which is actually inspired by Mantissa in its architecture.
participants (4)
-
glyph＠divmod.com -
Jean-Paul Calderone -
Phil Mayers -
Valentino Volonghi aka Dialtone