[Twisted-Python] multiple log-in / perspective broker
Suppose I have a chat room application using perspective broker. Users log in with their credentials and gain access to some kind of lobby showing all available chat rooms. Now suppose entry into each chat room is precluded by another log in step. How do I implement that? I suppose I could make another realm and listen on another port but that seems wrong. -- Daniel Sank Department of Physics Broida Hall University of California Santa Barbara, CA 93117 (805)893-3899
On 2013-12-27 16:48, Daniel Sank wrote:
Anyone?
_______________________________________________ Do your own cred login() to the new Realm, or maybe Portal if need auto auth. Read how urgent existing login code works, it is just a thin layer. I can't really give a good answer when typing on this crap tablet keyboard, if that doesn't help will try to answer more when back at computer In a few days. Or maybe someone else can.
Do your own cred login() to the new Realm, or maybe Portal if need auto auth.
The way I understand currently is like this: r = MyIRealmImplementer() p = portal.Portal(r) pbFactory = pb.PBServerFactory(p) reactor.listenTCP(<port number>, pbFactory) reactor.run() The API documentation for Portal specifically says that each Portal gets exactly one Realm. Therefore, I don't see how to add another Realm to the system without another listenTCP call on a new port. Is that what I'm supposed to do? The reason I'm not going for the listen-on-a-new-port idea is that I'd have as many open ports as chat rooms, which smells funny to me. What I really want is for the client processes to receive one new Avatar instance representing their access for each chat room into which they enter. If this is misguided please advise.
Read how urgent existing login code works, it is just a thin layer.
I don't understand what you mean by this. Is there a particular example I can look at?
I am imagining having a remotely accessible login() method on the avatar returned by the realm. I meant to say read current implementation, not "urgent". Written on an iPad still, sorry.
On 04:22 pm, itamar@itamarst.org wrote:
I am imagining having a remotely accessible login() method on the avatar returned by the realm.
In other words, you don't have to log in on the *root* pb object. Login is just a PB method call. You can have a second portal wrapping a different realm handing out different avatars and you can log in to that portal the second time. Jean-Paul
In other words, you don't have to log in on the *root* pb object. Login is just a PB method call. You can have a second portal wrapping a different realm handing out different avatars and you can log in to that portal the second time.
How can the client access that second Portal if it's not hooked up using pb.PBServerFactory and reactor.listenTCP?
I am imagining having a remotely accessible login() method on the avatar returned by the realm.
Ah, I think I understand this now. The first Avatar (the one that lives in the Lobby) has a method like remote_logIntoChatRoom(self, roomName, credentials, mind) which will then invoke some kind of login method on another Portal/Realm pair representing the specific chat room. What threw me originally is that I didn't realize that it's ok to use the Portal/Realm structure without a corresponding PBServerFactory and listenTCP call.
In other words, you don't have to log in on the *root* pb object. Loginis just a PB method call. You can have a second portal wrapping a different realm handing out different avatars and you can log in to that portal the second time.
I look in t.s.pb to find out what methods are called during log in. PBServerFactory is adapted to a pb root object by _PortalRoot which returns a _PortalWrapper from rootObject(self, broker). _PortalWrapper has a remote_login method with the following code def remote_login(self, username): """ Start of username/password login. """ c = challenge() return c, _PortalAuthChallenger(self.portal, self.broker, username, c) I'm confused by this because I expect that attempting to return an instance of _PortalAuthChallenger from the remote_login method should fail (ie. insecureJelly). How does this work?
On 08:46 pm, sank.daniel@gmail.com wrote:
In other words, you don't have to log in on the *root* pb object. Loginis just a PB method call. You can have a second portal wrapping a different realm handing out different avatars and you can log in to that portal the second time.
I look in t.s.pb to find out what methods are called during log in. PBServerFactory is adapted to a pb root object by _PortalRoot which returns a _PortalWrapper from rootObject(self, broker).
_PortalWrapper has a remote_login method with the following code
def remote_login(self, username): """ Start of username/password login. """ c = challenge() return c, _PortalAuthChallenger(self.portal, self.broker, username, c)
I'm confused by this because I expect that attempting to return an instance of _PortalAuthChallenger from the remote_login method should fail (ie. insecureJelly). How does this work?
_PortalAuthChallenger is a Referenceable. Any Referenceable is allowed by default. See twisted.spread.jelly.SecurityOptions, in particular the `basicTypes` attribute and the `allowBasicTypes` method. Jean-Paul
participants (3)
-
Daniel Sank -
exarkun＠twistedmatrix.com -
Itamar Turner-Trauring