Not sure if this is a known thing but today I spent several hours trying to figure out what the hell was going on when trying to login to my http://localhost instance of Squidex.
While logging in worked in Firefox, in Chrome I couldn’t get passed the login pop-up.
I first had some issues with Chrome redirecting from http to https automatically. This I knew how to fix from before by deleting localhost from the HSTS settings in Chrome.
Then it took me a while to come up with the idea to check dev tools console for the popup window. And here’s where I saw this message I’ve never seen before about “Mark cross-site cookies as Secure…”
After a quick google search I ended up disabling this feature in Chrome by going to the following setting:
chrome://flags/#cookies-without-same-site-must-be-secure
So the default is obviously that it’s enabled.
Is Squidex in need of a fix for this? Or what else can be done in the future to not run into this issue?
The fix is to run it with https. I have already made the fixes for that, it also runs in https mode by default.
okay. Will try that out.
And for those that want to set up Squidex quickly without LetsEncrypt and HTTPS?
Okay I noticed that with that flag disabled I cannot login to my https live domain.
BTW; what exactly does SQUIDEX_FORCE_HTTPS=True do?
And second question:
When would I need it?
docker-compose-noproxy.yml
Fixes in dockerfiles.
7 months ago
docker-compose-noproxy__open-mongo.yml
Fixes in dockerfiles.
7 months ago
docker-compose.yml
Fixes in dockerfiles.
7 months ago
docker-compose__open-mongo.yml
Fixes in dockerfiles.
7 months ago
What do you mean by “open-mongo”?
open-mongo means an open mongodb port. Should not be used.
SQUIDEX_FORCE_HTTPS means that Squidex makes https redirects if you are running under http, which is only needed when the reverse proxy does not do it. Usually it does it anyway.
http is not supported anymore. It is a browser restriction I cannot fix. Anyway I think it is a good thing, because Squidex is secure by default and uses open standards and certified components for security.
Okay thanks for clarifying. Sounds great to me, no more do I need to worry about which mode to use (http/https).
Still a bit confused.
So now that we must use HTTPS won’t that mean that these two files will be rendered obsolete?
docker-compose-noproxy.yml
docker-compose-noproxy__open-mongo.yml
Also; I want to be able to install Squidex using docker compose on my local machine. I don’t want to create one on let’s say Azure and I don’t want to work against a remote instance of Squidex.
I also read somewhere that I can’t use “localhost”, but instead I must use e.g. “localhost.squidex” as my local dev domain.
I have this in my .env file:
SQUIDEX_PROTOCOL=https
SQUIDEX_FORCE_HTTPS=False
SQUIDEX_DOMAIN=localhost.squidex
…
…
and I’ve added localhost.squidex to my hosts file on my Windows machine. I ping localhost.squidex and it’s indeed pointing to 127.0.0.1
So what do I need to do next in order to get LetsEncrypt and the reverse proxy to work?
ATM I’m getting a “503 Service Temporarily Unavailable” for some reason. I guess it has to do with the certificate missing? Although the letsencrypt container logs doesn’t show me any errors.
Please advice.
PS. I’m trying to get it up and running using this file btw: https://github.com/Squidex/squidex-docker/blob/master/standalone/docker-compose.yml
Also I found this in the docs:
When you use a local host name or IP address such as localhost or 127.0.0.1 your are referring to the host name. But containers inside docker cannot resolve the network routes and therefore the authentication flow fails. The solution is to either use another local hostname, that you have to configure in the host file of your Operation system or to use a real hostname, such as a public domain name.
I’ve done what I’ve highlighted in bold but still gives me the 503 error I mentioned further up.
