Hi! The Dashboard is pretty cool, but I have a question about how it is intended to be used. It is served by the backend, and the backend is protected by CORS. It looks like the Dashboard is intended to be accessed directly via the browser, and not through an API call. However, if I access directly from my browser, then no origin is provided with the request, which means that it gets rejected by CORS. I tested by disabling CORS, and can access the Dashboard as expected. I'm not sure how to resolve this issue because I can't seem to find a way to disable CORS just for that single route (unless I am misunderstanding how the configuration works). Here is my CORS config, **which is general to all routes due to the use of `app.use(middleware())`**:

SuperTokens.init(SuperTokensInitConfig);
admin.initializeApp();

const app = express();

const whitelist: string[] = [
  websiteDomain,
  'http://localhost:4201',
  'http://localhost:4202',
  'http://localhost:4203',
  ... etc.
];

app.use(cors({
  origin: function(origin, callback) {
    if (origin && whitelist.indexOf(origin) !== -1) {
      callback(null, true);
    } else {
      callback(new Error(`Origin ${origin} not permitted due to CORS policy`));
    }
  },
  allowedHeaders: ['content-type', ...SuperTokens.getAllCORSHeaders()],
  credentials: true,
}));

app.use(middleware());
app.use(errorHandler());

export default app;

Hey @dleangen

Hi! Ok, I see what you mean. In that case, I think that implies that the API is in production (or perhaps a proxy set up in the local dev environment, which I don't have at this time). Right now I am testing on localhost, so it would seem that this problem only occurs when testing locally.

Hmm. Why can’t you directly load the api domain on the browser?

Sorry, I guess I didn't explain well... First, my config. My apiDomain is "http://localhost:5001" because I am testing locally. I am accessing via the browser from "http://localhost:5001/auth/dashboard". I suppose that is what you mean by your comment: > Hmm. Why can’t you directly load the api domain on the browser? > Visit /auth/dashboard If CORS is disabled, then it works, yes. So in that sense, everything is "ok". However, the issue is that I also want to test with CORS enabled (and by "enabled", I also mean that I configure which origins are acceptable, not just accepting any origin). Using the "cors" module, I can configure per route, but because of the middleware, per-route configuration does not appear to be an option. The problem is that when loading from the browser, the browser does not set an origin (it is only ever set when using XHR or fetch, never when using the browser directly), so cors sees the origin as "undefined", which means that I will see this error:

Error: Origin undefined not permitted due to CORS policy

I was wondering if you have advice for this scenario. The only option I can think of is to just disable CORS when testing locally, but that is not my preferred option.

Just so I understand correctly, youre seeing a CORS error when you access http://localhost:5001/auth/dashboard on your browser?

Yes, that is correct.

This is from the cors middleware > If you do not want to block REST tools or server-to-server requests, add a !origin check in the origin function like so: > > var corsOptions = { > origin: function (origin, callback) { > if (whitelist.indexOf(origin) !== -1 || !origin) { > callback(null, true) > } else { > callback(new Error('Not allowed by CORS')) > } > } > }

That strategy (setting the origin header), as you say is a hack, and I don't really like it, but it does work. I will go with that for now. However, this to me seems like a bug. Thanks a lot for your help!

So by design browsers dont send the origin header if the request source and destination are on the same origin (because it isnt cross origin anymore) So its not really a bug because the origin is meant to be undefined for same origin requests.

Yes, I understand about the origin, thanks. The "bug" is that I have to add this hack to make the dashboard work. Seems like a fault in the design to me. 😀

i don't think it's anything to do with html being served. Even your GET APIs that are queried via the browser should fail cause of the same issue

I think we're talking past each other now. 😁 I guess the fundamental "issue" is that something intended to be consumed by a browser is being served via the API. I will just deal with it. I just wanted to provide you with my feedback as a user. I have my workaround, so I'm ok. Thank you as always for all your help!

sounds good! 🙂 Noted. We will think about how to make this better if more people have this same issue

Thanks. I really like the Dashboard, BTW!!

awesome :))