Umbrella redirect 303

[billmacuk]

Hello!

Thanks for any help offered.

Two of our clients are using Cisco Umbrella and when they access our web application they encounter an issue.

(Our application is a standard JS app that makes requests to back-end APIs. Clients not using Cisco Umbrella have no issues.)

For some reason when the app sends a specific HTTPS request to our backend,  Cisco Umbrella seems to be returning a redirect 303 to the same location except its HTTP.   You can see this in the screenshot below.

Can anyone think of any Umbrella config or policy setting that would cause this?

Kind regards,

Bill

[adamwin]

Check the Activity Search to see if there are blocked domains at the same time. It's also possible these domains are going to the Intelligent Proxy. I'd have to check if either of these flows generate a 303 response. Support would know for sure. 

[adamwin]

I checked our internal docs, and it looks like 303 Redirect is used when SWG is implemented in a policy and it is redirecting a user to SAML auth.  Do you have SIG Essentials or SIG Advantage, or is this a DNS subscription?

[w-ytmrm11811]

We're facing a challenge with Cisco Umbrella's SWG where our client's API requests result in a CORS error when being redirected to gateway.id.swg.umbrella.com/gw/auth/begin/. The issue arises from the request origin being set to null by the browser on a 303 redirect after SAML authentication.

Temporarily removing credentials: "include" from our requests prevents the CORS problem by changing the response to a 307 Temporary Redirect, but our application requires credentials for proper operation.

Could you advise on any adjustments we might make on the application side to handle this scenario while still including credentials?

Your guidance on resolving this issue would be invaluable.

Thank you for your assistance.

[espereira]

We appreciate any response as our application is experiencing a very similar issue, starting almost at the same time as the first logs show it happening around 4/01.

The fetch requests are returning a 307 from the original endpoint to the following:
{host}.x.{id}.id.opendns.com/s/{host}/{path}?X-OpenDNS-Session={id}

Then another 307 from the above URL to:
{host}/{path}?X-OpenDNS-Session={id}

Then the final request fails with a 400 Bad Request because during that process the Authorization header is removed due to CORS policies. 

This issue is completely blocking many corporate users from using our portal so we appreciate any guidance on the subject.