Skip to content
This repository was archived by the owner on Dec 13, 2018. It is now read-only.
This repository was archived by the owner on Dec 13, 2018. It is now read-only.

Redesign automatic authentication choice mechanism #1061

Closed
@blowdart

Description

@blowdart

The current mechanism for choosing which authentication middleware runs by default has been fragile and caused pain when more than one middleware has been set to automatically run, leading to what is, at best, undefined behaviour. The undefined behaviour changed in 1.1, but some folks were relying on it.

The basic idea behind automatic challenging middleware was that only one middleware should be configured to automatically challenge, however historically this was configured by a property on the individual middleware, and, as middlewares cannot inspect each other, it was too easy to set multiple middlewares to automatically challenge.

The new behaviour should take the decision of what middleware to use to issue a challenge when no middleware is specifically selected out of the hands of the middleware, and into the realm of authorization policy. It's envisaged that the default policy would contain information on the elected middleware to use to issue a challenge, and syntactic sugar added so you can set it as a property on authorization, rather than having to write a complete policy.

This leaves an open question of what happens when Challenge is called manually, without specifying which middleware to use - do we use the one from the default policy, or remove automatic challenge at that point and force a developer to specify the middleware to be used?

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions