Auth0 Home Blog Docs

CORS error calling passwordless from Cordova

cordova
spa
passwordless
cors
ios

#1

Context:

  • SPA
  • Hybrid
  • Using Cordova and WKWebview
  • Not using Locks
  • Passwordless login

Our app works fine in the web, but the same code base is getting an auth0 error in iOS (Cordova). To prevent sending a null origin, we use cordova-local-webserver.

During the passwordless login, we have a POST to https://{app}.auth0.com/passwordless/start which generates the following log:


{
  "date": "2017-05-10T12:38:16.181Z",
  "type": "fco",
  "description": "Origin http://localhost:49634 is not allowed.",
  "connection_id": "",
  "ip": "189.6.84.54",
  "user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Mobile/14E304 (4392531984)",
  "details": {
    "xhr": false,
    "method": "OPTIONS",
    "origin": "http://localhost:49634",
    "allowedOrigins": 
      "https://manage.auth0.com",
      "https://auth0.com/docs",
      "https://login.auth0.com",
      "https://docs.auth0.com",
      "https://manage.auth0.com"
    ],
    "headers": {
      "x-forwarded-proto": "https",
      "x-forwarded-for": "189.6.84.54, 127.0.0.1",
      "host": "remoto.auth0.com",
      "content-length": "0",
      "origin": "http://localhost:49634",
      "access-control-request-method": "POST",
      "access-control-request-headers": "auth0-client,content-type",
      "accept": "*/*",
      "user-agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Mobile/14E304 (4392531984)",
      "referer": "http://localhost:49634/www/index.html?cdvToken=0F82EE55-BA72-4E73-B822-53D4F7656018-2355-000003C10FA3DE7F",
      "accept-language": "en-us",
      "accept-encoding": "gzip, deflate"
    },
    "host": "https://remoto.auth0.com",
    "originalUrl": "/passwordless/start"
  },
  "log_id": "49560429270835143462029482507958217094351368046241644546"
}

why are the allowed origins:

“allowedOrigins”:
https://manage.auth0.com”,
https://auth0.com/docs”,
https://login.auth0.com”,
https://docs.auth0.com”,
https://manage.auth0.com
],

shouldn’t they be the ones I setup in dashboard?


#2

@abhishek.hingnikar could you help me on this?


#3

On it, although for Cordova and derivatives on mobile you should be using https://github.com/docs/auth0-cordova and you’ll need to update the hosted login page to use Auth0Lock Passwordless. This is to enforce better security measures on Cordova / Native apps using PKCE.


#4

Hi Fred, I noticed a lot of your apps are using the client, you should not be using that additionally please don’t use wildcard ports that i think is whats causing the issue, with the repository I linked you’ll not need to use Cordova server on the device as Native apps do not enforce CORS restrictions. Additionally, all your clients should be a separate client .


#5

@abhishek.hingnikar You brought some issues to discussion. Let’s separate them.

  1. using auth0-cordova + auth0Lock Passwordless: I am understanding that to use auth0-cordova, I will have to use Lock. If so, this is not possible because we have a very different user flow.

2)wildcard: Do you mean using wildcard in Client > Settings > Allowed Origins (CORS)? Because I removed wildcards and still get the same error.

3)…


#6


3) Different clients: My app has one codebase and different deployments: web, osx (via electron), ios/android (via cordova). And that is why I didn’t create a different client id for each deployment. we see them as one app. We did, though, create a different client-id for development and it is in a different account.


#7

@abhishek.hingnikar Any news on this? Besides, our “Dashboard > Logs” is empty?!?? What happened?


#8

Even though its the same code base the grant types are different an SPA should use implicit while a native app should use PKCE and so on.


#9
  1. You don’t have to use Lock you can use the same logic using Auth0.js however, it’ll need some work on the hosted page (passwordless lock is still using Auth0.js#v7) you can have the same logic.

  2. That seems to be weird. Can you check in network logs what it is actually sending the call as ? I’ll contact you on email to setup a call and lets debug this in parts.


#10

view comment here https://community.auth0.com/answers/13630/view


#11