[Twisted-Python] Perspective / Client confusion
I've read all the spread and pb docs several times now, and I'm still confused about some issues, particularly having to do with cred. I've created a pb app and am trying to figure out the best way to use Perspectives. Can someone explain why I would want to use one Perspective instance that kept track of attached clients, as shown in listings/pclients/multiple.py, versus creating a Perspective instance for each client, versus something more dynamic as hinted at in http://www.twistedmatrix.com/documents/howto/pb-cred: <quote> In addition, .attached() has the opportunity to return a different Perspective, if it so chooses. You could have all users initially access the same Perspective, but then as they connect (and .attached() gets called), give them unique Perspectives based upon their individual Identities. The client will get a reference to whatever .attached() returns, so the default case is to 'return self'. </quote> This application is sort of like a traditional database application. There will be admin-type users as well as employees with more limited authority. Customers will also have access to the application but will only be able to make changes to their own account information. I have a very simple demo that I am using to try out different approaches, which you can find here, if you want to see how I'm coding things: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pypersyst/sandbox/pobrien/twi... Since I'm using PyPerSyst to persist all the application data, I could also store user information there and use that to determine what a user can/cannot do, rather than rely on Perspectives. But I'm not sure that is the right approach. Any help would be greatly appreciated. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------
Hi Patrick, I'm pretty much in the same boat as you. Although I think I have a grasp no the different uses for mutiple/single prespectives, I'm currently struggeling with dbcred and how I want to apply prospectives to my rdbms application. I'd love to do an IRC session, but I don't know which IRC server to use :o I've found chatzilla (included in the www.mozilla.org web browser distribution) to be a nice IRC client, BTW -Joe
On Thursday, May 29, 2003, at 10:31 AM, Patrick K. O'Brien wrote:
Perspective is a very simple concept, with an almost-equally-simple representation. It just means "a token representing the user's presence and permissions within the context of a particular service". So, you should be able to use PyPerSyst to store Perspective subclass instances as the "user information" that you want to keep in your application.
On Thursday 29 May 2003 03:37 pm, Glyph Lefkowitz wrote:
Itamar helped me a bit on #twisted, but I'm still a bit unsure of myself. The problem seems to be that there are a number of different ways to do everything, and it isn't entirely clear to me how to evaluate the options. For example, I need more than one Perspective subclass. And I'd like the same person (Identity) to be able to log into the application with whichever Perspective is available to them. Itamar suggested that the best approach would be to have one service, several Perspective subclasses, and one Perspective instance for each client. So now I think I need to override the service.createPerspective() to create the right kind of Perspective instance, or create the Perspective independently and then send it to service.addPerspective(). It also seems to me that I should hide the Perspective details such that when a user logs in they simply choose which of their perspectives they want to use (admin, user, customer, for example). It also seems to me that I should generate the perspective names automatically, in order to keep them unique within the service (something like identity.name + perspective.__class__.__name__, perhaps). If I'm going to persist identities and perspectives using PyPerSyst, I also need to be careful what references those objects contain, such as perspective.service and service.authorizer. I'm not sure I want those persisted, so I probably need to add __getstate__ and __setstate__ methods to my subclasses. I also need a way to load persistent indentities and perspectives from PyPerSyst when the application starts. I know I've seen mention of those "load" methods, but I couldn't find any code examples. I also need to figure out how to allow someone to create new identities and perspectives in the first place. So I probably need to have the app start with a "root" type user/perspective that has the authority to create new identities and perspectives. Maybe I need another Perspective subclass that deals only with that capability. Am I making this more complicated than it needs to be? I'd love to hear someone say "yes" and then show me a simple way. It seems like what I'm trying to do would be pretty common for anyone creating a PB application that had many users that needed to be divided into groups, with each group having different capabilities. The plumbing all seems to be there (Identity, Perspective, Service, Authorizer, etc.), but hooking everything together still eludes me. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------
On Thursday 29 May 2003 07:03 pm, Patrick K. O'Brien wrote:
This is working so far: identity = auth.createIdentity('root') identity.setPassword('password') identity.save() perspective = AdminPerspective(identity) service.addPerspective(perspective) identity.addKeyForPerspective(perspective) perspective = UserPerspective(identity) service.addPerspective(perspective) identity.addKeyForPerspective(perspective) application.run() The init for my base Perspective class looks like this: def __init__(self, identity): """Create a Perspective for the identity.""" if not isinstance(identity, auth.identityClass): raise TypeError("Expected identity instance, got %s." % identity) perspectiveName = identity.name + ':' + self.__class__.__name__ pb.Perspective.__init__(self, perspectiveName, identity.name) -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------
Hi Patrick, I'm pretty much in the same boat as you. Although I think I have a grasp no the different uses for mutiple/single prespectives, I'm currently struggeling with dbcred and how I want to apply prospectives to my rdbms application. I'd love to do an IRC session, but I don't know which IRC server to use :o I've found chatzilla (included in the www.mozilla.org web browser distribution) to be a nice IRC client, BTW -Joe
On Thursday, May 29, 2003, at 10:31 AM, Patrick K. O'Brien wrote:
Perspective is a very simple concept, with an almost-equally-simple representation. It just means "a token representing the user's presence and permissions within the context of a particular service". So, you should be able to use PyPerSyst to store Perspective subclass instances as the "user information" that you want to keep in your application.
On Thursday 29 May 2003 03:37 pm, Glyph Lefkowitz wrote:
Itamar helped me a bit on #twisted, but I'm still a bit unsure of myself. The problem seems to be that there are a number of different ways to do everything, and it isn't entirely clear to me how to evaluate the options. For example, I need more than one Perspective subclass. And I'd like the same person (Identity) to be able to log into the application with whichever Perspective is available to them. Itamar suggested that the best approach would be to have one service, several Perspective subclasses, and one Perspective instance for each client. So now I think I need to override the service.createPerspective() to create the right kind of Perspective instance, or create the Perspective independently and then send it to service.addPerspective(). It also seems to me that I should hide the Perspective details such that when a user logs in they simply choose which of their perspectives they want to use (admin, user, customer, for example). It also seems to me that I should generate the perspective names automatically, in order to keep them unique within the service (something like identity.name + perspective.__class__.__name__, perhaps). If I'm going to persist identities and perspectives using PyPerSyst, I also need to be careful what references those objects contain, such as perspective.service and service.authorizer. I'm not sure I want those persisted, so I probably need to add __getstate__ and __setstate__ methods to my subclasses. I also need a way to load persistent indentities and perspectives from PyPerSyst when the application starts. I know I've seen mention of those "load" methods, but I couldn't find any code examples. I also need to figure out how to allow someone to create new identities and perspectives in the first place. So I probably need to have the app start with a "root" type user/perspective that has the authority to create new identities and perspectives. Maybe I need another Perspective subclass that deals only with that capability. Am I making this more complicated than it needs to be? I'd love to hear someone say "yes" and then show me a simple way. It seems like what I'm trying to do would be pretty common for anyone creating a PB application that had many users that needed to be divided into groups, with each group having different capabilities. The plumbing all seems to be there (Identity, Perspective, Service, Authorizer, etc.), but hooking everything together still eludes me. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------
On Thursday 29 May 2003 07:03 pm, Patrick K. O'Brien wrote:
This is working so far: identity = auth.createIdentity('root') identity.setPassword('password') identity.save() perspective = AdminPerspective(identity) service.addPerspective(perspective) identity.addKeyForPerspective(perspective) perspective = UserPerspective(identity) service.addPerspective(perspective) identity.addKeyForPerspective(perspective) application.run() The init for my base Perspective class looks like this: def __init__(self, identity): """Create a Perspective for the identity.""" if not isinstance(identity, auth.identityClass): raise TypeError("Expected identity instance, got %s." % identity) perspectiveName = identity.name + ':' + self.__class__.__name__ pb.Perspective.__init__(self, perspectiveName, identity.name) -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------
participants (3)
-
Glyph Lefkowitz -
Joe Brown -
Patrick K. O'Brien