Skip to main content
Solved

Authorization error when running an XMLHttpRequest

  • July 3, 2024
  • 8 replies
  • 97 views
N
Vanguard
Forum|alt.badge.img+3

Hi,

We have created a functionality that is working well in our DEV branch, but for some reason I cannot get it to work in our staging/acceptance environment. 

In a DnD area we are performing an API call to indicium. It looks like this:

xhr.open('POST', 'https://{{company_url}}/indicium/sf/go_acc/document', true);
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.send(JSON.stringify(payload));

When we try to upload a file we get a 401 unauthorized error. I've tried changing my user's authorization settings in IAM to RDBMS, Windows and IAM to no avail. I've also tried adding ‘/public/’ in the url to hopefully open to the public, this led to a not found 404 error. 

Any other things I might've overlooked that cause this error?

One thing that might be interesting, but I can't find any info on, is that our production environment runs under https://{{company_url}}/universal/ and our acceptation environment runs under https://{{company_url}}/universal_acc/. could this difference in URL cause the authentication error?

Best answer by Dick van den Brink

Hi Niels,

Can you give a little bit background info about your setup?
Did you write a custom component which you are showing in Universal through the preview component?
If so, the Indicium, Universal and the custom component are all loaded from the same domain?

In any case, did you check your browser DevTools? The console might give some information, also the cookies tab of your request should show which cookies are sent to Indicium. Sometimes it shows an icon with a warning in case something is wrong.
To rule out some issues with iframes, CORS or other browser protection features, you can also try to do the same request in Postman or Insomnia. If it works with one of these tools, it might give some clues in to what to investigate next and allows to check if the user rights/roles are correctly configured.

Did you see Jaspers post about uploading files? It might give some additional ideas, because it looks similar as what you are trying to achieve.
https://community.thinkwisesoftware.com/news-blogs-21/upload-multiple-files-using-the-universal-gui-3880?postid=16710#post16710

About some the things you tried, adding the /public/ segment only works if you created a role with 'Allow as public API', which I don't think is what you want in this case.
Changing the user to IAM/RDBMS/Windows should not really matter, if you can log in in Universal, it should probably work.

 

This topic has been closed for replies.

8 replies

Mark Jongeling
Administrator
Forum|alt.badge.img+23
  • Mark Jongeling
  • Administrator
  • 4050 replies
  • July 8, 2024

Hi Niels,

The Universal URL does not matter as you are targetting its Indicium. 

Performing https://{{company_url}}/indicium/sf/go_acc/document means your are targetting the SF meta source which most likely is not present in your acceptance environment. I think you are intending to call iam/go_acc/document to request data from "document” of the go_acc application in IAM.

However, that does not explain the authorization error. This normally means that the actor fails to provide correct log in credentials. The actor must use valid credentials to be able to perform the action. If you want to use the same account for development as well as in your acceptance environment, you'll need to create the same user in the acceptance environment IAM and give the user applicable rights.

 

"Wake me up before you low-code"
N
Vanguard
Forum|alt.badge.img+3
  • Niels KoopVanguard
  • Author
  • Vanguard
  • 45 replies
  • July 8, 2024

Hi Niels,

The Universal URL does not matter as you are targetting its Indicium. 

Performing https://{{company_url}}/indicium/sf/go_acc/document means your are targetting the SF meta source which most likely is not present in your acceptance environment. I think you are intending to call iam/go_acc/document to request data from "document” of the go_acc application in IAM.

However, that does not explain the authorization error. This normally means that the actor fails to provide correct log in credentials. The actor must use valid credentials to be able to perform the action. If you want to use the same account for development as well as in your acceptance environment, you'll need to create the same user in the acceptance environment IAM and give the user applicable rights.

 

@Mark Jongeling thank you for your answer, I changed sf to iam. I checked my user rights in the IAM, and it seems that I have the right permissions to be able to perform this action. 

I checked the IAM in our acc application and added the right platform and applications under my user in Authorization > users > user preferences. I also checked the effective user rights, and I have crud access to the document table. 

Did I miss anything?

Mark Jongeling
Administrator
Forum|alt.badge.img+23
  • Mark Jongeling
  • Administrator
  • 4050 replies
  • July 8, 2024

I would expect that should be it yes

"Wake me up before you low-code"
N
Vanguard
Forum|alt.badge.img+3
  • Niels KoopVanguard
  • Author
  • Vanguard
  • 45 replies
  • July 8, 2024

@Mark Jongeling forgot to add that I still get the same error message after these changes :)

Mark Jongeling
Administrator
Forum|alt.badge.img+23
  • Mark Jongeling
  • Administrator
  • 4050 replies
  • July 8, 2024

By any chance, do you run multiple Indiciums on the same domain? The authentication cookies are therefore shared which may cause this conflict. I've asked a colleague of the Indicium team to help out.

"Wake me up before you low-code"
N
Vanguard
Forum|alt.badge.img+3
  • Niels KoopVanguard
  • Author
  • Vanguard
  • 45 replies
  • July 8, 2024

Yes, I do think so. I read something similar in the docs which is why I asked in the original question. We have our domain, and our acceptance environement runs under a path under that domain. Our main (production) application runs on the same domain, but under a different path. 

Acceptance = {{domain}}/universal_acc/
Main = {{domain}}/universal/

D
Moderator
Forum|alt.badge.img+3

Hi Niels,

Can you give a little bit background info about your setup?
Did you write a custom component which you are showing in Universal through the preview component?
If so, the Indicium, Universal and the custom component are all loaded from the same domain?

In any case, did you check your browser DevTools? The console might give some information, also the cookies tab of your request should show which cookies are sent to Indicium. Sometimes it shows an icon with a warning in case something is wrong.
To rule out some issues with iframes, CORS or other browser protection features, you can also try to do the same request in Postman or Insomnia. If it works with one of these tools, it might give some clues in to what to investigate next and allows to check if the user rights/roles are correctly configured.

Did you see Jaspers post about uploading files? It might give some additional ideas, because it looks similar as what you are trying to achieve.
https://community.thinkwisesoftware.com/news-blogs-21/upload-multiple-files-using-the-universal-gui-3880?postid=16710#post16710

About some the things you tried, adding the /public/ segment only works if you created a role with 'Allow as public API', which I don't think is what you want in this case.
Changing the user to IAM/RDBMS/Windows should not really matter, if you can log in in Universal, it should probably work.

 

N
Vanguard
Forum|alt.badge.img+3
  • Niels KoopVanguard
  • Author
  • Vanguard
  • 45 replies
  • July 8, 2024

@Dick van den Brink Hi Dick, thank you for your reply, and @Mark Jongeling thank you as well. This led me to finding the correct answer. I was firing the indicium path, so the cookies were being sent to indicium, while we also have a different indicium for the acceptance environment. Did not notice that in my debugging…

Anyways, it works now. And I did indeed follow the guide you linked too! Thanks again. 

Terms & ConditionsCookie settingsAccessibility statement