-
Notifications
You must be signed in to change notification settings - Fork 1.7k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
'authorization' is missing in Access-Control-Allow-Headers only in a specific request #2093
Comments
Hello @mtlive ! Indeed, authentication and authorization have not been implemented in Ocelot for the Websockets feature. There's an ongoing issue, #1040, which is currently in progress. However, it's unclear when it will be resolved as there are no open PRs at the moment.
I will mark our issue as a duplicate of #1040. At least we have implement both tickets #1040 and #2093 in one PR.
When you said "directly" did you try without Ocelot or with Ocelot? Show us your
|
I don't do authentication at Ocelot, it'll be done at the service. Furthermore, this request isn't in WebSocket.
By directly I mean without Ocelot.
|
Okay, it appears I've identified the issue. However, I need to examine your C# configuration code. 🙏 Provide your Ocelot setup and configuration C# code, specifically the
|
Apologies, this isn't an actual issue but rather a misconfiguration. I will convert this to a discussion... |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
We tried to use Ocelot for our gateway, but our signalR requests (in http) ended up in Error 401 Unauthorized. I looked up the network requests and noticed that 'authorization' is missing in Access-Control-Allow-Headers:

This problem doesn't exist when connected directly or for other requests in other paths.
I even tried to create a separate route for this pass but the issue still remains.
Expected Behavior
authorization should be included in Access-Control-Allow-Headers in OPTIONS request method

Actual Behavior
It's missing
Specifications
The text was updated successfully, but these errors were encountered: