Go to the latest version of this document.
search in docstrings

Search bar offers the following options:

- Term presence. The below example searches for documents that must contain “foo”, might contain “bar” and must not contain “baz”: `+foo bar -baz`
- Wildcards. The below example searches for documents with words beginning with “foo”: `foo*`
- Search in specific fields. The following search matches all objects in "twisted.mail" that matches “search”: `+qname:twisted.mail.* +search`

  Possible fields: 'name', 'qname' (fully qualified name), 'docstring', and 'kind'. Last two fields are only applicable if "search in docstrings" is enabled.

- Fuzzy matches. The following search matches all documents that have a word within 1 edit distance of “foo”: `foo~1`

Results provided by Lunr.js

# ``twisted`.`cred`.`portal`.`Portal``

class documentation

`class Portal: (source)`

Constructor: `Portal(realm, checkers)`

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 `IRealm`.
Method | `listCredentialsInterfaces` | Return list of credentials interfaces that can be used to login.
Method | `login` | No summary
Method | `registerChecker` | Undocumented
Instance Variable | `checkers` | Undocumented
Instance Variable | `realm` | Undocumented

def __init__(self, realm: `IRealm`, checkers: `Iterable[ICredentialsChecker]` = ()): (source)

Create a Portal to a `IRealm`.

def listCredentialsInterfaces(self) -> `List[Type[Interface]]`: (source)

Return list of credentials interfaces that can be used to login.

def login(self, credentials: `ICredentials`, mind: `object`, *interfaces: `Type[Interface]`) -> `Deferred[_requestResult]`: (source)

Parameters
credentials:`ICredentials` | an implementor of `twisted.cred.credentials.ICredentials`
mind:`object` | 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:`Type[Interface]`

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

`Deferred[_requestResult]`

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.

def registerChecker(self, checker: `ICredentialsChecker`, *credentialInterfaces: `Type[Interface]`): (source)

Undocumented

checkers: `Dict[Type[Interface], ICredentialsChecker]` = (source)

Undocumented

realm = (source)

Undocumented