user error

[phildunlap]

Hi Chris,

If you're getting a forbidden error, my guess would be toward an expired cookie or no cookie at all. I would also expect that you're getting relevant log messages. Are you still getting this? You could check a few requests in the developer tools of the browser to see if the request includes a cookie. How are you logging into this instance?

[atkins.chrisw]

I just cleared my cookies. And I am still getting the error.

When I look at the console log it says this. no element found

Cookie: MANGO8080=hus65pj7gb4lpm7okd1pn4o; XSRF-TOKEN=b8e862ad-16fa-4858-ada4-e83e0daf1234
Connection: keep-alive

[phildunlap]

Hmm. I'm not seeing that.

Are you logged in as a user with 'superadmin' permission? Perhaps this user doesn't have a permissions group with 'Users View' permission?

[atkins.chrisw]

This post is deleted!

[atkins.chrisw]

Hey Phil. Have you got some time to help me with this. Im getting more users and I can't add them to the system.

[phildunlap]

When on the page that it fails on, open up the network tab of the developer tools. Click on one of the messages that got the 403 and please report if you have both the Cookie header set and the X-Xsrf-Token header set in the request

[atkins.chrisw]

Failed to load resource: the server responded with a status of 403 (Forbidden)
jquery-1.11.2.min.js:4 POST http://demo.systemvitality.com:8080/rest/v1/users 403 (Forbidden)
send @ jquery-1.11.2.min.js:4
ajax @ jquery-1.11.2.min.js:4
MangoAPI.ajax @ api.js:941
MangoAPI.postUser @ api.js:101
UsersView.saveUser @ UsersView.js:223
dispatch @ jquery-1.11.2.min.js:3
r.handle @ jquery-1.11.2.min.js:3

Response Headers
HTTP/1.1 403 Forbidden
Date: Wed, 04 Jan 2017 19:38:59 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: SAMEORIGIN
Content-Length: 0
Server: Jetty(9.2.12.v20150709)

Request Headers
POST /rest/v1/users HTTP/1.1
Connection: keep-alive
Content-Length: 231
Accept: application/json, text/javascript, /; q=0.01

X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Content-Type: application/json

Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: XSRF-TOKEN=a994ed2e-1731-4e00-bff6-10603736516f; MANGO8080=hrhzw8elv6oj15imw0139okrk
Request Payload
view source

In the Cookies tab. under the Request Cookies
MANGO and the XSRF-TOKEN both have a value

in the response cookies it is blank

[phildunlap]

I see the Cookie header as being set, but I do not see the value of the XSRF-TOKEN being passed also under the header X-Xsrf-Token: a994ed2e-1731-4e00-bff6-10603736516f

What is it that is producing this request? It's the users page, still?

[atkins.chrisw]

Yes. From the Mango Front End.

[phildunlap]

I am grasping at straws a little because it would seem like perhaps you changed something that affected this?

Perhaps I would try,

1. clearing your browser cache
2. deleting your Mango/work/jsp directory
3. Removing your overrides and restarting Mango.

And perhaps I would wonder (but assume),

1. What brower? (Chrome. Edit: I see by the network tools you have a picture of this is probably wrong.)
2. Do you experience this when using a completely out-of-the-box Mango? (No)

[atkins.chrisw]

What happens if I delete the jsp directory?

I have already tried clearing my browser cache. I typically use Chrome but I am seeing the same problem in Firefox and IE.

Also, if I remove the overrides folder. Do I just cut it out and restart. Then restart the Mango instance? Then see if it works. Then re-paste the overrides folder?

[phildunlap]

It forces Mango to recompile the cached JSPs

Yes. If that reveals where the issue is you can binary search for it or perhaps you have a suspicion.

[terrypacker]

I suspect this is a permissions problem with the user you are logged in as. 403 Responses are coded into the REST api when a user does not have proper permission. I would triple check that the user actually has the 'superadmin' permission.

If this is the case you should be seeing WARN level log messages in the logfile that look something like this:

Non admin user: <username> attempted to create user : <new-username>

The only other way to get a 403 from this endpoint is as Phillip suggested, you are either not logged in or the cookies were not set/stored properly when you did log in.