You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 23, 2022. It is now read-only.
Currently, you get the platter when you might only want a side-item.
For internal projects at Ritter, we have a need to allow bearer-token auth, but disallow UI auth (and vice-versa) on our QA sites.
I propose using the StuntmanOptions-instance passed to UseStuntman to selectively enable bearer-token and UI authentication as two separate properties on the options instance (this could be combined as one property using &, but it seems overkill for only two possible values).
The text was updated successfully, but these errors were encountered:
Current behavior registers both cookie and bearer token providers and there is no way to only use one or the other.
New behavior allows selective disabling.
Note: this could allow someone to effectively use Stuntman AND disable both things that make Stuntman useful.
Implements ritterim#133
Current behavior registers both cookie and bearer token providers and there is no way to only use one or the other.
New behavior allows selective disabling.
Note: this could allow someone to effectively use Stuntman AND disable both things that make Stuntman useful.
Implements ritterim#133
Currently, you get the platter when you might only want a side-item.
For internal projects at Ritter, we have a need to allow bearer-token auth, but disallow UI auth (and vice-versa) on our QA sites.
I propose using the
StuntmanOptions
-instance passed toUseStuntman
to selectively enable bearer-token and UI authentication as two separate properties on the options instance (this could be combined as one property using&
, but it seems overkill for only two possible values).The text was updated successfully, but these errors were encountered: