static-file-server
static-file-server copied to clipboard
.htaccess
Can we get options for basic authentication?
I did a rough outline of what the feature might look like in the feature/basic_auth branch. Before I bring it into master, I want to clean-up the code and add some tests, but the functionality will be backwards compatible. This provides two options for basic authentication:
-
'quick and dirty' (not recommended for extended deployment) export FAST_AUTH=user:password static-file-server
-
'secure' export CREDENTIALS=creds.json static-file-server auth add user # either add password as second argument or respond to password request. static-file-server
Let me know if this meets your requirements.
That sounds awesome!
It will take me a few days (maybe a week or two) to get some free time to refactor/clean-up the code. I want to get a few unit tests dropped in, as well. In the meantime, try it out and let me know if you find any bugs or want any changes. I've attached a 64-bit Linux binary for trying out to save time building.
No rush, I was able to get nginx setup for my current needs
how do you configure the directory with the file you uploaded?
In the days of Apache web server any folder containing a .htaccess
file would require HTTP basic authentication.
CLI tools for managing .htaccess
files are plenty (e.g. http://manpages.ubuntu.com/manpages/bionic/man1/htpasswd.1.html) and this project should not bother with managing that kind of configuration.
I suggest an env flag HTACCESS=true
that makes the server check for an .htaccess
file in the folder of requested resource and all parent folders. The first file found is the one used to check HTTP headers for user authentication and with a mismatch, return 401 Unauthorized as per https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
One can then have .htaccess
files in the /web
mount and manage them with existing tools.
Obviously, any request for this file should return at least a 404 😄 .
This issue has been the only one I haven't felt like I'm entirely happy with the solution. I would like to keep it dead simple and standalone and not inherit another server's legacy interfaces, but I haven't found an implementation that I want to perpetually support. Besides simplicity (like moving all authentication into the single YAML file), I prefer not to create the opening for 'I can .... with .htaccess files and that doesn't work with static-file-server'. If SFS supports any feature using a .htaccess, it will be expected that it supports all of them perpetually.
I'm definitely open to ideas and arguments on all sides of this feature.
Hey,
I love the idea of the system being as simple as possible without bells and whistles and redirects. As such, the credentials being stored as close to the yml as possible is great. My concern is that, for the sake of customizability and flexibility, the server should still have the option of anonymous access if one so desires.
A few notes taken from the code (with the prefix that I am not versed in GO):
-
The credentials would be stored in a JSON This is great, because it allows offline or even granular or automatic administration of users
-
I'm a bit sketchy on the usefulness of FAST AUTH, maybe because the scope of the feature is rather vague
-
Immediate suggestion would be to add a whitelist feature for IP addresses as an alternative for credentials or anonymous access
-
In the interest of keeping things as simple as possible, I don't see any implementation change that would work better than what you have already proposed
Thanks
- One of the common use cases involves transferring a file between machines. For example, if I have a video file that is too large for email, or perhaps I'm on a private network (company network, or a coffee shop), a solution easier than providing SSH access, or creating a temporary shared folder over Samba/Windows/NFS/etc shares; once can start the server with simple, plain-text in the command-line username and password (FAST_AUTH) and leave the connection live for no longer than it takes to download the file with a web browser, wget or curl. Using FAST_AUTH, the server could be set up in a single command, but it comes at the security costs of: credentials are plain text on the command-line, stored in the command-line history, discover-able with server access and, most likely, isn't used a TLS certificate, so the credentials can be determined with a packet sniffer. It is a solution that replaces some security complexity with basic security that is only useful due to the ephemeral state of the temporary file server. I'm actually not a huge fan of the FAST_AUTH solution, but I can understand why people would want it. I'm still not certain I want to add FAST_AUTH.
- I like the IP whitelist option. I'm going to give it some thought. That may actually be better than the FAST_AUTH solution, though I still have some concern over spoofiing.
Thanks for the feedback! I'll probably add this in over the next few weeks. In the meantime, if you have any other thoughts, feel free to drop them here.
Hi @halverneus, I love the little server so far, and it's way easier to get going than nginx for me, but I'm having a little trouble with the feature/basic_auth installation. Go complains it can't find the external packages, and I don't think I know enough to fix:
serve.go:17:2: cannot find package "golang.org/x/crypto/scrypt" in any of:
/usr/local/go/src/golang.org/x/crypto/scrypt (from $GOROOT)
/go/src/golang.org/x/crypto/scrypt (from $GOPATH)
It sounds like you're in the middle of implementing the auth feature in a more fleshed out way, but I don't know if you have any quick fixes you can suggest since I really just need a modicum of security for my internal site. Thanks!
Sounds like you are compiling it yourself. In that case, just run the following:
go get golang.org/x/crypto/scrypt
With Go, if you are having any issues with missing packages, just throw a "go get" in front of the package it can't find. With the latest Go Modules features (used in the latest releases, but not back when I prototyped out this feature), those dependencies are automatically pulled.
I'm actually trying to compile with the Dockerfile. I added RUN go get golang.org/x/crypto/scrypt
and RUN go get github.com/howeyc/gopass
after WORKDIR /
and got the docker to run, but it will just 404 when I try to connect, and fail entirely if I try to use -e FAST_AUTH=username:password
during docker run.
Any thoughts?
Ah! Considering it was just a quick prototype, I'll wager that I never set it up to compile with the Dockerfile. My first thought is that the forth comment in this issue has a binary for Linux 64-bit that you can use (even if you are not on Linux, with Docker you can do a quick Dockerfile that copies the binary into the container (example here )). If that doesn't work as expected, give me a few specifics (docker command, file structure (ideally a 1 file "hello" example with a screenshot of ownership/permissions (as applicable), application output and request output (curl?)).
As an aside, I don't plan to support the code and implementation in this branch, but I would like input on your subjective experience with it, as well as any suggestions. Once code touches the master branch, I'm supporting it "forever" (hence my caution with this feature).
Hah forever is a long time! I'd be happy to help, this is a pretty low key project for me as well and I mostly interested so I don't have to put the effort into nginx or LAMP. Still getting a 404 from the binary, but let me run through my process and make sure it's not user error:
- Download and decompress
static-file-server.tar.gz
, replace line in Dockerfile withCOPY static-file-server /serve
-
docker build -t auth_test .
-
docker run -d --name static_auth_test -v /home/user/static_auth:/content/html -p 8080:8080 auth_test:latest
- Boots fine, runs fine. Changed dir permissions to 777 for kicks so hello.txt is:
-rwxrwxrwx 1 ionadmin ionadmin 0 May 3 16:57 hello.txt
curl -i 10.0.0.0:8080
HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Fri, 03 May 2019 20:59:48 GMT
Content-Length: 19
404 page not found
The alternative to docker would be what, installing go and running the application that way? I think it'd be nice to keep inside a container but I'd be open to alternatives.
Try this:
docker run -d --name static_auth_test -v /home/user/static_auth:/web -p 8080:8080 auth_test:latest
or
docker run -d --name static_auth_test -e FOLDER=/content/html -v /home/user/static_auth:/content/html -p 8080:8080 auth_test:latest
Some progress! Curl now shows:
curl -i 10.0.0.0:8080
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Last-Modified: Fri, 03 May 2019 20:57:06 GMT
Date: Fri, 03 May 2019 21:40:38 GMT
Content-Length: 293
<pre>
<a href="Dockerfile">Dockerfile</a>
<a href="hello.txt">hello.txt</a>
<a href="static-file-server">static-file-server</a>
<a href="static-file-server-feature-basic_auth/">static-file-server-feature-basic_auth/</a>
<a href="static-file-server.tar.gz">static-file-server.tar.gz</a>
</pre>
It seems this works for both commands. However, if I try to connect from another machine I get nothing. I'm guessing that's because no auth is set up yet?
I'm curious about your IP address of 10.0.0.0... does it work remotely if you use the results of your "ip addr" on the server machine?
Yeah, it does. That's not my "real" ip, just minor censorship! Again though, I was able to connect successfully with the master branch of the repo and have everything show up correctly, from both the server machine and a remote machine.
So a quick update, I'm able to use curl
to access the files from a remote machine, but that's about it. Can't connect through a browser, can't use wget
, and I can't load it into the application I was hoping to use to serve these files anyways (igv). Thoughts on that?
Does it work with "wget" if you pass the "--auth-no-challenge" flag?
Yeah that does seem to do it! Any solution for web browsers or other apps?
Yeah, that is because I didn't finish implementing it. It was just intended to evaluate workflow. I still need to do some research to work with auth challenging; just never enough time. I'm afraid that is where this branch is stuck until I implement it for production. It is on my short list, though, once I get some free time.
Sounds great. Glad I could help somewhat!
Ist there any progress here? Need that feature :(
I'll move it up the priority list and revisit it in the near future.
I would like to have this feature too :)
Yes please