This commit fixes the JS callback defined in the check-session iframe which can produce infinite callback loops if the received message doesn't come from the relying
party. In that case another message is posted to the source of the message (which can be the OP itself) thus resulting in an infinite loop because "error" messages are
continuously generated by the callback function.
* Small wording change + fix in example template code
* Added note about UserConsent not being in the admin
* Mostly spelling corrections and phrasing changes
* Moved template context explation from the settings to the templates page
* Changed wording
* Changed wording
Django 1.10 changed request.user.is_authenticated from a function to a
boolean and Django 2.0 dropped the backward compatibility. In order to
use django-oidc-provider with Django 2.0, AuthorizeView needs to handle
request.user.is_authenticated as a boolean.
* Add test to expose issue #197
* Strip 'login' from prompt before redirecting
This fixes#197. Otherwise the user would have to login once,
then is immediately logged out and prompted to login again.
* Only remove 'login' if present
* Don't append an empty prompt parameter
* Inline variable
The token endpoint handled the scope parameter incorrectly for all of
the three handled grant types:
1. For "authorization_code" grant type the scope parameter in the token
request should not be respected but the scope should be taken from
the authorization code. It was not totally ignored, but rather the
scope parameter of the token request was used for the generated ID
token. This had two consequences:
* Spec conforming implementations of authorization code flow
didn't get correct ID tokens, since they usually don't pass
scope parameter with the token request.
* It's possible to get a broader scope for the ID token than what
is authorized by the user in the original authorization code
request.
2. For "refresh_token" grant type the scope parameter in the token
request should only allow narrowing down the scope. It wasn't
narrowed, but rather the original auth code scope was used for the
access token and the passed in scope parameter was used for the ID
token (again allowing unauthorized scopes in the ID token).
3. For "password" grant type the scope parameter in the token request
should be respected. The problem with this was that it wasn't
properly splitted when passed to ID token creation.
Fixes#186
The ID token processing hook might want to add claims to the ID token
conditionally based on the scope parameter. Therefore it would be very
useful to provide the scope parameter to the processing hook.
The token endpoint handled the scope parameter incorrectly for all of
the three handled grant types:
1. For "authorization_code" grant type the scope parameter in the token
request should not be respected but the scope should be taken from
the authorization code. It was not totally ignored, but rather the
scope parameter of the token request was used for the generated ID
token. This had two consequences:
* Spec conforming implementations of authorization code flow
didn't get correct ID tokens, since they usually don't pass
scope parameter with the token request.
* It's possible to get a broader scope for the ID token than what
is authorized by the user in the original authorization code
request.
2. For "refresh_token" grant type the scope parameter in the token
request should only allow narrowing down the scope. It wasn't
narrowed, but rather the original auth code scope was used for the
access token and the passed in scope parameter was used for the ID
token (again allowing unauthorized scopes in the ID token).
3. For "password" grant type the scope parameter in the token request
should be respected. The problem with this was that it wasn't
properly splitted when passed to ID token creation.
Fixes#186
