Setting XMLHttpRequest "withCredentials" attribute

[EvheniyHlushko]

After updating from "@aspnet/signalr-client" to "@aspnet/signalr" because "@aspnet/signalr-client" is deprecated.

I have these errors:

Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.

The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

How can I set withCredentials attribute?

[analogrelay]

The error is occurring because we already set the withCredentials attribute. You need to adjust your CORS configuration to use specific Origin values, rather than a wildcard, because wildcards are not supported in CORS when using credentials.

[blubiszirp]

Why do you set the withCredentials attribute? Is there any possibility to remove the attribute and use a wildcard?

[davidfowl]

@blubiszirp because cookies don't flow without withCredentials and when running in environments that support stickyness via cookies, it required to function.

[JanEggers]

im on the same team / problem as @blubiszirp

we switched from

app.UseCors( builder => builder
.AllowAnyHeader()
.AllowAnyMethod()
.AllowAnyOrigin()
);

to

app.UseCors( builder => builder
.AllowAnyHeader()
.AllowAnyMethod()
.WithOrigins(corsOptions.Value.Origins)
);

and now we are getting the error:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

seems to be the same issue as #2095

[gingters]

Now that's a bummer.

We plan to provide an open API with SignalR and a JS client lib that anybody can use on their website to connect to push notifications from our server. Therefore, it is impossible to know all possible origin values, as literally everybody should be able to use that on any website.

So, we must be able to use Access-Control-Allow-Origin: *.
If you need to support cookies, then at least make setting withCredentials configurable, so that we can turn it off.

An alternative would be to extend .AllowAllOrigins() configuration on aspnet core CORS to not send the wildcard, but reply with the value of the received origin header, so that this matches, but I strongly would prefer not sending withCredentials in the first place.

Update: Okay, I forgot to set .AllowCredentials() in the first pace before adding concrete origins. When I combine .AllowAnyOrigin().AllowCredentials() on the CORS settings, the CORS engine will indeed response not with * but with the value received in the Origin header, which is totally fine.

[davidfowl]

We'll look at making it configurable, it'll be on by default and if you do happen to use cookies for sticky sessions, it will not work if you scale out and have withCredentials false. This is something we'll need to describe in our docs.

/cc @rachelappel

[JanEggers]

@gingters: thx for pointing that out.

I added .AllowCredentials() and now it works fine

[EvheniyHlushko]

Yes, .AllowCredentials() fixed

[peterdeme]

AllowCredentials() solved our issue, too. Guys, can you somehow emphasize the importance of this in the docs?

[analogrelay]

We're discussing getting the docs updated ASAP in the aspnet/Docs repo, so I'm going to close this issue since we don't think there's a work item here for the SignalR code itself. Making this configurable is not likely to help much since SignalR also requires sticky sessions which is generally implemented using Cookies, so disabling the withCredentials flag will cause that to fail.