Latest Contributions by RandallWilliams

When I opened your app, I hit the F12 button and refreshed the page. In most browsers these days, F12 will bring up the debug console.  The debugger captures and enumerates all the requests and responses the browser is making and receiving from resources on the web. From in the debugger I clicked the console tab, which showed me a few errors that I knew to be related to security mismatches. I then clicked the 'network' tab, where I could see the ArcGIS Server endpoints your application was referencing and saw that the protocol over which the services were requested was http instead of https. In general, websites are a hodgepodge of resources, images, and web services collected from all over the place and presented in one aggregated form. The debugger can help us see from where these resources are coming from, manipulate resources on the fly, issue requests and queries to the application server, find bottlenecks, etc. ... View more

Yes, best form. While I want to be 'real', I'm also active in the security realm and would lose reputation points if I promoted a self signed cert over a CA signed cert, but at the same time wanted to provide real world options. There's no need to remove your current certificate. When you upload/import the signed certificate, you'll be prompted to supply an alias, which is basically a label for the cert. Like the self signed cert has the alias 'SelfSignedCertificate'. For your CA signed certificate, I might provide the alias 'GoDaddyG2_certificate_05242017'. After the certificate is updated, you go into 'Machines' in the admin API and update the machine properties. You'll see an option to update the certificate alias - you'd update that to reflect the alias of your new certificate, which is how the web server will map to the certificate in the keystore. https://server.arcgis.com/en/server/latest/administer/windows/configuring-https-using-a-new-ca-signed-certificate.htm#ESRI_SECTION1_96040AD6BEE04C1BA8D781D2CB2A8557 ... View more

Honestly, it's a matter of preference and philosophy when it comes to the internal web server, but in general I'll state that using a CA signed cert is preferable to a Self-Signed cert. With that said... A certificate signed by a reputable Certificate Authority provides you with the following: Confidentiality: protecting the information from disclosure to unauthorized parties. Integrity: protecting information from being modified by unauthorized parties Non-Repudiation: you are who you say you are and information you provide cannot be disowned A self-signed certificate will provide you with confidentiality and integrity, but since when you create a self signed cert, you're essentially vouching for yourself, it won't provide non-repudiation. Also, a CA will provide their root certificates to vendors like Microsoft and Oracle (Java) to be provided to client machines via updates. In this manner, browsers know which certificates to 'trust'. Because self signed certificates aren't created via a CA, users have to take steps so that their systems will 'trust' the certificate. In the case of ArcGIS Server, users typically expose services to the outside via a proxy of some sort, like the Web Adaptor or some other reverse proxy. Users aren't aware of the internal systems, they only know about the web tier. They won't get errors regarding the certificate being untrusted. Internal users, however, if they connect to the GIS Server using HTTPS on port 6443, will get browser errors unless they import the certificate into the browser. For these users, non-repudiation might not be a big deal - but in the scheme of the internet in general, non-repudiation IS a big deal and keeps users from falling victim to attempts to impersonate some organization. So basically: if you only allow users to access the GIS Server via the web server front end and deny access via the GIS Server on port 6443 with a firewall or something, while it's considered bad form, this configuration is valid and secure - especially when coupled with secured services. Many folks do use the self signed cert on the GIS Server back end with a CA cert on the front end. It comes down to your particular organizations security posture. To answer your question though, you're working with two independent web servers. Updating the CA signed cert at the front end doesn't touch the back end, and vice versa. Hope that helps, Randall ... View more

A few questions: Are you discussing the certificate at the GIS tier, or the certificate at the Web tier? Like, for instance, in house here I use ArcGIS Server's self signed certificate at the GIS tier, but access my GIS Server via the web adaptor. At the web tier, I have signed CA certificates. So in my case, when the self signed certs expire I just create a new one using the ArcGIS Server admin API, and when my CA signed certificates expire, I get a new one from the CA. If you don't use the web adaptor, then you'd use the admin tools in the admin API to bring the new cert into the ArcGIS Server keystore. Because ArcGIS Server uses a Java web server, it only uses the system keystore when ArcGIS Server is acting as a client. You can certainly have a CA signed certificate that you imported into ArcGIS Server AND a CA signed certificate at the web tier. ... View more

Hi Russell, I'm unsure I understand what you're after here. There isn't really an anonymous built in credential used for accessing web services. Are you looking to support a mix of public and private services, where you're using Integrated Windows Authentication and users from an AD domain? If you can explain your environment and goal, I think we could provide better direction. ... View more

Hi Angelia, I usually use bitly, but that's more of a URL shortener and doesn't let you customize. If you've got a web srever you can leverage, you can download the app and host it there, using whichever domain name you have registered. ... View more

Here's better doc: https://blogs.esri.com/esri/arcgis/2014/10/07/public-access-to-arcgis-online-premium-services/ ... View more

You can use the routing tools and directions template publicly. In this case, I think that the workflow is like this (I'm trying to find the DOC): a.    Right now, your org is configured to use the default routing service. Your browser is passing the credentials of your current ORG account to the routing server. b.    What needs to happen in this case is to use ArcGIS.com to create a proxy to automatically pass your organization credentials when using routing - but understand that this will consume credits. c.      To do that, you can add this as an item to your 'My Content' on ArcGIS.com: https://route.arcgis.com/arcgis/rest/services/World/Route/NAServer d.      When you press 'OK', you should be prompted for credentials. Provide your named user credentials, and choose the option to 'save credentials'. This will create the proxy. e.    Now when the item is created, in the bottom right of the items detail page, you should use a URL. It should read like the URL is for https://utility.arcgis.com/usrsvcs... - not https://route.arcgis.com. Use the 'copy' button to copy this URL. f.    Finally, in My Organization>Edit settings>utility services, paste the URL copied in step 'e' above in to the 'Directions and Routing' combo box. I'm unsure which changes, if any, you'd need to adjust on the app side. It may just be to reconfigure the routing widget to use the URL from https://utility.arcgis.com, as that URL routes through the proxy you created when you saved the credentials with the item. ... View more

Hi Angelia, I'd start looking at this by opening the F12 Dev tools in your browser and have a look at the traffic. This sounds kind of like a mixed content issue. When I tried to look at your apps it looks like they're not shared to the public - I was redirected to your organization log in page. ... View more

I wouldn't consider this behavior expected. I'd log a case with Esri Support detailing your Enterprise GIS version, shared storage configuration, etc. so that this can be tested in-house. ... View more

OK. My guess is that in the HTTPS sample that worked, you have a certificate from a valid CA at the web tier. In the example where you're using the internal web server on :6443, are you still using the default self signed certificate? http://server.arcgis.com/en/server/latest/administer/windows/configuring-https-using-a-new-ca-signed-certificate.htm ... View more

Hi JB, It's a little hard to tell based on your post, but I'll take a stab. First, you may be running into mixed content issues. I see you've added your service to ArcGIS.com using https, but are you also accessing your web map/web app using https? If you're using http, I can see the browser complaining. You can confirm by opening up a new web map and pressing F12 on your keyboard to open the browsers DEV tools and clicking on the console view to look at any errors generated. Hopefully that tells you the issue. To be clear - you're able to add your service as an item to ArcGIS.com, but you're unable to add it to a web map, is that correct? Also, is the resource you're adding secured  - like does it require username/password to access? ~Randall ... View more

1. While enjoying the expo, if a product island is slammed, you can likely find insight at the Support Neighborhood. In general, Esri support analysts are there to represent Esri's best of class Support. If you've used Support Services in the past, there's a good chance you'll get to meet your hero! 2. Second KGerrow-esristaff‌'s tip on the hidden taco truck. 3. In addition to studying up on the sessions you'd like to attend, compile a list of GIS questions/issues/requests/ideas that you'd like to discuss with product teams. UC represents a unique opportunity to speak one-on-one with the folks who develop the products you rely on. Your feedback counts! 4. Speaking of Support Services, use the My UC site or app schedule an appointment ahead of time. Even folks without a Support contract can leverage this resource. Many customers bring a machine to help demonstrate a question or workflow, and some even VPN into their environment for in depth troubleshooting! ... View more