We are running forest admin behind VPN and our environments are:
Development: http://localhost:3310
Staging: http://localhost-staging:30007
We migrated to version 7 and now Development works fine but we are not able to connect to Staging, error:
Please verify that your admin backend is correctly configured and running and that you have access to the internet.
In the console, we are getting:
Mixed Content: The page at ‘https://app.forestadmin.com/workpuls/Staging/Admins/dashboard/105893’ was loaded over HTTPS, but requested an insecure resource ‘http://localhost-staging:30007/forest/authentication’. This request has been blocked; the content must be served over HTTPS.
Reverting to previous version of the “forest-express-mongoose”, 6.1.0, it is working perfectly fine.
Hello @ipetrovic,
You will have to support HTTPS on the staging agent. With newer version, we won’t support HTTP on other endpoints than localhost for security and compatibility reasons. Browsers are blocking more mixed content, and some requests to HTTP endpoints.
To transform a HTTP endpoint into a HTTPS one, you’ll have to add a reverse-proxy (such as nginx) and configure it with a self-signed certificate. Then, you’ll have to manually accept this certificate in your browser.
The next step will be to change the environment’s configured endpoint in Forest Admin by modifying the protocol in the URL.
Hi @GuillaumeGautreau,
This way you’ve made it so much more complicated for users that are running everything thru VPN only.
I know that you need to comply with some standards, but this could easily be just an option turned on/off by each client.
On the other side a self-signed certificate that is manually added to the browsers, doesn’t really provide extra security, just more complexity.
Hello @ipetrovic,
Actually, there are several reasons for this limitation:
- Browsers are gradually blocking some features on HTTP, some of them are necessary for the application to work correctly. Some features are now working only on localhost with HTTP, and on HTTPS. It’s becoming a pain to support HTTP, and even sometimes impossible.
- Even if your users are accessing your internal server through a VPN, the security problem remains because the exit point of your VPN will still send and receive unencrypted traffic from/to our own servers. That’s something that we don’t want when accessing production environments.
Regarding self-signed certificates, you are right. If you are using a remote environment that is used by actual users, in production, then the good practice would have to generate a valid and signed certificate, for the url. This would be simpler for the users and provide the right level of security.