Part of twisted.cred.portal View Source View In Hierarchy
A mediator between clients and a realm.
A portal is associated with one Realm and zero or more credentials checkers. When a login is attempted, the portal finds the appropriate credentials checker for the credentials given, invokes it, and if the credentials are valid, retrieves the appropriate avatar from the Realm.This class is not intended to be subclassed. Customization should be done in the realm object and in the credentials checker objects.
|Method||__init__||Create a Portal to a
|Method||listCredentialsInterfaces||Return list of credentials interfaces that can be used to login.|
|Parameters||credentials||an implementor of |
|mind||an object which implements a client-side interface for your particular realm. In many cases, this may be None, so if the word 'mind' confuses you, just ignore it.|
|interfaces||list of interfaces for the perspective that the mind wishes to attach to. Usually, this will be only one interface, for example IMailAccount. For highly dynamic protocols, however, this may be a list like (IMailAccount, IUserChooser, IServiceInfo). To expand: if we are speaking to the system over IMAP, any information that will be relayed to the user MUST be returned as an IMailAccount implementor; IMAP clients would not be able to understand anything else. Any information about unusual status would have to be relayed as a single mail message in an otherwise-empty mailbox. However, in a web-based mail system, or a PB-based client, the ``mind'' object inside the web server (implemented with a dynamic page-viewing mechanism such as a Twisted Web Resource) or on the user's client program may be intelligent enough to respond to several ``server''-side interfaces.|
|Returns||A deferred which will fire a tuple of (interface, avatarAspect, logout). The interface will be one of the interfaces passed in the 'interfaces' argument. The 'avatarAspect' will implement that interface. The 'logout' object is a callable which will detach the mind from the avatar. It must be called when the user has conceptually disconnected from the service. Although in some cases this will not be in connectionLost (such as in a web-based session), it will always be at the end of a user's interactive session.|