Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
blocks:server:nginx [2022-12-13 13:47] – [NGINX Reverse Proxy] admin | blocks:server:nginx [2025-09-15 13:19] (current) – [Acquire Let's Encypt certificates using DNS-01 challenge] mattias | ||
---|---|---|---|
Line 9: | Line 9: | ||
It serves all static files (those under /public), rather than passing those requests on to Blocks. Offloading such work leaves more headroom in Blocks for dealing with its more advanced functions. | It serves all static files (those under /public), rather than passing those requests on to Blocks. Offloading such work leaves more headroom in Blocks for dealing with its more advanced functions. | ||
- | ====HTTPS, Domain name and Certificate==== | + | =====HTTPS, Domain name and Certificate===== |
The nginx reverse proxy can also manage a secure HTTPS connection, thus offloading also the work of encryption and decryption from Blocks. HTTPS is increasingly a requirement for many advanced web features. This applies also to Blocks, which is entirely web based. For instance, the Camera, QR Scanner and Locator (when using QR Code or GPS) block types may have limited or no functionality unless | The nginx reverse proxy can also manage a secure HTTPS connection, thus offloading also the work of encryption and decryption from Blocks. HTTPS is increasingly a requirement for many advanced web features. This applies also to Blocks, which is entirely web based. For instance, the Camera, QR Scanner and Locator (when using QR Code or GPS) block types may have limited or no functionality unless | ||
Line 21: | Line 21: | ||
Furthermore, | Furthermore, | ||
- | ===Obtaining a Certificate=== | + | ====Obtaining a Certificate==== |
You must obtain a HTTPS certificate from an accredited // | You must obtain a HTTPS certificate from an accredited // | ||
Line 50: | Line 50: | ||
Make sure to keep the space after // | Make sure to keep the space after // | ||
- | |||
- | If you want to use HTTPS for all traffic, edit the file at **/ | ||
- | |||
- | < | ||
- | # Redirect ALL http request to https | ||
- | server { | ||
- | listen 80 default_server; | ||
- | server_name _; | ||
- | return 301 https:// | ||
- | } | ||
- | </ | ||
- | |||
- | Save and exit //nano// again. | ||
Make sure you've set good, strong passwords on all your Blocks users. Finally, while still as the //root// user, run the following commands, pressing enter after each. The first of these commands checks your new nginx configuration for errors. Pay close attention to any error messages that may appear. | Make sure you've set good, strong passwords on all your Blocks users. Finally, while still as the //root// user, run the following commands, pressing enter after each. The first of these commands checks your new nginx configuration for errors. Pay close attention to any error messages that may appear. | ||
Line 86: | Line 73: | ||
If you get stuck, and need more details, follow the official //certbot// guide found [[https:// | If you get stuck, and need more details, follow the official //certbot// guide found [[https:// | ||
- | ===Using Local Wifi=== | + | If you want to use HTTPS for all traffic, edit the file at **/ |
+ | |||
+ | < | ||
+ | # Redirect ALL http request to https | ||
+ | server { | ||
+ | listen 80 default_server; | ||
+ | server_name _; | ||
+ | return 301 https:// | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Save and exit //nano// again, then test your configuration and restart nginx: | ||
+ | |||
+ | < | ||
+ | sudo /sbin/nginx -t | ||
+ | sudo systemctl restart nginx | ||
+ | </ | ||
+ | |||
+ | ====Using Local Wifi==== | ||
While you may use a local wifi network instead of making your Blocks server internet accessible, this adds more complexity for visitors in connecting to your system, since they must first connect to your local wifi and then to your blocks server. Both of these actions can be done from most modern smartphones using QR codes – but you will need two of those, and they need to be scanned in the right order. You of course also need to provide a wifi network with adequate performance and coverage. Thus, for most visitor-facing Blocks applications, | While you may use a local wifi network instead of making your Blocks server internet accessible, this adds more complexity for visitors in connecting to your system, since they must first connect to your local wifi and then to your blocks server. Both of these actions can be done from most modern smartphones using QR codes – but you will need two of those, and they need to be scanned in the right order. You of course also need to provide a wifi network with adequate performance and coverage. Thus, for most visitor-facing Blocks applications, | ||
Line 92: | Line 97: | ||
If you do opt for a local wifi network, your method for setting up HTTPS also becomes a bit more complicated: | If you do opt for a local wifi network, your method for setting up HTTPS also becomes a bit more complicated: | ||
- | - You must provide internet access to your visitors through your local wifi. This is required both to expedite the wifi connection (many phones will refuse | + | - You must provide internet access to your visitors through your local wifi. This is required both to expedite the wifi connection (many phones will hesitate |
- Your DNS entry must point to the IP address of your intranet Blocks server, now (hopefully) accessible through your wifi. That means that any attempts to access it from the internet will fail (since it's only available while on the in-house wifi). An " | - Your DNS entry must point to the IP address of your intranet Blocks server, now (hopefully) accessible through your wifi. That means that any attempts to access it from the internet will fail (since it's only available while on the in-house wifi). An " | ||
- You can't use the automatic " | - You can't use the automatic " | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||