POST
|
If your deployment is on Windows, have you installed the Web Adaptor Reliability Patch? One of the issues addressed in the patch is related to cookies and sounds similar to the behavior you are seeing. Most of those apps rely on the esri_aopc cookie for authentication. Do you see that cookie in your browser developer tools?
... View more
03-19-2024
08:42 AM
|
0
|
0
|
180
|
IDEA
|
@BenjaminRitter This auto-login process you are describing has been available in Portal for quite a while. If SAML is the only enabled login type, you should be automatically redirected to the SAML login after you click the "Sign In" button. What release are you testing this on? If you want to eliminate even having to click on the "Sign In" button, you can disable the "Allow anonymous access to your portal" option under Organization > Settings > Security.
... View more
03-06-2024
02:34 PM
|
0
|
0
|
149
|
POST
|
I wanted to follow-up on this based on some recent findings and because of the bug that was logged related to this issue (BUG-000164666). This issue is caused by how Windows handles network address resolution when IPv6 is disabled on a network adaptor. Information on this is outlined in this Windows Server KB article. In short, when you disable IPv6 on a network adaptor, Windows still resolves the internal hostname of the server to the IPv6 localhost address (::1). This is the source of the issue. For security reasons, the publishing tool blocks requests to localhost and returns the 999999999 error in these scenarios. There are 2 ways to address this: As mentioned and confirmed by many, you can enable IPv6. If enabling IPv6 is not an option or not desired, you can add the "DisabledComponents" registry value as outlined in the Windows Server help doc and set the value to "0x20" (technically "0xFF" works as well but is not recommended by Microsoft). Once the server is restarted, Windows will link the internal hostname of the server to the regular IPv4 address and the publishing process will succeed.
... View more
02-05-2024
11:11 AM
|
2
|
1
|
372
|
POST
|
Hi. Just wondering if the machine name where your Enterprise is installed happens to be mapped to the localhost IP address (127.0.0.1). There was a security enhancement added recently that limits some communication directly to localhost and I'm wondering if that may be involved here.
... View more
01-16-2024
08:48 AM
|
1
|
0
|
693
|
POST
|
I suspect you have a port conflict where Apache httpd and Tomcat are both trying to listen on port 443. That's why you are seeing the RHEL Test Page. If you are not using the Apache httpd, the easiest fix is to disable that and only run Tomcat. If you are hosting other apps on Apache httpd, it might be easier to configure Apache as a reverse proxy for Enterprise and not use Tomcat. Documentation on configuring the reverse proxy can be found here: https://enterprise.arcgis.com/en/portal/latest/administer/linux/using-a-reverse-proxy-server-with-portal-for-arcgis.htm
... View more
12-04-2023
05:09 PM
|
0
|
1
|
382
|
POST
|
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 more
11-27-2023
01:04 PM
|
0
|
2
|
480
|
POST
|
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.
... View more
11-27-2023
09:34 AM
|
0
|
6
|
524
|
POST
|
Hi Stephen, You mentioned that you have the dotnet-sdk package installed, but do you have the .NET 6 Windows hosting bundle installed (part of the .NET core runtime)? The installer should notify you if you didn't have it installed but it is worth double-checking.
... View more
10-04-2023
08:40 AM
|
0
|
0
|
488
|
POST
|
For those requests where you are seeing "net::ERR_INCOMPLETE_CHUNKED_ENCODING", can you access any of those urls directly in the browser? I'm wondering if the load balancer might be adjusting or removing the "Transfer-Encoding" response header for some reason. That would make it freeze like you are seeing. Can you access the sign-in page through the web adaptor url directly (bypassing the load balancer)?
... View more
09-26-2023
10:15 AM
|
0
|
0
|
504
|
POST
|
@NicolasGIS I agree with you that this behavior shouldn't happen when trying to add a service that is not secured to either the new Map Viewer or to the Content page. The checkurl request should only be made if the service is secured. To @Scott_Tansley's point, yes, from a security hardening perspective, it is good that more organizations are using the "allowedProxyHosts" to limit what hostnames the portal can make proxy requests to. As you observed, it is working as expected where the checkurl requests are blocked if the hostname is not in allowedProxyHosts. That being said, when trying to add an unsecured map/feature service (with CORS enabled) to the new Map Viewer, no proxy requests should be needed and it shouldn't get stuck in a loop like that. If you haven't already, could you please contact Technical Support and get a bug logged?
... View more
06-08-2023
04:47 PM
|
0
|
0
|
1837
|
POST
|
@MarjorieDillinghamGOAA - That sounds like a loopback error. If you disable IWA, are you able to access the Portal for ArcGIS page ok? If so, you probably just need to disable the loopback check on your IIS server. This link shows some different ways you can do that.
... View more
05-30-2023
08:30 AM
|
0
|
0
|
360
|
POST
|
I wanted to follow-up to my solution for this issue to clarify a few things. The way the bug was logged makes it sound like Portal logins are blocked for anyone using the IIS web adaptor. That is not the case. While the underlying issue with the unencoded curly brackets exists for anyone with the IIS web adaptor in 11.1, the OAuth login issue will only be encountered for organizations that use a front-end load balancer or reverse proxy that does not accept the curly brackets in the query parameters. Logins directly through the IIS web adaptor will work fine since IIS accepts unencoded curly brackets. Similarly, as @NicolasGIS pointed out, if the OAuth login redirects to a 3rd-party application running on a web server that blocks the curly brackets, the login issue will be observed there as well.
... View more
05-17-2023
05:08 PM
|
0
|
0
|
1267
|
POST
|
Yes, this is a known issue caused by the latest Portal Security Patch. It has been logged under the following bug: BUG-000157748 - After installing the Portal for ArcGIS 10.9.1 Security 2023 Update 1 Patch, Map Viewer's Styles panel fails to load and other panels (Filter, Clustering) subsequently fail to load. We plan to have a version B of this patch available next week to address this.
... View more
05-12-2023
04:06 PM
|
1
|
1
|
529
|
POST
|
@DavidColey Yes, I agree. Switching to a Java web adaptor even temporarily might be difficult for some organizations. I'm hoping we can get this fixed and patched soon. Keep in mind this issue will only impact organizations that use a front-end load balancer or reverse proxy that does not accept the curly braces in the query parameters. By default IIS will allow unencoded curly braces included in the query parameters so I don't think most Windows shops will encounter this.
... View more
05-08-2023
10:24 AM
|
0
|
1
|
1476
|
POST
|
@NicolasGIS- Yes, I have been able to reproduce that issue and it appears to be unique to the IIS web adaptor in 11.1. If Enterprise is configured with the Java web adaptor, the curly braces are encoded. That might be a possible workaround for you. We will work to get that fixed in the IIS web adaptor. If you want to track the status of it, please contact Support and have a bug logged.
... View more
05-02-2023
11:57 AM
|
0
|
1
|
1601
|
Title | Kudos | Posted |
---|---|---|
2 | 02-05-2024 11:11 AM | |
1 | 01-16-2024 08:48 AM | |
1 | 05-12-2023 04:06 PM | |
1 | 02-03-2023 09:13 AM | |
1 | 03-03-2015 02:23 PM |
Online Status |
Offline
|
Date Last Visited |
2 weeks ago
|