- Eliminated confusing topic switch https->proxy->https. - Moved all HTTPS mentions to end of intro. - Added paragraph about when you'd want a reverse proxy. - Use /code for subpath, to encourage purpose-based naming
9.5 KiB
title | license | origin_url |
---|---|---|
Reverse proxy | Apache-2.0 | e865de1e9d/docs/content/usage/authentication.en-us.md |
Forgejo can live standalone, or behind a reverse proxy.
You may want this for scenarios like:
- Subpath mapping.
If you want Forgejo at something like
https://example.com/code/
orhttps://example.com/repositories/
instead of the defaulthttps://example.com
. - Port mapping.
If you want to run Forgejo on the standard port, and that port is already taken by another web server.
I.e. ashttps://example.com
instead of ashttps://example.com:3000
. - Proxy authentication.
Using an external login service.
Forgejo usually does not need a proxy for this, as it can be configured to talk to many login services directly.
Forgejo does not need the help of a proxy to do HTTPS, it can do it directly.
Set in SERVER
section of the configuration PROTOCOL=https
and either set CERT_FILE
and KEY_FILE
or let Forgejo manage the certificates with ENABLE_ACME=true
nginx
Basic HTTP
To set up a basic HTTP reverse proxy in nginx, create a file forgejo.conf
in /etc/nginx/conf.d
and add the following configuration:
server {
listen 80; # Listen on IPv4 port 80
listen [::]:80; # Listen on IPv6 port 80
server_name git.example.com; # Change this to the server domain name.
location / {
proxy_pass http://127.0.0.1:3000; # Port 3000 is the default Forgejo port
proxy_set_header Connection $http_connection;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
client_max_body_size 512M;
}
}
Make sure to reload/restart nginx after changing the configuration.
HTTP with a subpath
If you want to serve Forgejo on a subpath, e.g. on http://example.com/code
, use the following configuration:
server {
listen 80; # Listen on IPv4 port 80
listen [::]:80; # Listen on IPv6 port 80
server_name example.com; # Change this to the server domain name.
location /code/ { # Replace /code here with your subpath
rewrite ^ $request_uri;
rewrite ^/code(/.*) $1 break;
return 400;
proxy_pass http://127.0.0.1:3000$uri;
proxy_set_header Connection $http_connection;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
client_max_body_size 512M;
}
}
Make sure to set the Forgejo ROOT_URL
configuration key to the URL with the subpath, otherwise links generated by Forgejo will be broken.
HTTPS
When using a reverse proxy, it's usually easier to let the proxy handle HTTPS. It's easy to set up HTTPS on nginx.
HTTPS with Certbot
To set up HTTPS with Certbot, first set up an HTTP reverse proxy with the configuration above and ensure that it works as expected. To use HTTPS you need to have a domain name.
Then, install certbot. When running certbot, select the domain name that your Forgejo instance is hosted under, and choose automatic installation. This should automatically set up HTTPS on port 443 and a redirect on the old port 80.
You may wish to change the ROOT_URL
configuration key to the HTTPS protocol so links generated by Forgejo automatically use HTTPS.
HTTPS with manually installed certificates
If you have obtained certificates from elsewhere or have chosen not to let certbot automatically install them, make the following changes to the configuration file:
Change the listening ports
Change the lines
listen 80;
listen [::]:80;
to
listen 443 ssl http2;
listen [::]:443 ssl http2;
Add the SSL certificate information
Generate an SSL configuration at mozilla, and add the SSL parameters to your configuration file. Make sure to replace the paths in the example with paths to your certificate files.
Add a redirect from HTTP
Outside the server block, add this redirection block:
server {
listen 80 default_server;
listen [::]:80 default_server;
location / {
return 301 https://$host$request_uri;
}
}
This will redirect anyone visiting the HTTP site to the HTTPS site.
Apache
Basic HTTP
To set up a basic HTTP proxy in Apache, create a file 100-forgejo.conf
in /etc/apache2/sites-available
and add the following configuration:
<VirtualHost *:80>
ServerName git.example.com
ProxyPreserveHost On
ProxyRequests off
AllowEncodedSlashes NoDecode
ProxyPass / http://127.0.0.1:3000/ nocanon
</VirtualHost>
Next, enable the site with a2ensite 100-forgejo.conf
and enable the proxy modules with a2enmod proxy proxy_http
. Finally, restart the apache server.
HTTP with a subpath
If you want to serve Forgejo on a subpath, e.g. on http://example.com/code
, use the following configuration:
<VirtualHost *:80>
ServerName example.com
ProxyPreserveHost On
ProxyRequests off
AllowEncodedSlashes NoDecode
ProxyPass /code http://127.0.0.1:3000/ nocanon # Change /code here to your desired subpath.
</VirtualHost>
Make sure to set the Forgejo ROOT_URL
configuration key to the URL with the subpath, otherwise links generated by Forgejo will be broken.
HTTPS
When using a reverse proxy, it's usually easier to let the proxy handle HTTPS. It's easy to set up HTTPS on apache.
HTTPS with Certbot
To set up HTTPS with Certbot, first set up an HTTP reverse proxy with the configuration above and ensure that it works as expected. To use HTTPS you need to have a domain name.
Then, install certbot. When running certbot, select the domain name that your Forgejo instance is hosted under, and choose automatic installation. This should automatically set up HTTPS on port 443 and a redirect on the old port 80.
You may wish to change the ROOT_URL
configuration key to the HTTPS protocol so links generated by Forgejo automatically use HTTPS.
HTTPS with manually installed certificates
If you have obtained certificates from elsewhere or have chosen not to let certbot automatically install them, make the following changes to the configuration file:
Change the listening ports
Change <VirtualHost *:80>
to <VirtualHost *:443>
.
Add the SSL certificate information
Generate an SSL configuration at mozilla, and add the SSL parameters to your configuration file. Make sure to replace the paths in the example with paths to your certificate files.
Add a redirect from HTTP
Outside the VirtualHost *:443
, add this configuration:
<VirtualHost *:80>
ServerName git.example.com
RewriteEngine on
RewriteCond %{SERVER_NAME} =git.example.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
This will redirect anyone visiting the HTTP site to the HTTPS site.
Caddy
HTTPS
To set up basic HTTPS proxy in Caddy with Caddyfile create a file forgejo
in /etc/caddy/conf.d
and add the following configuration:
git.example.com {
reverse_proxy 127.0.0.1:3000
}
Caddy will automatically get certificates for the domain.
HTTPS with a subpath
If you want to serve Forgejo on a subpath, e.g. on https://example.com/code, use the following configuration:
example.com {
reverse_proxy /code* 127.0.0.1:3000
}
Make sure to set the Forgejo ROOT_URL configuration key to the URL with the subpath, otherwise links generated by Forgejo will be broken.
Proxy Authentication
Forgejo supports Reverse Proxy Header authentication, it will read headers as a trusted login user name or user email address. This hasn't been enabled by default, you can enable it with
[service]
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
The default login user name is in the X-WEBAUTH-USER
header, you can change it via changing [security].REVERSE_PROXY_AUTHENTICATION_USER
in app.ini. If the user doesn't exist, you can enable automatic registration with ENABLE_REVERSE_PROXY_AUTO_REGISTRATION=true
.
The default login user email is X-WEBAUTH-EMAIL
, you can change it via changing [security].REVERSE_PROXY_AUTHENTICATION_EMAIL
in app.ini, this could also be disabled with ENABLE_REVERSE_PROXY_EMAIL
If set ENABLE_REVERSE_PROXY_FULL_NAME=true
, a user full name expected in X-WEBAUTH-FULLNAME
will be assigned to the user when auto creating the user. You can also change the header name with [security].REVERSE_PROXY_AUTHENTICATION_FULL_NAME
.
You can also limit the reverse proxy's IP address range with [security].REVERSE_PROXY_TRUSTED_PROXIES
which default value is 127.0.0.0/8,::1/128
. By [security].REVERSE_PROXY_LIMIT
, you can limit trusted proxies level.
Notice: Reverse Proxy Auth doesn't support the API. You still need an access token or basic auth to make API requests.
Docker / Container Registry
The container registry uses a fixed sub-path /v2
which can't be changed.
Even if you deploy Forgejo with a different sub-path, /v2
will be used by the docker
client.
Therefore you may need to add an additional route to your reverse proxy configuration.