Assuming you are hosting both Univeral and Indicium on IIS, are you sure you have all prerequisites as described here: https://docs.thinkwisesoftware.com/docs/deployment/indicium#prerequisites ?

A missing URL Rewrite Module might cause such problems.

 Hi ​@Marcel Zuur ,

The URL Rewrite Module is installed. However, maybe a rewrite rule is missing that should be there. 

At this moment these are the rewrite rules that are in place for indicium. 

This is the only rule that is in place on the universal web page: 

Am I missing rewrite rules?

Hi Mark,

Could it be that the Indicium, Universal and the custom component are not on the same web domain? Otherwise it would be a strange error as the authentication should have been taken care of. Perhaps other Community members know more about integrating this custom component.

Hi ​@Mark Jongeling 

I'll try and figure out if all the components are on the same web domain. De web domain is maintained by another partner of the client, therefore I don’t have full rights to change or look into the settings of the on premise enviroment.

Another weird thing is that on the test enviroment (hosted on Azure) logging into either the https://my-appl/universal or https://my-appl/indicium makes it so your are automatically logged in to both the webpages. On the on premise environment, I have to log into both web pages seperately. I think that this is the problem causing the unauthorized error. However, I still am unsure as to how to fix this problem.

Seems like the on premise environment has some sort of wrong configuration then. Placing the components all on the same web domain should fix this issue. Hope that is it!

​Hi @Mark Jongeling ,

Both indicium and universal are on the same webdomain ThinkACC as shown in the docs: 

I am still running into this issue due to the fact that the partner of the client is on leave, so any other ideas would be welcome!

This is quite odd, but I’ll see if we can somehow provide some pointers.

When the error occurs, can you check the Network log to see if the cookies sent with regular Universal traffic are the same as the cookies sent with the upload POST?

The 401 indicates an unauthorized and this should be reflected in the absence of identity-related cookies on the request.

A reason that the cookies are not shared would be a difference in the domain name. For instance, Universal uses a FQDN https://my-app.mycompanynetwork.com/ for Indicium whereas the custom component users http://my-app.mycompanynetwork.com/ or https://my-app.com/ or https://my-app.mycompanynetwork.com:8090/ or something like that.

Directly accessing the Indicium URL may result in a minor redirect to a different FQDN which causes the new session to be started on the same domain as the one the custom component uses, thus allowing access.

Hi Anne,

The difference I can find between the cookies are that the regular Universal traffic contain a idsrv.session where the POST upload doesn’t. Also, the .AspNetCore.Identity.Application are different for both actions. 

The post request uses the following URL https://URL/Indicium/iam/p2p/cases(/parameters])/detail_ref_cases_cases_document. Normal actions use 62 instead of the P2P alias. For example: https://URL/Indicium/iam/62/cases_payment.cases_payment_no_detail(_parameters]/layout()

So as far as I am concerned, I dont see any differences between the URLs other than the ID of the app versus alias of the app.

My gut says that the error has something to do with how the on premise server is set up. Do you have any other idea’s that I could look into?