When chevereto is deployed via docker and is published to the public Internet, it is usually done through a reverse proxy and SSL is enabled on the reverse proxy. However, this raises a problem. Chevereto does not know that visitors will use https to access the site (normally, docker maps http ports to the outside world, because https requires certificates to be configured in the container, and many people are unwilling to do so, including me. In fact, it is not just chevereto, many applications have this problem.), and the reverse proxy also uses http when configuring the target URL. In this case, the following error will appear:
The plain HTTP request was sent to HTTPS portAt this time, visiting the chevereto page will have this effect:
The normal situation is as follows:
Because of the reasons mentioned above, the content of chevereto's response always starts with http, and the client browser will use http in subsequent accesses. However, because the reverse proxy uses https, it receives http requests on the https port, so the above error is generated.
The solution is simple, there are two options:
1. Directly tell chevereto the https protocol used by the user
"X-Forwarded-Proto" tells the backend server that the real protocol used by the client is https, and that https should be used instead of http when responding. You only need to add the following code to the reverse proxy configuration:
proxy_set_header X-Forwarded-Proto https;2. Directly modify the response content of chevereto
When the reverse proxy receives the HTTP response content sent back by chevereto, it directly uses "proxy_redirect" to change the HTTP to https and then sends it back to the user. You only need to add the following code to the reverse proxy configuration:
proxy_redirect http:// https://;Of course, you can also grab it with both hands, as a double insurance :)
However, this is only the simplest case of a level 1 reverse proxy, that is, user -> reverse proxy -> chevereto. The actual production environment cannot be so simple. For example, I am now: CDN -> total reverse proxy -> WAF (also the working method of http reverse proxy) -> chevereto. If there is a problem in this case, we need to consider the situation of multi-level reverse proxy:
1. If the "X-Forwarded-Proto" method is used, the easiest way is to configure it on the WAF (the reverse proxy closest to chevereto), because chevereto is behind the WAF, so you can just tell it directly; of course, from a standard perspective, it should be configured on the total reverse proxy and then passed through the WAF (usinghttp_x_forwarded_proto), I won't go into details here.
2. Use the "proxy_redirect" method to modify the chevereto response directly in the total reverse proxy. By the way, "proxy_redirect" is very powerful. In fact, if you are not afraid of trouble,You don't even need to use host. You can just modify the response returned by the application no matter how outrageous it is.
In fact, this is closely related to the application. Chevereto does not have the function of customizing the access protocol, domain name and port, while some applications, such as wordpress, can define the access URL (protocol, domain name, port) by themselves:
Therefore, you only need to pass the domain name accessed by the client to the http listening port of wordpress using the $host parameter in the reverse proxy chain, and wordpress will return the correct URL. However, only a few applications have this function. The vast majority of applications still simply and crudely adopt the method of "returning http when the http port receives a request, and returning https when the https port receives a request". Therefore, when there are multiple levels of reverse proxies, if you encounter a problem, you must analyze it specifically.
