Received CORS issue trying to reproduce quickstart demo in Rails

Help
,
1

I tried to add auth0 to a Rails web app following the quickstart demo (I’ve successfully done it before with SPA and Rails API) and received an error.

Screenshot 2021-03-26 154114
Screenshot 2021-03-26 154114855×82 4.62 KB

As a reference and to check everything, I downloaded the configured quick start demo and executed it against the same tenant and app and works. I’m trying to find a relevant difference with no luck so far.

  • Tenant app’s settings for Allowed Callback URLs, Allowed Web Origins, and Allowed Origins contain both. In “Allowed Callback URLs” includes the path.
  • New app: Rails 6.1.3, Quickstart app: Rails 6.1.1. Ruby version 3 and 2.7.
  • On login click both apps call auth0 SDK.
    • The new app generates an OPTIONS request and a GET request, the latest got blocked by browser due to CORS afaik. Also, I saw NS_ERROR_DOM_BAD_URI on Firefox (all tested too on edge chromium) for the second request. The target of the request is <tenant>.auth0.com/authorize. Headers are pasted below.
    • The quickstart app generates a GET request to .../authorize and another to .../login, works fine, isn’t blocked by the browser. The first one returned 302, the second one 200.
  • The secured.rb concerns are equal on both. Routes typed the same. Other controllers are similar to each other.
  • As the quickstart is working I don’t think the issue is related to configure the app via HTTPS and with a DNS name different than localhost. However, I managed to configure it that way, configuring puma to use HTTPS and with a DNS defined in the host file. I got the same results.
  • I attached the gemfiles for both apps.

I need any ideas to make it work on the new app.

Failed Request 1 headers

OPTIONS /authorize?client_id=h2hqE7WyxWID3l6APK3E9MBLSW6o8f8U&leeway=60&nonce=89a9191c70f7b65e6e9acecbcc80b026&redirect_uri=http%3A%2F%2Flocalhost%3A3002%2Fauth%2Fauth0%2Fcallback&response_type=code&scope=openid+profile&state=e55b5abf080bd564dd2c38b1b891d4326a2465b7c4c262cc HTTP/1.1
Host: ***********.us.auth0.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: */*
Accept-Language: en-US,en;q=0.7,es;q=0.3
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: GET
Access-Control-Request-Headers: x-csrf-token
Referer: http://localhost:3002/
Origin: http://localhost:3002
DNT: 1
Connection: keep-alive

Failed (browser blocked) Request 2 headers

GET /authorize?client_id=h2hqE7WyxWID3l6APK3E9MBLSW6o8f8U&leeway=60&nonce=7f5ec38dda29e8e2ba9ee3f3f80ac8b6&redirect_uri=http%3A%2F%2Flocalhost%3A3002%2Fauth%2Fauth0%2Fcallback&response_type=code&scope=openid+profile&state=59b384d8e8fa7cd3b272a21b45e2b79f362f68c35dc9d133 undefined
Host: ********.us.auth0.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: text/vnd.turbo-stream.html, text/html, application/xhtml+xml
Accept-Language: en-US,en;q=0.7,es;q=0.3
Accept-Encoding: gzip, deflate, br
Origin: http://localhost:3002
X-CSRF-Token: yo20b-N0AXbGYuYPAvJFYQt1L9powVvcxmGJ3ogfLEdgA6kRlqI4GqClwLNyu0ojJI_79UgPh2C8KG5U1bNJbw
Referer: http://localhost:3002/
DNT: 1
Connection: keep-alive

Gemfiles

Tenant configuration

Application Type

Regular Web Application

Token Endpoint Authentication Method

Post

Allowed Callback URLs

http://localhost:3002/auth/auth0/callback, http://localhost:3000/auth/auth0/callback

Allowed Web Origins

http://localhost:3000, http://localhost:3002

UPDATES

  • I’m using turbo (from hotwire), checking now any possible problem because the js actions are delegated to it.
1 Like
2

Hi nils,

When making a request to /authorize this should be a top-level navigation, not a cross-origin request (e.g. using fetch or XMLHttpRequest APIs). Making a cross-origin request causes the browser to attempt a CORS Preflight, which is not supported for this API.

Can you share how you are triggering the request GET /authorize?client_id=h2hqE7WyxWID3l6APK3E9MBLSW6o8f8U&...request? Is the request made by an Auth0 SDK?

2 Likes
3

Yes, it’s made by an SDK.
In this case:

gem 'omniauth-auth0', '~> 2.5'
gem 'omniauth-rails_csrf_protection', '~> 0.1'
4

Thanks @nils,

The important thing here is what is happening in the browser, as that is where CORS errors may pop up.

I can see in your screenshot of the Network tab above that the request to /authorize is being initiated by “turbo”. I’m not familiar with that library but from reading https://turbo.hotwire.dev/handbook/introduction#turbo-drive%3A-navigate-within-a-persistent-process it looks like it may be attempting to do a cross-origin fetch of /authorize, which is not supported.

The OAuth 2.0 authorization endpoint is not designed to be called programmatically (for example using xhr or fetch request from Javascript) so you will need to disable Turbo for /authorize for this to work.

3 Likes
5

Thanks, @luuuis, that should be the problem indeed, I’ll confirm later and mark the solution, right now I couldn’t cut turbo from this button action in particular despite supposedly using data-turbo="false".

6

Hi @luuuis, confirmed, I disabled turbo and the login navigation action works. Of course, the problem of disabling turbo on this specific form (nested in turbo frame) is not related to auth0 and I’m subscribed to the specific failed scenario on the hotwire community.

1 Like
7

Glad it’s working now and thanks for sharing that with the rest of community!

1 Like
8

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.