-
Notifications
You must be signed in to change notification settings - Fork 192
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
Conflict between HttpAuthentication::bearer and actix-cors #127
Comments
I suspect there's an error being thrown in httpauth middleware impl that should not be. A reminder that the semantic meaning of an error in middleware is unrecoverable and outer middlewares should not attempt to handle them. |
I also experienced the same issues. Got the same browser CORS error when trying to consume API on the browser after setting the CORS and HttpAuthentication::bearer Edit: Fixed it by removing the HttpAuthentication Middleware and handling http auth in the individual functions (which is obviously a more hectic approach). |
I initially thought that I was having the same issue as well with This probably caused the cors middleware to not run resulting in the expected headers not being attached. |
I noticed the merged PR, and a new release ('0.5.3`). Still, I see the same behavior. Should that problem be fixed now? |
Not yet. It will still skip downstream middleware if the validation function returns an error. That PR fixed a different case causing the same behaviour without changing the API. |
Thanks for the quick response. I overlooked that I need to update I would appreciate a release with the current patch already. |
I have the same issue and i would like the help solving it. Here my suggestion. In httpauth middleware the signature for the return of the process_fn is this I don't think that the process must yield an unrecoverable error so why not replace the signature by this I know that it will be a breaking change but let me explain. We can now replace this code: // TODO: alter to remove ? operator; an error response is required for downstream
// middleware to do their thing (eg. cors adding headers)
let req = process_fn(req, credentials).await?;
service.call(req).await By this: match process_fn(req, credentials).await {
Ok(req) => {
let fut = service.borrow_mut().call(req);
fut.await
},
Err(res) => {
Ok(res)
},
} For me the user is in charge of what happen in the validation function and the user must take a decision when an error occur. The middleware should not worry about an error occurring in this function and should in this case break the chain of middleware and send the response back directly but this will not break middleware call before httpauth. If you guys want to see it in action i would be glad to put this in a PR with some test case. P.S: english is not my native language so feel free to correct my mistake and let me know if you guys didn't understand something =) |
I was experiencing a similar problem until I realized that the "wrap's" execute in reverse order and therefore the bearer authentication middleware was checking if the OPTIONS request had the 'Authorization' token (which it should not have)
|
fixed in 0.7.0 |
воиспроизводится |
Expected Behavior
Be able to use HttpAuthentication::bearer and actix-cors in the same project
Current Behavior
Hi, I am trying to use HttpAuthentication::bearer in a project that also uses actix-cors, if I use HttpAuthentication::bearer or actix-cors alone it works fine, but if I use both I get an error saying that cors has block the request due to No 'Access-Control-Allow-Origin' header is present on the requested resource.
Steps to Reproduce (for bugs)
My code is:
Your Environment
The text was updated successfully, but these errors were encountered: