-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: New type safe middleware #64
Conversation
Codecov Report
@@ Coverage Diff @@
## master #64 +/- ##
==========================================
- Coverage 65.33% 58.15% -7.19%
==========================================
Files 5 6 +1
Lines 251 282 +31
==========================================
Hits 164 164
- Misses 87 118 +31
Continue to review full report at Codecov.
|
Tests are currently failing since this requires TypeSafeMiddleware which will only be available in Kitura 2.4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good. Minor comment about refactoring but that could be done another time.
onFailure: { status, headers in | ||
fail(response: response, status: status, headers: headers) | ||
}, | ||
onSkip: { status, headers in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be refactored into a skip()
function
Add the TypeSafeCredentials protocol needed for TypeSafeMiddleware
This has a handle function which will be called by the type-safe middleware to authenticate the user and return an instance of self on success, fail and end the response onFailure or return an error and continue onPass.
inProgress was removed since it isn't getting called by the current credentials and i don't believe we will use it.
redirect unauthorized was added which would redirect the user to a defined url if they failed to authenticate and this is set to have a value.
The plugin headers are set to allow httpBasic to set the headers requesting the user input a username and password.
Id and Provider are needed since these combined will make a unique identifier which is the desired result of this process and will simplify multiple authentication.
On pass will only set the response status if one has not already been set. This is so you can have multiple routes defined on the same path with different auths and if one succeeds then you don't get back unauthorized.