On my local Arch Linux machine I installed GitLab from via the arch wiki.
When I try to open the website on localhost:8080 or 127.0.0.1:8081 I get a page without formatting:
When I try to set a password I get:
8 errors prohibited this user from being saved:
- Email can't be blank
- Password can't be blank
- Namespace route can't be blank
- Namespace name can't be blank
- Name can't be blank
- Username can't be blank
- Username can't be blank
- Username can contain only letters, digits, '_', '-' and '.'. Cannot start with '-' or end in '.', '.git' or '.atom'.
I followed the whole guide.
The thing that to me seemed to be missing:
setting some port for gitlab in nginx
symlinking the gitlab config file in nginx (step 2.9.1)
Why is the formatting is not working, and the password change gives errors that doesn't make sense?
It took me a long time to get the unixsocket working in redis, but from the environment variable checks I did manage in the end.
Edit from the browsers dev console I get:
Refused to load the font 'data:font/truetype;charset=utf-8;base64,d09GRgABAAAAALY3ABIAAAABztAAAAAAAAC1QAAAAPcAAAHiAAAAAAAAAABHUE9TAACV9AAAFxIAAHKy/pn970dTVUIAAK0IAAAINQAAFD6g2KReTFRTSAAABtQAAAA6AAACQeO3nq5PUy8yAAACDAAAAFMAAABgZoZye2NtYXAAABxsAAADdwAABTpa8HPyY3Z0IAAAIbAAAAAoAAAAKAhGAbdmcGdtAAAf5AAAAQUAAAFzBpmcN2dhc3AAAJXoAAAADAAAAAwABwAHZ2x5ZgAAJkQAAGT0AADhaCjCChFoZG14AAAHEAAAFVwAADPIhU9AOGhlYWQAAAGUAAAANQAAADYFph12aGhlYQAAAcwAAAAgAAAAJAc2BPtobXR4AAACYAAABHEAAAj0jIVtDGxvY2EAACHYAAAEbAAABHyCc7p8bWF4cAAAAewAAAAgAAAAIARXAjxuYW1lAACLOAA...SCThVMYJIqZCqSu4rDezyzyKpY17tqhUyLsX30L+SQltAyggVZVqVMsLfPk1CNKvWoXtPreoMd2Ymd2YVd2S2+tbRTX92te3Sv7tP9egCjlnZ0oid96c/8LMkyrMgarMP67MDvNkYxV0uGjvOJFo+33umRlTnS48NR0ehv5tf6D/25M7IAAAB4AYVRRXfDMAz+K3q+jBc4DVyPmfGu56iNk9bKc9QO/ny5Y7iJP5DukGCGgtCjUDv2DZWsxsroHvmMA3jsUEM9TnoQx8NmHEMax+sKuqHdULlItRFFljsdCtZhW14qWh2mCiKj286Srwlc9vMROJ8M/Hcsak/njBZ6FrPHXtAKON/k7e/j0OQAb9h+mHVQhtg6Gm/r2TmjLVcvwbVymR6e31sY89p7uwn3o6Nvmx8XAmbUwVBOd48CVrkrwdWA8NYEbn69Ft3Z/AmDvFqGE2/fj78tvTlH0w9MfcpAGK7ZliRjjd2agD20SKpx8c34aPZXMwDpj6h5' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'font-src' was not explicitly set, so 'default-src' is used as a fallback.
password:1 Refused to load the font 'data:font/truetype;charset=utf-8;base64, d09GRgABAAAAALM7AA8AAAABq0AAAAAAAACyRAAAAPcAAAHiAAAAAAAAAABHUE9TAACIDAAAIgQAAH82Ol56cUdTVUIAAKoQAAAIMwAAFD6gNKPBT1MvMgAAAdAAAABVAAAAYGbqc4pjbWFwAAAGbAAAA3wAAAU4Vch3gWN2dCAAAAwYAAAAQAAAAEAQPwNiZnBnbQAACegAAAEDAAABcwZZnDdnbHlmAAAQvAAAbJ4AAOZUwSn/MmhlYWQAAAFYAAAANgAAADYGApswaGhlYQAAAZAAAAAgAAAAJAdbBRtobXR4AAACKAAABEIAAAjwrN1ggGxvY2EAAAxYAAAEYgAABHqHyk9obWF4cAAAAbAAAAAgAAAAIARWA2ZuYW1lAAB9XAAAAoEAAAZuOd88j3Bvc3QAAH/gAAAIKgAAEi5ynk2NcHJlcAAACuwAAAEqAAACpAoaNTMAAQAAAAEAAA...STdLpgIn7fZCqSu5rDezyzyKpZz7vqhExLsEP0L+KQltJygoVYTqVM+PxDJaFaVekJvaE39RY7sTO7sCu7sbtQL3VQf92n+/WAHtRDehiopT2d6UU/BrAAS7EsK7Em67IBO/KnjVXM1dKhE3yixfOtb3pmZY70/HBUmjxmflv/BTgtM3AAeAGFUUV3wzAM/it6vowXOA1cj5nxrueojZPWynPUDv58uWO4iT+Q7pBghoLQo1A79g2VrMbK6B75jAN47FBDPU56EMfDZhxDGsfrCrqh3VC5SLURRZY7HQrWYVteKlodpgoio9vOkq8JXPbzETifDPx3LGpP54wWehazx17QCjjf5O3v49DkAG/Yfph1UIbYOhpv69k5oy1XL8G1cpkent9bGPPae7sJ96Ojb5sfFwJm1MFQTnePAla5K8HVgPDWBG5+vRbd2fwJg7xahhNv34+/Lb05R9MPTH3KQBiu2ZYkY43dmoA9tEiqcfHN+Gj2VzMA6Y+oeQ==' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'font-src' was not explicitly set, so 'default-src' is used as a fallback.
password:1 Refused to load the font 'data:font/truetype;charset=utf-8;base64, d09GRgABAAAAAMjjABIAAAAB2mAAAAAAAADH7AAAAPcAAAHiAAAAAAAAAABHUE9TAACdfAAAIjcAAH80VqR1REdTVUIAAL+0AAAINwAAFD6g7KTPTFRTSAAABwQAAABHAAACQYV/Ri1PUy8yAAACDAAAAFQAAABgZ050kmNtYXAAAB1cAAAChQAAA/wdE0d/Y3Z0IAAAIdQAAAA0AAAANAq+BC1mcGdtAAAf5AAAAQUAAAFzBpmcN2dhc3AAAJ1wAAAADAAAAAwABwAHZ2x5ZgAAJnAAAGxKAADg/GpVnLBoZG14AAAHTAAAFhAAADPIAPyiAmhlYWQAAAGUAAAANQAAADYF/aZQaGhlYQAAAcwAAAAgAAAAJAdxBTBobXR4AAACYAAABKIAAAj0wQRTzWxvY2EAACIIAAAEZwAABHxHMIAQbWF4cAAAAewAAAAgAAAAIARXAs1uYW1lAACSvA...2hawUjGKWSTHlyN3B4j2cWs3I2964qIdNK7Bn7l3NIq2gNwdKsrkImONznSahSZTpEh+owvcW+7Mf+HMCBHCTUSS3UXS/oRb2kl/WKXkVU0IxWdKQr3VmSlVmNtdmIzdiSffjdhinO1apRR/hEi8+3rumZFRzp+eEo1XnM/Kz/ABXXNDcAeAGFUUV3wzAM/it6vowXOA1cj5nxrueojZPWynPUDv58uWO4iT+Q7pBghoLQo1A79g2VrMbK6B75jAN47FBDPU56EMfDZhxDGsfrCrqh3VC5SLURRZY7HQrWYVteKlodpgoio9vOkq8JXPbzETifDPx3LGpP54wWehazx17QCjjf5O3v49DkAG/Yfph1UIbYOhpv69k5oy1XL8G1cpkent9bGPPae7sJ96Ojb5sfFwJm1MFQTnePAla5K8HVgPDWBG5+vRbd2fwJg7xahhNv34+/Lb05R9MPTH3KQBiu2ZYkY43dmoA9tEiqcfHN+Gj2VzMA6Y+oeQ==' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'font-src' was not explicitly set, so 'default-src' is used as a fallback.
password:1 Refused to apply style from 'http://127.0.0.1:8080/users/password/edit?reset_password_token=f5d7HAJzHr9H9Y2FeXDe' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
password:1 Refused to apply style from 'http://127.0.0.1:8080/users/password/edit?reset_password_token=ddakboEDSrmuDD7x89WM' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
password:1 Refused to execute script from 'http://127.0.0.1:8080/users/password/edit?reset_password_token=EpcdmHy2ZpwoZ8dPBM5m' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.
password:1 Refused to apply style from 'http://127.0.0.1:8080/users/password/edit?reset_password_token=LPU1u168VBn2zgvo3x-h' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
password:1 Refused to execute script from 'http://127.0.0.1:8080/users/password/edit?reset_password_token=YnvtsaFsWta_8SfBpg5U' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.
password:1 Refused to execute script from 'http://127.0.0.1:8080/users/password/edit?reset_password_token=NxtjP2MX13M54nZSTLfJ' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.
Under "issues" I have:
Content Security Policy of your site blocks some resources
Some resources are blocked because their origin is not listed in your site's Content Security Policy (CSP). Your site's CSP is allowlist-based, so resources must be listed in the allowlist in order to be accessed.
A site's Content Security Policy is set either as via an HTTP header (recommended), or via a meta HTML tag.
To fix this issue do one of the following:
(Recommended) If you're using an allowlist for 'script-src', consider switching from an allowlist CSP to a strict CSP, because strict CSPs are more robust against XSS . See how to set a strict CSP .
Or carefully check that all of the blocked resources are trustworthy; if they are, include their sources in the CSP of your site. ⚠️Never add a source you don't trust to your site's CSP. If you don't trust the source, consider hosting resources on your own site instead.
1 directive
Resource Status Directive Source Location
data blocked font-src edit:166
When I check systemctl status nginx I get:
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: disabled)
Active: active (running) since Sun 2023-01-08 06:54:59 CST; 1h 11min ago
Process: 408 ExecStart=/usr/bin/nginx -g pid /run/nginx.pid; error_log stderr; (code=exited, status=0/SUCCESS)
Main PID: 432 (nginx)
Tasks: 2 (limit: 18846)
Memory: 5.8M
CPU: 15ms
CGroup: /system.slice/nginx.service
├─432 "nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;"
└─433 "nginx: worker process"
Jan 08 06:54:59 Latitude7420 systemd[1]: Starting A high performance web server and a reverse proxy server...
Jan 08 06:54:59 Latitude7420 nginx[408]: 2023/01/08 06:54:59 [warn] 408#408: could not build optimal types_hash, you should increase either types_hash_max_size: 1024 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size
Jan 08 06:54:59 Latitude7420 systemd[1]: Started A high performance web server and a reverse proxy server.
Jan 08 06:59:38 Latitude7420 nginx[433]: 2023/01/08 06:59:38 [error] 433#433: *1 open() "/usr/share/nginx/html/favicon.ico" failed (2: No such file or directory), client: 127.0.0.1, server: localhost, request: "GET /favicon.ico HTTP/1.1">
Jan 08 08:03:23 Latitude7420 nginx[433]: 2023/01/08 08:03:23 [error] 433#433: *2 open() "/usr/share/nginx/html/favicon.ico" failed (2: No such file or directory), client: 127.0.0.1, server: localhost, request: "GET /favicon.ico HTTP/1.1">
The solution was to add the sample nginx.conf from the arch install guide of nginx (section 3.1), overriding the default conf file.
https://wiki.archlinux.org/title/Nginx#Configuration
nginx.conf :
user http;
worker_processes auto;
worker_cpu_affinity auto;
events {
multi_accept on;
worker_connections 1024;
}
http {
charset utf-8;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
log_not_found off;
types_hash_max_size 4096;
client_max_body_size 16M;
# MIME
include mime.types;
default_type application/octet-stream;
# logging
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log warn;
# load configs
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
Related
There seems to be quite a bit floating around the internet about problems such as this, but nothing I have found and tried quite pertains to my particular issue.
I had a functional Plumber api working in Nginx on Digital Ocean, alas when I installed php 8.0.2 and upgraded Ubuntu to 22.04 (and overwrote my conf files then reconfigured them!), it ceased to work. I can see that my R pid is listening to port 3000, and myApi-plumber.service is also directed at port 3000, yet when I test http://127.0.0.1:3000 as root user in console it returns a 404 error instead of an expected 405 (I have provided all info below).
I have not altered any settings in my plumber.R file since it was functional, and it still works perfectly on my local machine, which leads me to suspect it's a server configuration.
I would think I've likely done something incorrectly since, but I've spent days on this and cannot conceive of what it might be. I have adhered to consistent trailing slashes, restarted nginx and rebooted the droplet. I have since spun up new droplets and reinstalled everything from scratch too, but nothing seems to be working. My firewall is also configured as it should be.
Here are my settings:
Nginx version 1.18.0
/etc/nginx/sites-available/default
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
index index.php index.html;
server_name _;
location / {
try_files $uri $uri/ =404;
}
location /myApi/ {
proxy_pass http://127.0.0.1:3000/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
}'
curl -i http://127.0.0.1:3000
(Here I would expect a '405 - Method not allowed' for a POST API with no JSON content being passed to it)
HTTP/1.1 404 Not Found
Date: Fri, 27 Jan 2023 13:11:52 GMT
Access-Control-Allow-Origin: *
Content-Type: application/json
Content-Length: 36
Webpage form POST request
(Here I would expect a JSON object to get passed to the plumber API and run through an R script which compiles a file from server-side files and becomes available as a link on the page.)
function foo(myCallback) {
$.ajax({
type: "POST",
url: "http://XX.XX.XX.XX/myAPI/",
data: myAPIString,
dataType: "json",
success: myCallback,
})
Returns a 404 xhr error in the network tab of the console in the browser.
sudo lsof -i -P -n | grep LISTEN
R 717 root 15u IPv4 XXXXX 0t0 TCP 127.0.0.1:3000
plumber-API.service - Plumber API
Loaded: loaded (/etc/systemd/system/plumber-API.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2023-01-27 10:40:03 UTC; 2h 45min ago
Main PID: 717 (R)
Tasks: 4 (limit: 1131)
Memory: 210.8M
CGroup: /system.slice/plumber-myTree.service
└─717 /usr/lib/R/bin/exec/R --no-echo --no-restore -e pr~+~<-~+~plumber::pr('/var/plumber/myApi/plumber.R');~+~pr$setDocs(FALSE);~+~~+~pr$run(port=3000)
Jan 27 10:40:03 ShakenPolygamy systemd[1]: Started Plumber API.
Jan 27 10:40:10 ShakenPolygamy Rscript[717]: Loading required package: maps
Jan 27 10:40:13 ShakenPolygamy Rscript[717]: Running plumber API at http://127.0.0.1:3000
Very frustrating indeed. Any help is so much appreciated!
I have an nginx server and get a lot of junk traffic from CN/JP and some UK.
how can i block access to these countries?
i have tried GeoIP and cant get it to work...
Part of file: /etc/nginx/nginx.conf
http {
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
geoip_country /usr/share/GeoIP/GeoIP.dat;
map $geoip_country_code $allowed_country {
default yes;
CN no;
JP no;
}
include /etc/nginx/mime.types;
Part of file: /etc/nginx/conf.d/default.conf
(a location block inside my HTTPS section for testing)
location /geo {
if ($allowed_country = no) {
return 444;
}
}
nginx -t
comes back clean with success
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
/etc/init.d/nginx restart
comes back clean with [OK]
Restarting nginx nginx [OK]
I want CN/JP to get either a 444 no header sent or 403 denied. Something so they get no content access on the site. but other countries get to access.
My logs are just full of access after access from these two countries.
I am trying to convert my apache config to nginx. For apache I have following:
<VirtualHost *:443>
ServerName loc.goout.net
<Location />
ProxyPass http://localhost:8080/ retry=0
ProxyPreserveHost On
</Location>
<Location /i/>
ProxyPass https://dev.goout.net/i/ retry=0
ProxyPreserveHost Off
</Location>
...
Like this, if I fetch:
https://loc.goout.net/i/user/606456_001_min.jpg
It correctly fetches content from:
https://dev.goout.net/i/user/606456_001_min.jpg
So for nginx I am trying this:
server {
listen 443 ssl;
server_name loc.goout.net;
proxy_buffering off;
proxy_ssl_session_reuse off;
proxy_redirect off;
proxy_set_header Host dev.goout.net;
location /i/ {
proxy_pass https://dev.goout.net:443;
}
But when I fetch the content, I will always get 502.
In nginx logs I see following:
[error] 7#7: *5 no live upstreams while connecting to upstream, client: 127.0.0.1, server: loc.goout.net, request: "GET /i/user/606456_001_min.jpg HTTP/1.1", upstream: "https://dev.goout.net/i/user/606456_001_min.jpg", host: "loc.goout.net"
Note the link: https://dev.goout.net/i/user/606456_001_min.jpg
- which works correctly. It seems to me it still doesn't connect with SSL. I also tried to define the upstream section as:
upstream backend {
server dev.goout.net:443;
}
But it had no effect.
Note the server is behind CloudFlare gateway, I hope it is not preventing the correct connection, but I guess that wouldn't work in apache either.
tl;dr: SNI is off by default in nginx, as per http://nginx.org/r/proxy_ssl_server_name, but is required by Cloudflare.
It's generally not the best idea to have home-made proxies on top of Cloudflare — it's supposed to be the other way around.
However, what you're omitting is the actual error message that results from making the request like curl -v localhost:3227/i/user/606456_001_min.jpg — of course it is TLS-related:
2018/07/07 23:18:39 [error] 33345#33345: *3 SSL_do_handshake() failed (SSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure) while SSL handshaking to upstream, client: 127.0.0.1, server: loc.goout.net, request: "GET /i/user/606456_001_min.jpg HTTP/1.1", upstream: "https://[2400:cb00:2048:1::6818:7303]:443/i/user/606456_001_min.jpg", host: "localhost:3227"
This is because nginx is not really intended to be used to steal someone else's sites via proxy_pass, so, some features that Cloudflare does require, are turned off by default in nginx for the general use; specifically, it's the SNI, Server Name Indication extension to TLS, that's making the difference here.
As per http://nginx.org/r/proxy_ssl_server_name, putting an extra proxy_ssl_server_name on; to your exact configuration does fix the issue (I've tested this myself — it works) — note that this requires nginx 1.7.0 or newer.
+ proxy_ssl_server_name on; # SNI is off by default
Additionally, note that you'll also have to ensure that the domain name resolution gets updated during the run-time, as, by default, it only gets resolved when the configuration is loaded or reloaded; you could use the trick of using variables within your http://nginx.org/r/proxy_pass to make it update the resolution of the host as appropriate, but then this also requires you to use the http://nginx.org/r/resolver directive to specify the server to use for DNS resolutions (during the runtime, after loading the configuration), so, your MVP would then be:
location /i/ {
resolver 1dot1dot1dot1.cloudflare-dns.com.;
proxy_ssl_server_name on; # SNI is off by default
proxy_pass https://dev.goout.net:443$request_uri;
}
If you want to specify upstream servers by hostname instead of IP then you must define a resolver directive for Nginx to do DNS look ups.
Is dev.goout.net on a different, remote machine?
Where are your proxy_ssl_certificate and proxy_ssl_certificate_key directives? That connection won't just secure itself.
OS: Ubuntu 14.04
Nginx: nginx version: nginx/1.4.6 (Ubuntu)
For providing Clickjacking based security in the browser side for frames, X-Frame-Options header options can be set in 3 different ways.
DENY
SAMEORIGIN
ALLOW-FROM <uri>
PS: https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet (for compatibility matrix) and https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options (Note: Don't mix Apache with Nginx for configuration part).
I want to enable display of frames / iframes (generated/provided by Log parser plugin) on my Jenkins machine i.e. on Jenkins job's dashboard. For more info you can see some background here: Jenkins Log parser plugin - parsed console log page is not showing Load denied by X-Frame-Options does not permit framing ERR_BLOCKED_BY_RESPONSE
For that, I need to make sure, the following lines is NOT present in my NGINX configuration for jenkins https conf file / or you can commment it out.
add_header X-Frame-Options DENY;
Comment this line and the frames will render fine now in your browser i.e. on job's dashboard but doing this will bring security issues.
To implement the second option is to make sure, you remove/replace the above line OR make sure the following line EXIST in your NGINX config file for Jenkins https conf.
add_header X-Frame-Options SAMEORIGIN;
Now, the 3rd approach takes the word ALLOW-FROM https://_URI_value with / without double quotes starting before ALLOW-FROM and ending after the URL part.
This will tell NGINX to allow rendering of frames where the are coming from the given URI (JENKINS URL in my case), so I tried the following:
#ALLOW-FROM https://my.company.jenkins.com/
#add_header X-Frame-Options ALLOW-FROM https://my.company.jenkins.com/
#add_header X-Frame-Options "ALLOW-FROM https://my.company.jenkins.com/"
If I enable just the first line (as listed above for the 3rd approach) and run sudo service nginx restart; sleep 1; tail -1 /var/log/nginx/error.log, then I'm getting the following output / error.
* Restarting nginx nginx [fail]
2017/08/24 15:27:39 [emerg] 127120#0: unknown directive "ALLOW-FROM" in /etc/nginx/sites-enabled/jenkins_https.conf:23
If I enable either just the 2nd or 3rd line (as listed above for the 3rd approach), then I'm getting the following output / error for both 2nd/3rd lines.
* Restarting nginx nginx [fail]
2017/08/24 15:29:49 [emerg] 127189#0: invalid number of arguments in "add_header" directive in /etc/nginx/sites-enabled/jenkins_https.conf:23
How can I successfully, use the ALLOW-FROM syntax within nginx config file while the restart succeeds without the above failures and it allow frames/iframes rendering coming from a given URI/URL?
PS:
Using add_header X-Frame-Options SAMEORIGIN;, my issue is resolved but I'm mainly looking for why ALLOW-FROM <URI/URL> syntax is not working and giving me the above error messages.
The syntax accepted above doesn't work.
The expected syntax is
add_header X-Frame-Options "allow-from https://my.example.com/";
Tested successfully on versions nginx/1.11.9 and nginx/1.15.9
You've probably already figured this out, but just for posterity: to specify allow-from in add_header, use this syntax:
add_header "allow-from https://my.example.com/";
I have built nginx on a freebsd system with the following configuration parameters:
./configure ... –with-http_dav_module
Now this is my configuration file:
user www www;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
# reserve 1MB under the name 'proxied' to track uploads
upload_progress proxied 1m;
sendfile on;
#tcp_nopush on;
client_max_body_size 500m;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
#upload_store /var/tmp/firmware;
client_body_temp_path /var/tmp/firmware;
server {
server_name localhost;
listen 8080;
auth_basic "Restricted";
auth_basic_user_file /root/.htpasswdfile;
create_full_put_path on;
client_max_body_size 50m;
dav_access user:rw group:r all:r;
dav_methods PUT DELETE MKCOL COPY MOVE;
autoindex on;
root /root;
location / {
}
}
}
Now, the next things I do are check the syntax of the confiuration file by issuing a nginx -t and then do a graceful reload as follows: nginx -s reload.
Now, when I point my web-browser to the nginx-ip-address:8080 i get the list of my files and folders and so on and so forth (I think that is due to the autoindex on feature).
But the problem is that when I try to test the webdav using cadaver as follows:
cadaver http://nginx-ip-address:8080/
It asks me to enter authorization credentials and then after I enter that it gives me the following error:
Could not open Collection: 405 Not Allowed
And the following is the nginx-error-log line which occurs at the same time:
*125 no user/password was provided for basic authentication, client: 172.16.255.1, server: localhost, request: "OPTIONS / HTTP/1.1", host: "172.16.255.129:8080"
The username and pass work just fine wheni try to access it from the web-browser, then what is happening here?
It turns out that the webdav module in-built in nginx is broken and to enable full webdav, we need to add the following external 3rd party module: nginx-dav-ext-module.
Link to its github: https://github.com/arut/nginx-dav-ext-module.git
The configure parameter would now be:
./configure --with-http_dav_module --add-module=/path/to/the/above/module
The built in one just provides the PUT DELETE MKCOL COPY MOVE dav methods.
The nginx-dav-ext-module adds the following additional dav methods: PROPFIND OPTIONS
You will also need to edit the configuration file to add the following line:
dav_ext_methods PROPFIND OPTIONS;
After doing so check if the syntax of the conf file is intact by issuing: nginx -t
and then soft reload (gracefully) nginx: nginx -s reload
And Voila! you should now be able to use cadaver or any other dav client program to get into the directories.
I cannot believe that I solved this, it drove me nuts for a while!