Home button sending to wrong URL

568
7
Jump to solution
11-27-2023 08:13 AM
CodyPatterson
Occasional Contributor III

Hey all,

 I had thought I fixed the issue with the redirect_uri, but it seems to continue in other places. I found that when viewing a map, and clicking on the menu button and then home, it sends back to my internal portal URL, why could that be, and could I change it?

Enterprise 11.1 | Apache 2.4

When this occurs, I also am unable to access Notebooks, and any content as a redirect_uri appears, here is what it shows:

issue.gif

If anyone has any ideas, I'd greatly appreciate it, I assume this is why I'm not able to access the Organization settings through this as well.

 

Thank you in advance!

0 Kudos
1 Solution

Accepted Solutions
JeffSmith
Esri Contributor

Hi Cody,

Yes, that url that you highlighted in your screenshot should definitely be your reverse proxy url.  It should not point to your internal url.  One way to confirm that your WebContextURL setting is being read properly is to access the following url (adjusted to point to your portal):

https://arcgis-reverse-proxy/context/sharing/rest/portals/self?f=json

You don't need to be logged in; you can access this anonymously.  Search for "portalHostname".  The value should match what you specified in the WebContextURL parameter (the https protocol is not included).  It is what the Map Viewer should be using to create that link for the Home button.

View solution in original post

0 Kudos
7 Replies
JeffSmith
Esri Contributor

Hi Cody,

Two thoughts here - first, I assume you've already done but just to confirm, you've defined the "WebContextURL" parameter in the Portaladmin system properties to match your external domain name and context, correct? 

Second depends on the specific reverse proxy you are using, but ArcGIS Enterprise relies on the "X-Forwarded-Host" header be included when proxying requests.  Some RPs like Apache httpd include this automatically.  Others like Nginx need it to be specifically set.

0 Kudos
CodyPatterson
Occasional Contributor III

Hey Jeff,

 Thank you for the reply, I actually have not configured the WebContextURL, as far as I was aware that was only if a Web Adaptor was not used, I had attempted to use it previously, and it had seemingly broken the portal until it was reversed.

I should have included it and will edit to add it, but I use Apache in order to set this up, I wasn't aware of the automatic addition so I added it myself just in case, sadly does not change anything.

Thank you again!

0 Kudos
JonathanQuinn
Esri Notable Contributor

The Web Adaptor registration page sets the "organization URL" for the portal. For example, if you access the registration page by going to https://enterprise.domain.com/portal/webadaptor, the portal will use https://enterprise.domain.com/portal as its front-end URL. Any request to the portal that isn't made to that URL will redirect to the internal machine name of the portal.

Below is a link describing the various ways the organization URL can be defined:
https://enterprise.arcgis.com/en/portal/latest/install/windows/determine-your-organization-s-url.htm

If you set up something in front of the Web Adaptor, (load balancer or reverse proxy), you'll need to set the Web Context URL and relevant X-Forwarded-Host header to make sure that Portal knows what URL it should use. 

https://enterprise.arcgis.com/en/portal/latest/administer/windows/using-a-reverse-proxy-server-with-...

You'd also need to make sure you re-write the Location header in the event portal redirects, which can happen in certain situations:

Along with the X-Forwarded-Host header, your load balancer must be able to direct redirects (HTTP response codes 301 or 302). All Location headers should be rewritten on the load balancer to ensure that the fully qualified domain name (FQDN) and context of the response match the portal's WebContextURL value.

In your case, you'd use the proxypassreverse directive with Apache:

https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypassreverse

This directive lets Apache httpd adjust the URL in the Location, Content-Location and URI headers on HTTP redirect responses. This is essential when Apache httpd is used as a reverse proxy (or gateway) to avoid bypassing the reverse proxy because of HTTP redirects on the backend servers which stay behind the reverse proxy.

0 Kudos
CodyPatterson
Occasional Contributor III

Hey Jonathan,

Oddly enough, I decided to just attempt and place the regular URL that I use into the web context url, and after about 15 minutes my Portal environment came back up and I am now able to see my Organizational settings and Licenses, but at this point, the Home button is still redirecting to the internal URL of the portal. I'm curious if this was possibly missed during an implementation when looking at the inspect console of the home button while on the reverse proxy, this is what I see, it should be like https://arcgis-reverse-proxy/ or something similar:

CodyPatterson_0-1701112111669.png

Thank you again!

0 Kudos
JeffSmith
Esri Contributor

Hi Cody,

Yes, that url that you highlighted in your screenshot should definitely be your reverse proxy url.  It should not point to your internal url.  One way to confirm that your WebContextURL setting is being read properly is to access the following url (adjusted to point to your portal):

https://arcgis-reverse-proxy/context/sharing/rest/portals/self?f=json

You don't need to be logged in; you can access this anonymously.  Search for "portalHostname".  The value should match what you specified in the WebContextURL parameter (the https protocol is not included).  It is what the Map Viewer should be using to create that link for the Home button.

0 Kudos
CodyPatterson
Occasional Contributor III

Hey Jeff,

Thank you for another reply, I've went to that link and it does seem as if it's still my internal portal URL. As far as I'm aware, this and our Notebook server displaying invalid redirect_uri seems to be the only issue past what we have fixed so far.

Anything I should try next?

Thank you!

0 Kudos
CodyPatterson
Occasional Contributor III

Hey Jeff,

An update, for some reason, it has changed, I have changed nothing, but it's all working now!

I wouldn't know for sure without seeing your link, so thank you!

0 Kudos