Signals and Documentation

[DylannCordel]

Hi,

Since pre_user_save and post_authenticated are not any more used, I think it should be great to delete signals.py to avoid a working website wich was using signals to performs some actions ?

[peppelinux]

I completely agree but at the same time I'm looking for contributor that would reintroduce these (and document this feature) standing on what already documented in django and what would be the best practices for djangosaml2

I'm looking for contributor for that, would you like to join in this?

[DylannCordel]

Yes we (Webu) can join it.

I think there are 2 approaches (not exclusive):

• no signal, but extends the backends and views + override urls (like in the current master branch): need doc for :
  • how to have our own backend with examples
  • which "hooks" we can override in backend and need some code modification (for what I need, I must override _update_user because current "hooks" are not enough)
  • how to have our own views (like AssertionConsumerServiceView: extend it, change urls, etc.) with examples
  • which "hooks" we can override in those views
• send djangosaml2 signals like before + add doc

I think both approaches have advantages and depend on what you want to do. For exemple, it's simpler to have multiple independant app's which add custom code via signals. But for dependant apps, it's stronger to use hooks via multi Mixins inheritance for final Backend / View.

What do you think about it ?

[peppelinux]

regardings signals:
we need a general review of the current approach and a documentation for that

regarding hooks we have two strategies:

1. inherit AssertionConsumerServiceView and use urls.py to get it in. This commonly used for additional checks/validation and error handling regarding SAML2 Response.
2. inherit Saml2Backend as authentication backeds (suggested for internal user attributes, rewrites, storage, model ...)

as alternative we could move to a better generalizable model, similar to this:
https://github.com/UniversitaDellaCalabria/uniCMS/blob/a317c0d71b2c9ef6f2f9992f59eeb46f744522cf/example/unicms/settingslocal.py#L306

here we have some registered hooks (that could be also external django apps).
Each hook MUST accept a predefined (by-design)set of attributes, example: request, ava ...
In the core of djangosaml2 (AssertionConsumerServiceView and Saml2Backend) we should only register the calls of the configured hooks, similar on what did here as signals

https://github.com/UniversitaDellaCalabria/uniCMS/blob/main/src/cms/contexts/signals.py

or adding the calls in the class methods.

Probably the settings HOOKS would be the smartest thing if you agree

[peppelinux]

Hi @DylannCordel
Have you found something interesting to start with?

Which approach would you prefer?

[DylannCordel]

Hi @peppelinux

IMHO, be able to inherit some classes (views, backends...) which are designed to add some code execution at specific moment to change/add some behaviours is a must have. In the other hand, signals are also great to perform some actions which are independant from what SAML does, but just need to be executed at the right moment and get access to informations.

Concerning the signal registration via a setting, I'm not sure. I would prefer that third-party apps stay autonomous to register receivers once they are added in INSTALLED_APPS. If a signal is "order dependant" from th other in it's execution, I think it must not be a signal but an extend of the class where code is run.

In conclusion, I think both approaches are complementary (code designed to be overrided + signals) and will allow developpers to get a way for every thing they want to do.

I'll create a wip PR with just the documentation and if you are ok with what is proposed, I'll implement it.