NOW Experience - Proxy HTTP Calls

royjustus · ‎03-30-2020

I've been trying to get the HTTP request proxy to work and so far it's working perfectly in the instance once deployed but I suspect there's something wrong with my proxy configuration because it's not authenticating when I run "now-cli develop".

now-cli.json is:

{

  "development": {
    "proxy": {
      "origin": "https://dev100***service-now.com",
      "headers": {
        "Authorization": "Basic SGFoYSB5b3UgdGhpbmsgdGhpcyB3b3VsZCBiZSBteSByZWFsIHBhc3N3b3J"
      },
      "proxies": ["*"]
    },
}

modified

and my code (which works in-instance) is:

const fetchUserEffect = createHttpEffect('/api/now/table/sys_user?sysparm_limit=1', {
    method: 'GET',
    successActionType: USER_FETCH_SUCCESS,
    errorActionType: USER_FETCH_ERROR
});

What am I missing here? I've tried with and without batching and verified the username and password.

Console shows 401 error, packet inspection in fiddler confirms the Auth header is missing. If I add Authorization directly in the index.js then fiddler shows it in the outbound request but the instance gives the same response.

Any ideas?

Roen · ‎04-30-2020

Hey royjustus!

I just successfully did a GET call from my now-cli project after hours and hours of pain.

What I have come to realize is that now-cli completely ignores the now-cli.json file and anything you do in it except if you change your port, then it gets confused.

What I did to solve the problem. Is that I had to add my instance to the api request, AS WELL AS adding cors anywhere from heroku to get around cors errors.

I ALSO directly added my authorization into the header in the request, as again, the now-cli ignores the .json file. Atleast when in develop mode.

const fetchUserEffect = createHttpEffect(
	"https://cors-anywhere.herokuapp.com/https://dev11111.service-now.com/api/now/table/sys_user?sysparm_limit=10",
	{
		method: "GET",
		successActionType: "USER_FETCH_SUCCESS",
		errorActionType: "USER_FETCH_ERROR",
		batch: false,
		headers: {
			Authorization: "Basic bmljZXVzZXJuYW1laGVyZ3dvcmRoZXJl=",
		},
	}
);

This went straight through and was accepted.

instance id and auth key has been changed.

View solution in original post

Akash Rajput · ‎04-10-2020

Looks like even if you deploy it on instance, you will get error saying that 'r is undefined'

Brian Ogden · ‎04-23-2020

@royjustus I have not seen the proxy configuration "proxies": ["*"] before, try explicitly setting the default allowed proxies to an instance which are ['/amb/**', '/api/**']:

{

  "development": {
    "proxy": {
      "origin": "https://dev100***service-now.com",
      "headers": {
        "Authorization": "Basic SGFoYSB5b3UgdGhpbmsgdGhpcyB3b3VsZCBiZSBteSByZWFsIHBhc3N3b3J"
      },
      "proxies": ['/amb/**', '/api/**']
    },
}

DrewW · ‎04-24-2020

Why two * and not one?

Also I did try this and I'm still getting a 401 not authorized message.

royjustus · ‎04-24-2020

Same here with both one and two *.

The key is that the proxy is re-directing the call to the service-now instance as evidence by my Fiddler captures. The gap seems to be that it does not add the appropriate authorization header based on the config which results in a 401.

We've heard from a number of folks who do have this issue, is there anyone out there that has gotten the proxy config to work locally?

Brian Ogden · ‎04-24-2020

It might be possible that your system admins have shut down endpoints for basic auth on the instance for security reasons. Chances are, they haven't done the same for the table API because they didn't know the setting exists on the instance. That could be why deploy works but local doesn't.

And also why this issue is being experienced by others. Because disabling basic auth is a common security setting to disable.