IDX Bearer authorization conflicts with my backend API authorization token

I’m working on a backend API, I ran the project with IDX and wanted to test the API with Postman but IDX requires a Bearer JWT token which is generated with the option “Project IDX: Generate Access token”, the problem is that this token must be passed in the Authorization header in Postman and my backend also requires this same header to pass user’s JWT token

Is there any solution to pass the IDX access token in another header instead of the Authorization header in Postman ?

2 Likes

Hello Ayoub,

I’m in the same situation as you. My setup includes two workspaces, one for the frontend and one for the backend. I was able to make the call using Thunder Client (an alternative to Postman). I changed the Authorization header to a custom header in my backend, and I was able to get a response. However, when making requests through my frontend, I still get an error: “has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”

2 Likes

Hello @Yel-kobi,
Thanks for your reply, that’s exactly what I did as a workaround to this problem, I changed the Authorization header to a custom header in my backend, and now Postman is using that custom header to pass the user’s token, and the default Authorization header to pass IDX workspace token while waiting for a definitive solution.

Hey @essayoub ,

Were you able to successfully call your backend from your frontend client as well? I’m currently facing issues with CORS and credential handling when making requests from my React frontend to my Express backend in Project IDX.

Even having both the frontend and backend on the same idx workspace gives me the same error.

I think that should be solved from your express backend, you should use express cors() module to white-list your frontend URL
here is an example:

var cors = require('cors'); //import cors module

var whitelist = ['http://localhost:8000', 'http://localhost:8080']; //white list consumers
var corsOptions = {
  origin: function (origin, callback) {
    if (whitelist.indexOf(origin) !== -1) {
      callback(null, true);
    } else {
      callback(null, false);
    }
  },
  methods: ['GET', 'PUT', 'POST', 'DELETE', 'OPTIONS'],
  optionsSuccessStatus: 200, // some legacy browsers (IE11, various SmartTVs) choke on 204
  credentials: true, //Credentials are cookies, authorization headers or TLS client certificates.
  allowedHeaders: ['Content-Type', 'Authorization', 'X-Requested-With', 'device-remember-token', 'Access-Control-Allow-Origin', 'Origin', 'Accept']
};

app.use(cors(corsOptions)); //adding cors middleware to the express with above configurations

We wrote a bit about this in this blog post: Full-stack development in Project IDX

Does that help?

From chatting with Kaushik, one of the blog post’s authors, he also mentioned this detail: “If client is remote, “Authorization” header is the only thing we support.” This is something that we hope to figure out a way to address in future.

Cheers,
Kirupa

I thought my case was isolated, I was struggling for hours until they threw in the towel, and the worst of all is that there is no information anywhere, in their documentation they give you a step to do it but it doesn’t work.

[image]

1 Like

Thanks for letting us know that our workarounds suggested here don’t work. We’ll prioritize this and explore ways of making this work in the future.

Cheers,
Kirupa