NOW Experience - Proxy HTTP Calls

royjustus
Tera Contributor

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?
1 ACCEPTED SOLUTION

Roen
Kilo Expert

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

14 REPLIES 14

That is theoretically possible but there are three reasons why that can't be the issue here: 

1. The instance does support basic auth and I can make a successful call via postman by taking the exact message and headers sent from the local process and adding a basic authorization header. 

2. The call leaving my computer locally does not have an authorization header at all. Without an authorization header we will always get 401 unless our web service does not require authentication (which would be bad)

3. I suspect many people who have this issue are working on dev instances where in fact the basic authentication is enabled by default. 

 

So I found my issue, my issue was that I made the stupid mistake of thinking that when I did a now-cli login and it told me that it saved the info that it saved it in the now-cli.json file.

I used atob() to see what it was and it was admin:admin.

So maybe your base64 encoded user name and password are wrong on the now-cli.json file.

 

 

Roen
Kilo Expert

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.

 

 

 

One thing that I found was when you do a "now-cli develop" and then a ctrl+c to cancel it that part  node stays running in the background and at least on a windows box you need to kill it off to have your proxy settings change.

Also when I use this as a proxy setup

{
  "development": {
    "proxy": {
      "origin": "https://<MYINSTANCE>.service-now.com",
      "headers": {
        "Authorization": "Basic <BASE64 encoded username:password>"
      },
      "proxies": ["/api", "/amb", "/*.jpg"]
    },
    "test": {
        "unit": [
            "@servicenow/cli-jest-plugin"
        ]
    }
  },
  "styles": {
      "themes": [{
        "module": "@servicenow/sass-theme",
        "main": ["theme.scss"],
        "copyFiles": ["type/*", "*.scss"]
      }]
  }
}

 

That this code will work just fine

const getTableRow = createHttpEffect('/api/now/table/:table/:id', {
    method: 'GET',
	pathParams: ['table', 'id'],
	queryParams: ['sysparm_fields', 'sysparm_display_value'],
	startActionType: DATA_REQUEST_STARTED,
    progressActionType: DATA_REQUEST_PROGRESS,
    successActionType: DATA_SUCCEEDED,
    errorActionType: DATA_FAILED
});

dispatch(DATA_REQUESTED, {
	table: 'u_bok_aig',
	id: '0003194ddbc4541086e6876f68961950',
	sysparm_fields: 'u_active, u_name, u_start, u_end, u_account, sys_id',
	sysparm_display_value: 'true'
});

 

So I wonder whats different with your config that makes it so you have to add the extra things to the code to get it to work.  Is it because you are setting batch to false?

Ceatry
Tera Contributor

I'm late to the party but this issue is what i got now, after upgrading SNC from 1.1.0 to 1.1.2
With the new version I always get "User Not Authenticated". 

 

if i try manually with snc i get a valid response.

snc record get

 seems like snc is connected, but as you said it does not pass the auth to the proxy requests.

Do you have any update to your issue? Since this component should run on other instances aswell, i can not hardcode the endpoint