Invalid URL param hash when using alternate domain

Dane Bezuidenhout asked on February 13, 2023 13:08

We have 2 sets of domains pointing to our UAT admin site. The one set is the default Azure App Service web app domain. The second is a custom domain we own. The A record is pointing to the public IP address of the Azure web app. There is a reverse proxy enabled. If the reverse proxy is disabled, it works fine.

When we try to open any admin site dialog while on the new domain, we get a 403 Access Denied, it seems like the hash validation fails (security debug, custom domain):

4 ValidateHash False ?SelectionMode=Multiple&clientId=m_c_usRoles&hashElem=m_c_usRoles_hdnHash&hidElem=m_c_usRoles_hiddenField&localize=1&params=3d05e483-a00c-4245-86a6-27463624e916 CMSModules_Membership_Pages_Users_User_Edit_Add_Item_Dialog.OnLoad

The popups open fine on the Azure domain.

Why would the hash be affected by the domain or the reverse proxy? Unless perhaps the identity signing inside the admin site sensitive to this?

Recent Answers

Juraj Ondrus answered on February 14, 2023 08:15

What version of Kentico are you using? How are you telling the actual web server and Kentico app what is going on with the domain name in the URL before it hits the app? HAve you tried using this URL Host setting? You may also need to configure some reverse proxy IIS URL rewriting rules in your web.config file, depending on your configuration to let Kentico know what URL should be used.

0 votesVote for this answer Mark as a Correct answer

Dane Bezuidenhout answered on February 16, 2023 11:44

Kentico 13 refresh 4. We are using A DNS records to point to the public IP address of the web app (same Azure IP address for both apps). Cloudflare proxying is enabled (no way around this).

Yes we've tried the URL host setting with no effect, in fact it causes problems if you don't use the same domain for the admin and live site. When I try to use the same domain for both live and admin sites, it forces the live site to use a different path, which is undesirable.

"How are you telling the actual web server and Kentico app what is going on with the domain name in the URL before it hits the app?" - The DNS should resolve to the IP address and it does without any problems, the admin app redirects a couple of times to get to Administration.aspx. However, the admin site makes a number of requests which includes one to the live site domain (AuthenticationIframe) which returns a 404. If I try to access that directly, I get a 403. Why does it make this request?

"You may also need to configure some reverse proxy IIS URL rewriting rules in your web.config file, depending on your configuration to let Kentico know what URL should be used." - can you tell us what Kentico requires?

"Why would the hash be affected by the domain or the reverse proxy? Unless perhaps the identity signing inside the admin site sensitive to this?" - could you answer this please? I don't see why popups should have hash security issues when the rest of the admin site works with the A DNS record and proxying in place.

0 votesVote for this answer Mark as a Correct answer

Juraj Ondrus answered on February 16, 2023 13:00

This is hard to tell because we do not know your exact setup and what the network elements are doing with the requests. The bottom line is that you need to use license keys for all domains or IPs used to request Kentico admin app or the Live app. Then, if there is some URL rewriting going on, if there is some proxy or whatever, you need to tell Kentico using the config key what domain name should be expected in the request.

0 votesVote for this answer Mark as a Correct answer