docs: add documentation for post_authenticate signal #351
Conversation
|
Thanks! This looks good to me |
| * ``post_authenticate``: sent after a user has been authenticated through either the ``AdfsAuthCodeBackend`` | ||
| or the ``AdfsAccessTokenBackend`` (and created in Django, if ``CREATE_NEW_USERS`` is enabled) and |
There was a problem hiding this comment.
I'm good with this being merged as is, but I think there's room for some improvement.
I haven't checked the code, but I'm pretty sure the base backend class is what triggers the signal. If that's true it's better to say "authenticated through any subclass of BaseBackend (use the actual name). This signal is sent after any processing is done such as mapping claims, groups and creating the user if CREATE_NEW_USERS is enabled."
There was a problem hiding this comment.
you are correct - i was looking at something else in the subclasses and just misremembered when i was writing this. i'll update it.
| process. Currently, the following signals are supported: | ||
|
|
||
| * ``post_authenticate``: sent after a user has been authenticated through either the ``AdfsAuthCodeBackend`` | ||
| or the ``AdfsAccessTokenBackend`` (and created in Django, if ``CREATE_NEW_USERS`` is enabled) and |
There was a problem hiding this comment.
Ideally, we'd put a ref on CREATE_NEW_USERS in settings_ref.rst and use the ref syntax here.
| @receiver(post_authenticate) | ||
| def handle_post_authenticate(sender, user, claims, adfs_response, **kwargs): |
There was a problem hiding this comment.
Would there be a benefit to explaining what the signal arguments are outside the code block?
There was a problem hiding this comment.
i was a little torn on adding more documentation here vs. adding another place that needs to be changed if the code changes. but i guess if there's going to be a doc for it, it might as well be descriptive.
| * ``post_authenticate``: sent after a user has been authenticated through either the ``AdfsAuthCodeBackend`` | ||
| or the ``AdfsAccessTokenBackend`` (and created in Django, if ``CREATE_NEW_USERS`` is enabled) and |
There was a problem hiding this comment.
you are correct - i was looking at something else in the subclasses and just misremembered when i was writing this. i'll update it.
| @receiver(post_authenticate) | ||
| def handle_post_authenticate(sender, user, claims, adfs_response, **kwargs): |
There was a problem hiding this comment.
i was a little torn on adding more documentation here vs. adding another place that needs to be changed if the code changes. but i guess if there's going to be a doc for it, it might as well be descriptive.
I fumbled around for a while trying to figure out how to execute some custom code after a user is created/authenticated via SSO before I found the
post_authenticatesignal in the source code. I didn't see it in the docs, and having it in there would have saved me some time.I didn't really think it fit into any of the existing sections, but if you'd prefer it to be in there (maybe under installation, I guess?), let me know and I can move it.