@@ -19,102 +19,103 @@ password auth provider module implementations:
1919
2020Password auth provider classes must provide the following methods:
2121
22- * class* ` SomeProvider.parse_config ` (* config* )
22+ * ` parse_config(config) `
23+ This method is passed the ` config ` object for this module from the
24+ homeserver configuration file.
2325
24- > This method is passed the ` config ` object for this module from the
25- > homeserver configuration file.
26- >
27- > It should perform any appropriate sanity checks on the provided
28- > configuration, and return an object which is then passed into
29- > ` __init__ ` .
26+ It should perform any appropriate sanity checks on the provided
27+ configuration, and return an object which is then passed into
3028
31- * class * ` SomeProvider ` ( * config * , * account_handler * )
29+ This method should have the ` @staticmethod ` decoration.
3230
33- > The constructor is passed the config object returned by
34- > ` parse_config ` , and a ` synapse.module_api.ModuleApi ` object which
35- > allows the password provider to check if accounts exist and/or create
36- > new ones.
31+ * ` __init__(self, config, account_handler) `
32+
33+ The constructor is passed the config object returned by
34+ ` parse_config ` , and a ` synapse.module_api.ModuleApi ` object which
35+ allows the password provider to check if accounts exist and/or create
36+ new ones.
3737
3838## Optional methods
3939
40- Password auth provider classes may optionally provide the following
41- methods.
42-
43- * class* ` SomeProvider.get_db_schema_files ` ()
44-
45- > This method, if implemented, should return an Iterable of
46- > ` (name, stream) ` pairs of database schema files. Each file is applied
47- > in turn at initialisation, and a record is then made in the database
48- > so that it is not re-applied on the next start.
49-
50- ` someprovider.get_supported_login_types ` ()
51-
52- > This method, if implemented, should return a ` dict ` mapping from a
53- > login type identifier (such as ` m.login.password ` ) to an iterable
54- > giving the fields which must be provided by the user in the submission
55- > to the ` /login ` api. These fields are passed in the ` login_dict `
56- > dictionary to ` check_auth ` .
57- >
58- > For example, if a password auth provider wants to implement a custom
59- > login type of ` com.example.custom_login ` , where the client is expected
60- > to pass the fields ` secret1 ` and ` secret2 ` , the provider should
61- > implement this method and return the following dict:
62- >
63- > {"com.example.custom_login": ("secret1", "secret2")}
64-
65- ` someprovider.check_auth ` (* username* , * login_type* , * login_dict* )
66-
67- > This method is the one that does the real work. If implemented, it
68- > will be called for each login attempt where the login type matches one
69- > of the keys returned by ` get_supported_login_types ` .
70- >
71- > It is passed the (possibly UNqualified) ` user ` provided by the client,
72- > the login type, and a dictionary of login secrets passed by the
73- > client.
74- >
75- > The method should return a Twisted ` Deferred ` object, which resolves
76- > to the canonical ` @localpart:domain ` user id if authentication is
77- > successful, and ` None ` if not.
78- >
79- > Alternatively, the ` Deferred ` can resolve to a ` (str, func) ` tuple, in
80- > which case the second field is a callback which will be called with
81- > the result from the ` /login ` call (including ` access_token ` ,
82- > ` device_id ` , etc.)
83-
84- ` someprovider.check_3pid_auth ` (* medium* , * address* , * password* )
85-
86- > This method, if implemented, is called when a user attempts to
87- > register or log in with a third party identifier, such as email. It is
88- > passed the medium (ex. "email"), an address (ex.
89- > "< [email protected] > ") and the user's password.90- >
91- > The method should return a Twisted ` Deferred ` object, which resolves
92- > to a ` str ` containing the user's (canonical) User ID if
93- > authentication was successful, and ` None ` if not.
94- >
95- > As with ` check_auth ` , the ` Deferred ` may alternatively resolve to a
96- > ` (user_id, callback) ` tuple.
97-
98- ` someprovider.check_password ` (* user_id* , * password* )
99-
100- > This method provides a simpler interface than
101- > ` get_supported_login_types ` and ` check_auth ` for password auth
102- > providers that just want to provide a mechanism for validating
103- > ` m.login.password ` logins.
104- >
105- > Iif implemented, it will be called to check logins with an
106- > ` m.login.password ` login type. It is passed a qualified
107- > ` @localpart:domain ` user id, and the password provided by the user.
108- >
109- > The method should return a Twisted ` Deferred ` object, which resolves
110- > to ` True ` if authentication is successful, and ` False ` if not.
111-
112- ` someprovider.on_logged_out ` (* user_id* , * device_id* , * access_token* )
113-
114- > This method, if implemented, is called when a user logs out. It is
115- > passed the qualified user ID, the ID of the deactivated device (if
116- > any: access tokens are occasionally created without an associated
117- > device ID), and the (now deactivated) access token.
118- >
119- > It may return a Twisted ` Deferred ` object; the logout request will
120- > wait for the deferred to complete but the result is ignored.
40+ Password auth provider classes may optionally provide the following methods:
41+
42+ * ` get_db_schema_files(self) `
43+
44+ This method, if implemented, should return an Iterable of
45+ ` (name, stream) ` pairs of database schema files. Each file is applied
46+ in turn at initialisation, and a record is then made in the database
47+ so that it is not re-applied on the next start.
48+
49+ * ` get_supported_login_types(self) `
50+
51+ This method, if implemented, should return a ` dict ` mapping from a
52+ login type identifier (such as ` m.login.password ` ) to an iterable
53+ giving the fields which must be provided by the user in the submission
54+ to [ the ` /login ` API] ( https://matrix.org/docs/spec/client_server/latest#post-matrix-client-r0-login ) .
55+ These fields are passed in the ` login_dict ` dictionary to ` check_auth ` .
56+
57+ For example, if a password auth provider wants to implement a custom
58+ login type of ` com.example.custom_login ` , where the client is expected
59+ to pass the fields ` secret1 ` and ` secret2 ` , the provider should
60+ implement this method and return the following dict:
61+
62+ ``` python
63+ {" com.example.custom_login" : (" secret1" , " secret2" )}
64+ ```
65+
66+ * ` check_auth(self, username, login_type, login_dict) `
67+
68+ This method does the real work. If implemented, it
69+ will be called for each login attempt where the login type matches one
70+ of the keys returned by ` get_supported_login_types ` .
71+
72+ It is passed the (possibly unqualified) ` user ` field provided by the client,
73+ the login type, and a dictionary of login secrets passed by the
74+ client.
75+
76+ The method should return an ` Awaitable ` object, which resolves
77+ to the canonical ` @localpart:domain ` user ID if authentication is
78+ successful, and ` None ` if not.
79+
80+ Alternatively, the ` Awaitable ` can resolve to a ` (str, func) ` tuple, in
81+ which case the second field is a callback which will be called with
82+ the result from the ` /login ` call (including ` access_token ` ,
83+ ` device_id ` , etc.)
84+
85+ * ` check_3pid_auth(self, medium, address, password) `
86+
87+ This method, if implemented, is called when a user attempts to
88+ register or log in with a third party identifier, such as email. It is
89+ passed the medium (ex. "email"), an address (ex.
90+ "
< [email protected] > ") and the user's password.
91+
92+ The method should return an ` Awaitable ` object, which resolves
93+ to a ` str ` containing the user's (canonical) User id if
94+ authentication was successful, and ` None ` if not.
95+
96+ As with ` check_auth ` , the ` Awaitable ` may alternatively resolve to a
97+ ` (user_id, callback) ` tuple.
98+
99+ * ` check_password(self, user_id, password) `
100+
101+ This method provides a simpler interface than
102+ ` get_supported_login_types ` and ` check_auth ` for password auth
103+ providers that just want to provide a mechanism for validating
104+ ` m.login.password ` logins.
105+
106+ If implemented, it will be called to check logins with an
107+ ` m.login.password ` login type. It is passed a qualified
108+ ` @localpart:domain ` user id, and the password provided by the user.
109+
110+ The method should return an ` Awaitable ` object, which resolves
111+ to ` True ` if authentication is successful, and ` False ` if not.
112+
113+ * ` on_logged_out(self, user_id, device_id, access_token) `
114+
115+ This method, if implemented, is called when a user logs out. It is
116+ passed the qualified user ID, the ID of the deactivated device (if
117+ any: access tokens are occasionally created without an associated
118+ device ID), and the (now deactivated) access token.
119+
120+ It may return an ` Awaitable ` object; the logout request will
121+ wait for the ` Awaitable ` to complete, but the result is ignored.
0 commit comments