« back to all changes in this revision
Viewing changes to README.txt
- browse files at revision 122
- compare with another revision
- download diff
- download tarball
- view history from revision 122
- Committer: Tarmac
- Author(s): Matt Goodall
- Date: 2016-09-09 14:54:41 UTC
- mfrom: (121.1.6 release-0.10)
- Revision ID: tarmac-20160909145441-saqa13l8uzpad1fz
[r=fgallina,ricardokirkner] Document "openid_duplicate_username" signal. Bump version to 0.10.
The README was also reformatted to wrap ridiculously long lines and a few typos were fixed.
The README was also reformatted to wrap ridiculously long lines and a few typos were fixed.
- files modified:
- README.txt
added
removed
README.txt
104
104
When a user logs in, they will be added or removed from the relevant
105
105
teams listed in the mapping.
106
106
107
If you have already django-groups and want to map these groups automatically, you can use the OPENID_LAUNCHPAD_TEAMS_MAPPING_AUTO variable in your settings.py file.
107
If you have already django-groups and want to map these groups automatically,
108
you can use the OPENID_LAUNCHPAD_TEAMS_MAPPING_AUTO variable in your
109
settings.py file.
108
110
109
111
OPENID_LAUNCHPAD_TEAMS_MAPPING_AUTO = True
110
112
111
If you use OPENID_LAUNCHPAD_TEAMS_MAPPING_AUTO, the variable OPENID_LAUNCHPAD_TEAMS_MAPPING will be ignored.
112
If you want to exclude some groups from the auto mapping, use OPENID_LAUNCHPAD_TEAMS_MAPPING_AUTO_BLACKLIST. This variable has only an effect if OPENID_LAUNCHPAD_TEAMS_MAPPING_AUTO is True.
113
If you use OPENID_LAUNCHPAD_TEAMS_MAPPING_AUTO, the variable
114
OPENID_LAUNCHPAD_TEAMS_MAPPING will be ignored.
115
If you want to exclude some groups from the auto mapping, use
116
OPENID_LAUNCHPAD_TEAMS_MAPPING_AUTO_BLACKLIST. This variable has only an effect
117
if OPENID_LAUNCHPAD_TEAMS_MAPPING_AUTO is True.
113
118
114
119
OPENID_LAUNCHPAD_TEAMS_MAPPING_AUTO_BLACKLIST = ['django-group1', 'django-group2']
115
120
127
132
128
133
OPENID_EMAIL_WHITELIST_REGEXP_LIST = ['foo(\+[^@]*)?@foo.com']
129
134
130
would whitelist users with the following emails (and other matching the regular expression)
131
from being in a required team:
135
would whitelist users with the following emails (and other matching the regular
136
expression) from being in a required team:
132
137
133
138
foo@foo.com
134
139
foo+bar@foo.com
136
141
137
142
== External redirect domains ==
138
143
139
By default, redirecting back to an external URL after auth is forbidden. To permit redirection to external URLs on a separate domain, define ALLOWED_EXTERNAL_OPENID_REDIRECT_DOMAINS in your settings.py file as a list of permitted domains:
144
By default, redirecting back to an external URL after auth is forbidden. To
145
permit redirection to external URLs on a separate domain, define
146
ALLOWED_EXTERNAL_OPENID_REDIRECT_DOMAINS in your settings.py file as a list of
147
permitted domains:
140
148
141
149
ALLOWED_EXTERNAL_OPENID_REDIRECT_DOMAINS = ['example.com', 'example.org']
142
150
144
152
145
153
== Use as /admin (django.admin.contrib) login ==
146
154
147
If you require openid authentication into the admin application, add the following setting:
155
If you require openid authentication into the admin application, add the
156
following setting:
148
157
149
158
OPENID_USE_AS_ADMIN_LOGIN = True
150
159
151
It is worth noting that a user needs to be be marked as a "staff user" to be able to access the admin interface. A new openid user will not normally be a "staff user".
152
The easiest way to resolve this is to use traditional authentication (OPENID_USE_AS_ADMIN_LOGIN = False) to sign in as your first user with a password and authorise your
153
openid user to be staff.
160
It is worth noting that a user needs to be be marked as a "staff user" to be
161
able to access the admin interface. A new openid user will not normally be a
162
"staff user".
163
The easiest way to resolve this is to use traditional authentication
164
(OPENID_USE_AS_ADMIN_LOGIN = False) to sign in as your first user with a
165
password and authorise your openid user to be staff.
154
166
155
167
== Change Django usernames if the nickname changes on the provider ==
156
168
157
If you want your Django username to change when a user updates the nickname on their provider, add the following setting:
169
If you want your Django username to change when a user updates the nickname on
170
their provider, add the following setting:
158
171
159
172
OPENID_FOLLOW_RENAMES = True
160
173
161
174
If the new nickname is available as a Django username, the user is renamed.
162
Otherwise the user will be renamed to nickname+i for an incrememnting value of i until no conflict occurs.
163
If the user has already been renamed to nickname+1 due to a conflict, and the nickname is still not available, the user will keep their existing username.
175
Otherwise the user will be renamed to nickname+i for an incrementing value of
176
i until no conflict occurs. If the user has already been renamed to nickname+1
177
due to a conflict, and the nickname is still not available, the user will keep
178
their existing username.
164
179
165
180
== Require a valid nickname ==
166
181
167
If you must have a valid, unique nickname in order to create a user accont, add the following setting:
182
If you must have a valid, unique nickname in order to create a user account, add
183
the following setting:
168
184
169
185
OPENID_STRICT_USERNAMES = True
170
186
171
This will cause an OpenID login attempt to fail if the provider does not return a 'nickname' (username) for the user, or if the nickname conflicts with an existing user with a different openid identiy url.
172
Without this setting, logins without a nickname will be given the username 'openiduser', and upon conflicts with existing username, an incrementing number will be appended to the username until it is unique.
187
This will cause an OpenID login attempt to fail if the provider does not return
188
a 'nickname' (username) for the user, or if the nickname conflicts with an
189
existing user with a different openid identity url. However, a
190
"openid_duplicate_username" signal is also sent to give a project the chance to
191
resolve a conflict.
192
Without this setting, logins without a nickname will be given the username
193
'openiduser', and upon conflicts with existing username, an incrementing number
194
will be appended to the username until it is unique.
173
195
174
196
== Require Physical Multi-Factor Authentication ==
175
197
176
If your users should use a physical multi-factor authentication method, such as RSA tokens or YubiKey, add the following setting:
198
If your users should use a physical multi-factor authentication method, such as
199
RSA tokens or YubiKey, add the following setting:
177
200
178
201
OPENID_PHYSICAL_MULTIFACTOR_REQUIRED = True
179
202
180
If the user's OpenID provider supports the PAPE extension and provides the Physical Multifactor authentication policy, this will
181
cause the OpenID login to fail if the user does not provide valid physical authentication to the provider.
203
If the user's OpenID provider supports the PAPE extension and provides the
204
Physical Multifactor authentication policy, this will cause the OpenID login to
205
fail if the user does not provide valid physical authentication to the
206
provider.
182
207
183
208
== Override Login Failure Handling ==
184
209
185
You can optionally provide your own handler for login failures by adding the following setting:
210
You can optionally provide your own handler for login failures by adding the
211
following setting:
186
212
187
213
OPENID_RENDER_FAILURE = failure_handler_function
188
214
189
Where failure_handler_function is a function reference that will take the following parameters:
215
Where failure_handler_function is a function reference that will take the
216
following parameters:
190
217
191
218
def failure_handler_function(request, message, status=None, template_name=None, exception=None)
192
219
Loggerhead is a web-based interface for Breezy
Version: 2.0.1