
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-30-2020 09:42 PM
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": ["*"]
},
}
const fetchUserEffect = createHttpEffect('/api/now/table/sys_user?sysparm_limit=1', {
method: 'GET',
successActionType: USER_FETCH_SUCCESS,
errorActionType: USER_FETCH_ERROR
});
Solved! Go to Solution.
- Labels:
-
Now Experience UI Framework
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-30-2020 02:54 PM
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-24-2020 11:07 AM
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-24-2020 01:16 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-30-2020 02:54 PM
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2020 12:27 PM
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-27-2024 03:14 AM
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