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.
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.
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.
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.
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.
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:
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?
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?
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.