Problem with http/https

2562
15
07-12-2018 10:57 PM
Highlighted
New Contributor II

Hi, 

i have configuration file with services. Services are available from unsecure protocol (http - only). 

When i create instance for examle of FeatureLayer, service is called from https. I have in browser CORS enabled (Chrome with plugin), but that would not affect, when service is called from secure protocol. I tried adding the server to config (corsEnabledServer), but not working... I work with API version 4.8. Interesting is, that version 4.7 work.

15 Replies
Highlighted
New Contributor III

It seems that the 4.8 API is upgrading all feature layer requests (haven't tested other request types) to HTTPS. If your server is not serving on HTTPS this causes problems.

This appears to be a bug with 4.8, as it is not mentioned in the release notes or Feature Layer documentation.

Reply
0 Kudos
Highlighted
Frequent Contributor

The update was done to avoid mixed content errors. There should be no change if your application is running on http, but if your app is running on https, we upgrade the requests.

If you're running on localhost though, localhost validates as true for isSecureContext.

To avoid this issue when developing on localhost, you can create a self-signed cert for your machine. This is a nice repo to look at. GitHub - FiloSottile/mkcert: A simple zero-config tool to make locally trusted development certifica... 

We're going to be updating our documentation to reflect this.

Highlighted
New Contributor II

Just my 2c -

Although I understand the reasoning behind I think the specific solution is causing more trouble than helping.

If possible I'd like to have an option or a switch in the API whether I want this extra behavior, or I'd rather see the mixed content warning messages in the console.


There are valid business scenarios when serving and accessing pages and layers via localhost is needed. In such cases HTTP is a good solution. By adding a fake certificate to fake security we are merely masking the issue, and not necessarily adding any security. It is rather the opposite - adding and trusting an insecure certificate that shouldn't be trusted. Imagine the case where a department with hundreds of computers will need to have a fake certificate generated and be made trusted on each of those machines.

Separately from all that, the "isSecureContext" is still an experimental technology (as per the MDN page), and that behavior may change by the time it becomes an official standard.

Reply
0 Kudos
Highlighted
New Contributor III

But the feature service is not secure. Does this now mean you cannot develop on localhost if you have HTTP services?

Reply
0 Kudos
Highlighted
Frequent Contributor

We're still testing how viable it would be to white list localhost in the API, but your best option at the moment is add self-signed certs to your local machine. That link above is one route, and there are others depending on your local needs.

We'll update this thread with any more info.

Thanks!

Highlighted
New Contributor III

I feel like we are talking at cross-purposes, can you please actually read what I am saying?

If your local machine has a self-signed certificate and you are running on HTTPS localhost then HTTP feature services will be blocked, as that is mixed content:

dojo.js:152 Mixed Content: The page at 'https://localhost:8080/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://...'

If you are running on HTTP localhost then HTTP feature services are automatically upgraded to HTTPS and cannot be accessed as they don't exist.

Unless there is some other method, setting or flag that has not been mentioned up until now: how do you access HTTP services if you are developing on localhost?

Reply
0 Kudos
Highlighted
Frequent Contributor

Yes, you're correct, I was thinking of repro'ing a prod env as much as possible. I was able to repro this at one time, but now I'm having trouble, as everything I'm testing works. Do your URLs look like "http://gisdev/arcgis/rest..." using a machine name and not a full domain?

Reply
0 Kudos
Highlighted
New Contributor III

Thanks Rene, no - it is a full domain...

Reply
0 Kudos
Highlighted
New Contributor III

I were experiencing the same problem, but as this is a customer project I cannot edit HOSTS files to get around the issue. I concur with Vladimir:

Vladimir Strinski wrote:

There are valid business scenarios when serving and accessing pages and layers via localhost is needed. In such cases HTTP is a good solution. 

Whitelisting localhost would be nice, but if that is not easily done please please please provide a configuration option that will not automatically upgrade our URLs.

Reply
0 Kudos