Now, /verify can return 401 or 403 depending on the user authentication.
Every public API endpoints and pages return 200 with error message in
JSON body or 401 if the user is not authorized.
This policy makes it complicated for an attacker to know what is the source of
the failure and hide server-side bugs (not returning 500), bugs being potential
threats.
Example 1: The user has validated first factor when accessing a service
protected by basic auth. When he tries to access another service protected
by second factor, he is redirected to second factor step to complete
authentication.
Example 2: The user has already validated second factor. When he access auth
service, he is redirected either to /loggedin page that displays an "already
logged in" page or to the URL provided in the "redirect" query parameter.
Previously, string "{0}" was replaced by the user dn in the groups_filter
attributes of the LDAP configuration.
However, if the groups children only have a memberUid attribute, one would
like to use the username instead of the user dn.
Since the user dn can be built from the username, "{0}" is now replaced
by the username instead of the user dn so that an LDAP relying on attribute
'memberUid' can be used.
ACLs can now be defined by subdomain AND resource using pattern matching
with regular expressions.
It allows a very fine-grained access control to backend resources.
[Note] For using example environmnent, user must update its /etc/hosts with
new subdomains updated in README.
Before this fix, the application was simply crashing during execution
when connection to redis was failing.
Now, it is correctly handled with failing promises and logs have been
enabled to clearly see the problem
Before this fix, the redirection URL was stored in the user session,
but this has a big drawback since user could open several pages in
browser and thus override the redirection URL leading the user to
be incorrectly redirected.
Clement Michaud