Signature is validated, exp, aud and iis fields are checked.
Also add tests using tox and py.test. Proper validation of signature is verified
using jwcrypto.
Instead of encoding the redirect_uri in the state we:
* generate a random state with 128 bits of entropy
* store the state and the redirect_uri in the session
* verify that the state exist when receivng the callback
* retrieving the redirect_uri linked to this state from the session
Unlinking is now prevented if the user has no usable password and can't
change it because A2_REGISTRATION_CAN_CHANGE_PASSWORD is False.
For now it is thus assumed that the password is the unique other mean of
authentication and unlinking would make the account unreachable.
Also use A2_REGISTRATION_SET_PASSWORD_FORM_CLASS setting instead of
importing the form.
The registration frontend is used when the user is not logged locally
not with FC. The login template provide a link to the FC login view and
then to the plugin registration view.
If the user is already logged with FC, the login template provide a link
to the plugin registration view.
The view is called to create an account using the data provided by FC
at account creation.
The data provided is put in a protected token and sent to the next url.
If FC provides an email, the view redirects to the activation view.
If an email is not provided, the view redirects to the email registration
view.
The confirm_data parameter of the activation view is a plugin setting.
Account creation with FC means no password.
After a successful sso and no user is authenticated the user is redirected
on the login page. On the login page, the user may be asked to login with a
password or to create a new account. The plugin login button is hidden to avoid
an unecessary loop.
The patch add an option to display an other button that the login button.
This button reference the registration page and is filled with data from
the sso. If skip resgitration with prefilling data options are set on authentic
the button leads to a direct account creation.