Class ConsentScopes

Namespace

Fdyay.IdentityServer.UI.Pages

Assembly

Fdyay.IdentityServer.UI.dll

Turns a request's validated resources into rows, and a post about those rows into a grant.

public static class ConsentScopes

Inheritance

object

ConsentScopes

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.MemberwiseClone()

object.ReferenceEquals(object, object)

object.ToString()

Remarks

One implementation rather than one per screen. Two screens ask a user to approve a list of scopes — the consent page and the device approval page — and until 0.23.0 only the consent page read the six members that describe a scope to a human, so a host that named its scopes saw them named on one screen and not the other. The bounds on what a post may grant are here for the sharper version of the same reason: a copy of that check which drifts is a form the server trusts.

Methods

Describe(ResourceValidationResult)

Describes each validated scope with the metadata the host configured for these pages.

public static List<ConsentScope> Describe(ResourceValidationResult resources)

Parameters

resources ResourceValidationResult

Returns

List<ConsentScope>

Selected(ResourceValidationResult, IEnumerable<string>)

The scopes to grant: what was ticked, bounded by what was requested, plus what cannot be declined.

public static HashSet<string> Selected(ResourceValidationResult resources, IEnumerable<string> ticked)

Parameters

resources ResourceValidationResult

ticked IEnumerable<string>

Returns

HashSet<string>

Remarks

The post is a claim about which boxes were ticked and nothing more. It is intersected with the scopes this request actually validated, so a hand-written form cannot widen the grant past what the client asked for and the resource store allowed; and the host's Required scopes are added back afterwards, so omitting a disabled checkbox — which is what a browser does with one — cannot narrow it either.