Mathilde All those issues could be due to improper Nginx configuration. Please share your config.js file and your cryptpad.conf file.
Well, I should stop hoping that people do not ask for configuration files. I hoped, there was a little chance left, that one could just explain the general method of avoiding these issues. For example, according to the help messages arising from the erros on the Checkup page, I have written everything correctly & they are probably not displaying the proper solution, because they directly counter what is said in the documentation comments of the example NGINX configuration.
I am currently in the process of setting up a couple of apps behind a single dockered NGINX. Has worked so for very well for all, except for another app & now this one.
So, basically, I just need to know, how to make this work, with my own general NGINX.
I already applied the NGINX configuration, have added all the options, etc. Yes, it's all there. I have separate domains for every single major API endpoint address. Id est, files, sandbox, api, etc...
It's probably a mismatch between the NGINX configuration & config.js, as it said so on the Checkup page & the documentation of config.js inside the file is ironically pretty elaborate & seemingly detailed, but in fact it does not help a lot. It just beats around the bush, instead of really explaining, anything.
Here, examples.
/* httpSafeOrigin is the URL that is used for the 'sandbox' described above.
* If you're testing or developing with CryptPad on your local machine then
* it is appropriate to leave this blank. The default behaviour is to serve
* the main domain over port 3000 and to serve the sandbox content over port 3001.
*
* This is not appropriate in a production environment where invasive networks
* may filter traffic going over abnormal ports.
* To correctly configure your production instance you must provide a URL
* with a different domain (a subdomain is sufficient).
* It will be used to load the UI in our 'sandbox' system.
*
* This value corresponds to the $sandbox_domain variable
* in the example nginx file.
*
* Note that in order for the sandboxing system to be effective
* httpSafeOrigin must be different from httpUnsafeOrigin.
*
* CUSTOMIZE AND UNCOMMENT THIS FOR PRODUCTION INSTALLATIONS.
*/
and
/* httpSafePort allows you to specify an alternative port from which
* the node process should serve sandboxed assets. The default value is
* that of your httpPort + 1. You probably don't need to change this.
*
*/
So much text about this, which is essentially a great idea, but nowhere does it explain the important part.
Question 1: Does the NGINX need to access this port, or not? According to the official Cryptpad example NGINX configuration, it does not access port 3001, even once. Never. So, what's the point? I even forwarded the port, just to check, if the NGINX configuration does it somewhere hidden. No change.
Question 2: Does the client need to access this port directly or what? (Nowhere is this explained in any way, that mentions the important facts. It just beats around the bush.)
Question 3: How does this all work & make sense, if the port is neither even accessible by the client, nor by NGINX?
I've read all available documentation about the Sandbox mechanism, but it does not explain that. It just explains the concept, general idea & reasoning. That's it.
Next example from config.js.
/* httpUnsafeOrigin is the URL that clients will enter to load your instance.
* Any other URL that somehow points to your instance is supposed to be blocked.
* The default provided below assumes you are loading CryptPad from a server
* which is running on the same machine, using port 3000.
*
* In a production instance this should be available ONLY over HTTPS
* using the default port for HTTPS (443) ie. https://cryptpad.fr
* In such a case this should be also handled by NGINX, as documented in
* cryptpad/docs/example.nginx.conf (see the $main_domain variable)
*
*/
Again, some text, which is great, because documentation is mort important about projects. However, where does it say, that this is the truly "public facing" URL, rather than the actual URL in the background?
I can guess that roughly, with a lot of luck from the text, for example, when it mentions, that it should be the same as the $main_domain variable in the NGINX configuration, however, where do I know that, really? Nowhere is this assumption or guess of mine confirmed.
Question 1: If I'm running this inside Docker, exposing the port like 127.0.0.1:3000 on the host, the NGINX running on the host network, i.e. having access to all real 127.0.0.1 on the host, then do really put, what is inside the NGINX file or do I keep the default http://127.0.0.1:3000 entry in that place? Again, nowhere is that explained, which is one of the most important questions to answer.
Question 2: What connections are actually made? All I've seen in the NGINX configuration, it seems like it only does relatively simple things on port 3000. That's it. However, when reading the config.js, it seems like there is much more to it. The documentation is confusing, because it contradicts each other, directly.
So, you see the glimpse of the reason, why I do not post configuration files. A big reason is, it takes too much time & now I lost time too, literally just by posing the exact questions about the matter. These are, by far, not even all questions.
I just need someone having this running to tell me, how config.js matches up with the NGINX configuration in what way. How does NGINX exactly connect to the app? That's it. I don't need to know more or an analysis of my configuration.
On a first glance, the instance seemed to work alright, so the Checkup related issues are probably "minor" in the greater context.
However, I did not have time to test all features.
Please, I just need to know how the configuration files need to match up, that's it. The Docker setup I have is specifically designed in a way, that allows pretty much 1 to 1 applications of actual configurations. You don't need to do anything "Docker-specific", at all.
