For internal projects at Ritter, we want to allow a better dev. experience when working with apps. which talk to each other. When working locally, the communication normally flows using the other app's QA site. Identity Server is our auth provider when not running locally. To get our scenario to work, we need to augment the dev. app's auth configuration to use IdSrv and remember not to commit the changes.
Proposed change
Currently, Stuntman rejects the request if a bearer token is invalid. While this can continue to be the default behavior, an additional option will allow other auth providers a chance to validate the token. This now allows a scenario where we can have our dev. apps using Stuntman to pass a token to a QA-running app., let Stuntman on the latter get first crack at validating the token, and only passing to IdSrv if it cannot successfully validate.
A short test-session revealed that by removing the explicit 403 status code, the OWIN pipeline continued. The 403 seems to have special meaning, but I could not find where this actually comes into play and stops other middleware from executing.
billbogaiv
commented
7 years ago
Somewhat related to https://github.com/ritterim/stuntman/issues/133.
Background info.
For internal projects at Ritter, we want to allow a better dev. experience when working with apps. which talk to each other. When working locally, the communication normally flows using the other app's QA site. Identity Server is our auth provider when not running locally. To get our scenario to work, we need to augment the dev. app's auth configuration to use IdSrv and remember not to commit the changes.
Proposed change
Currently, Stuntman rejects the request if a bearer token is invalid. While this can continue to be the default behavior, an additional option will allow other auth providers a chance to validate the token. This now allows a scenario where we can have our dev. apps using Stuntman to pass a token to a QA-running app., let Stuntman on the latter get first crack at validating the token, and only passing to IdSrv if it cannot successfully validate.
A short test-session revealed that by removing the explicit
403status code, the OWIN pipeline continued. The403seems to have special meaning, but I could not find where this actually comes into play and stops other middleware from executing.