Setting Origin header for requests using node client

[mattgen88]

Hey, I have my API locked down with CORS and I need to set the Origin header for my node integration tests to run. Is there a way to tell the swagger client to send a specific origin header?

e.g.:
client = new Swagger();
client.then(function(api) {
api.default.myMethod().then(function (result) {
assert.qual(result.status, 200);
}
}

Since it doesn't send an Origin header, the request is 403'd and rejected. I cannot just adjust the CORS configuration on my server, since this is used to test deploys to servers that cannot just send *.

[webron]

CORS is only relevant to calls being made from the browser. If you're using the client in a node app, it shouldn't be an issue.

[Robbilie]

just installed swagger-client and realized its been updated to 3.0 aswell breaking my shit because i abused the clientAuthorizations of a previous version to add a user-agent which is not possible anymore so is there a way to set this header on the client somehow (no, setting it on each operation (which is supported by the swagger spec i use) is not an option for me)

also, if the server checks the origin it does not apply only to requests made from the browser @webron

[webron]

It should, but that's besides the point.

We're making some change to 3.0 to make it more backwards compatible with 2.0. It's going to take a bit to get there, but hopefully the same options that were available in 2.0 would be usable in a similar with 3.0.

[Robbilie]

so there is no way to set a header on client creation…?

[webron]

@Robbilie take a look at https://github.com/swagger-api/swagger-js/blob/master/docs/MIGRATION_2_X.md#authorizations.

[Robbilie]

@webron its not an auth header i want to set nor is it an authorization, i want to set a UA header, (X-User-Agent) which is a field i can set per request (https://esi.tech.ccp.is/latest/#/) but i dont want to pass that field on each operation so i did this in the past:

client.clientAuthorizations.add("ua", new SwaggerClient.ApiKeyAuthorization("X-User-Agent", "https://utils.space/", "header"));

[Robbilie]

oh god this is becoming the worst nightmare of my life, this new version breaks about everything

[webron]

Then don't upgrade yet.

[Robbilie]

thats about the most useless answer ever, swagger-client v3 is what you get if you install it via npm, swagger-ui is marked latest and then shit like this here happens and this isnt even the best, check this out:

#998

[webron]

Okay, it's time to take the attitude elsewhere. If you want to be a constructive community member, then by all means stick around. I will not tolerate the language nor the attitude any further.

[Robbilie]

so what do you want me to do?

[webron]

Be constructive. Understand that 3.X is a MAJOR version update from 2.X and as semver goes, it means it's a breaking change, so you can't expect everything to work out of the box.

We're aware of some issues, not all. As you find issues, it'd help if you can open tickets describing what's missing. We're all humans, we make mistakes. Let's work together on fixing them.

If you're willing to help out by submitting PRs to fix some of the issues, we'd appreciate that. If you don't know where to start, leave a comment on the issue and we'll try to guide you through. If you can't afford to submit PRs, that's absolutely fine as the tickets help us keep things in check as well.

[Robbilie]

i understand the concept of a major version update, i also would think that if something like the issue described in the other ticket exists the version would be in an alpha or beta state, rc if you want, but far from stable if something basic like post requests are not working, just my 2 cts.

atm i do not have the time to create a pr so i hope that adding to the issue someone else also has and creating a ticket for another, major issue is enough for the moment.

[mattgen88]

Well this certainly blew up unexpectedly.

My servers 403 non-whitelisted domains making requests (strict enforcement of CORS Access-Control-Allow-Origin). Thankfully, I'm in full control of what is enforcing this and I wrote into my middleware the ability to ignore private and loopback IPv4 blocks. Otherwise, I didn't have a good idea on how to fix this using the swagger library. Just something to think about, it may be a good idea to allow for some arbitrary headers to be added to requests to an API.

Keep up the good work guys, regardless.

[shockey]

@mattgen88, have you looked at the requestInterceptor option?

[shockey]

I'm going to preemptively close this ticket since (a) it's pretty old and (b) I'm fairly confident my suggestion will solve the original problem.

If I'm wrong about that, feel free to reply and I'll reopen this 😄