feat: protect HTTP API using access token

[bajtos]

Add a new configuration option to enable access-token-based authorization for all incoming HTTP requests.

Example use:

❯ go run ./cmd/lassie -- daemon --access-token supersecret
Lassie daemon listening on address 127.0.0.1:56251
Hit CTRL-C to stop the daemon

Unauthorized request:

❯ curl -i 'http://127.0.0.1:56251/debug/pprof/cmdline'
HTTP/1.1 401 Unauthorized
Date: Fri, 23 Jun 2023 09:13:57 GMT
Content-Length: 13
Content-Type: text/plain; charset=utf-8

Unauthorized

Authorized request:

❯ curl -i 'http://127.0.0.1:56251/debug/pprof/cmdline' -H 'Authorization: Bearer supersecret'
HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Fri, 23 Jun 2023 09:13:30 GMT
Content-Length: 120

Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.

[codecov-commenter]

Codecov Report

Merging #328 (f0441a6) into main (da0ac6b) will decrease coverage by 0.06%.
The diff coverage is 29.41%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #328      +/-   ##
==========================================
- Coverage   75.65%   75.60%   -0.06%     
==========================================
  Files          70       70              
  Lines        6310     6325      +15     
==========================================
+ Hits         4774     4782       +8     
- Misses       1262     1271       +9     
+ Partials      274      272       -2     

Impacted Files	Coverage Δ
pkg/server/http/server.go	68.85% <7.69%> (-16.57%)	⬇️
cmd/lassie/daemon.go	52.43% <100.00%> (+1.18%)	⬆️

... and 5 files with indirect coverage changes

[bajtos]

Context:

We are running Lassie Daemon in Filecoin Station on desktop computers (see space-meridian/roadmap#19). We don't want Lassie's HTTP server to be open to other processes running on the computer.

In this PR, I am adding an option allowing users to opt into authorisation.

@hannahhoward @rvagg @kylehuntsman
Could you please advise me on how to write tests for this change? I was looking around the codebase but could not find any existing tests making HTTP requests to Lassie Daemon.

cc @juliangruber

[kylehuntsman]

@hannahhoward @rvagg @kylehuntsman Could you please advise me on how to write tests for this change? I was looking around the codebase but could not find any existing tests making HTTP requests to Lassie Daemon.

Hi @bajtos! You can add a test to cmd/lassie/daemon_test.go to make sure the HttpServerConfig is capturing the access-token flag appropriately when provided, as well as updating the default args test to ensure the config has an empty string value when not provided.

As for a test that calls the daemon to double check functionality, I'm currently working on issue #261 to add these. If you want to add the above tests to ensure the configuration has the correct value given the CLI flags used, I'll make sure to check it in my HTTP API tests.

[bajtos]

@hannahhoward @rvagg @kylehuntsman Could you please advise me on how to write tests for this change? I was looking around the codebase but could not find any existing tests making HTTP requests to Lassie Daemon.

Hi @bajtos! You can add a test to cmd/lassie/daemon_test.go to make sure the HttpServerConfig is capturing the access-token flag appropriately when provided, as well as updating the default args test to ensure the config has an empty string value when not provided.

As for a test that calls the daemon to double check functionality, I'm currently working on issue #261 to add these. If you want to add the above tests to ensure the configuration has the correct value given the CLI flags used, I'll make sure to check it in my HTTP API tests.

Thank you for the pointers, @kylehuntsman!

I would like to test that the HTTP handler checks the Authorization header correctly. The file pkg/internal/itest/http_fetch_test.go seems to be a good place to add my tests and I did so in 94caaee.

I am going to add some tests for HttpServerConfig as you suggested.

[bajtos]

I added a new test-case config - expectUnauthorized.

Alternatively, we can also change the type of expectFail to accept the expected HTTP status code. It would be cleaner (IMO), but it would also require more changes in the existing test cases. Let me know which option you prefer!

[bajtos]

Code coverage looks much better now 💪🏻

This pull request is ready for review and landing, as far as I am concerned.

Please let me know if there is anything to improve.

[hannahhoward]

I feel good about this and thanks for adding the test.