-
-
Notifications
You must be signed in to change notification settings - Fork 36
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-330/allow anonymous #349
Conversation
@GlenDC I provided the logic in Also would it make sense for me to add an example showing how this might be used? |
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.
Well done, it is exactly in the right direction and partly spot on.
Added a couple of remarks and one guide post/comment to help you reach the finish line. Thanks for your contribution and do let me know if there's any questions, remarks, feedback or anything else I can be of help with.
represents a case where credentials are missing and server allows for anonymous users.
Updates Service implementation to handle cases where allow_anonymous == true
removes a few redundant lines
6a727df
to
4a28908
Compare
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.
You are getting close.
Things to do, next to my remarks is:
- The new
impl
block you added forValidateRequest
needs to be removed. - update the existing
impl
blocks for that trait:impl<S, B, ResBody> ValidateRequest<S, B> for Bearer<ResBody>
<- this replaced with the wrapperAuthorizeContext<Bearer<ResBody>>
impl<S, B, ResBody> ValidateRequest<S, B> for Basic<ResBody>
<- this replaced with the wrapperAuthorizeContext<Basic<ResBody>>
- You also need to provide setter methods for setting that
allow_anonymous
on the layer + service by adding these to:impl
blocks for things like `impl<S, C> ValidateRequestHeaderLayer<S, AuthorizeContext>impl<S, C> ValidateRequestHeader<S, AuthorizeContext<C>>
- no need to differentiate
C
betweenBasic
andBearer
here, given the constructors that we provide already limit whatC
can be, andC
's value is not used here. So this keeps it easy and minimal
Thank you @calebbourg for your contribution, effort and patience on this one. I hope the feedback does not discourage you. As always I'm here for you if there are remarks, feedback, questions or anything else of such nature. Take care. |
Thank you very much. Not discouraged at all. I welcome and appreciate the feedback. It's very helpful. |
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.
Well done, and fast indeed. Don't sweat it though, unless you're having fun :)
A couple of minor remarks, other than that I think we're good to go once these are resolved I'll give it a last review and if all is well I can merge it in if you're ok with it as well.
The presence of an Authorization header implies intent to be identified and authenticated
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.
Well done, thank you for going the extra mile.
The added unit tests and documentation is greatly appreciated!
💯🎈
Adds
allow_anonymous
concept to existing auth layers. Issue: #330