Trying to use filebase as bucket results in this error, using it with other programs I get no such error(s3fs)

monitor error: cannot lookup bucket region: InvalidAccessKeyId: The AWS Access Key Id you provided does not exist in our records.

My litestream.yml

access-key-id: ${LITESTREAM_ACCESS_KEY_ID}
secret-access-key: ${LITESTREAM_SECRET_ACCESS_KEY}
dbs:
  - path: ${DB_PATH}
    replicas:
      - url: s3://mypaste-new.filebase.com
        sync-interval: ${DB_SYNC_INTERVAL}

If logpaste expects litestream to be replicating data, and it's not, it should fail hard so that users stop uploading logs that will never be replicated.

Maybe the Go app can have a periodic check similar to what's mentioned in this Kubernetes example and panic if litestream is no longer replicating.

Hello!

I recently discovered logpaste, and it's a pleasure to use so far. Easy to set up, self host, and use! However, the text isn't always the easiest to read because of the white background on the home page. May can I ask, would it be possible to add dark mode, which can be enabled using a docker environment value?

Without this, clients can upload arbitrarily-large pastes. Such pastes will be caught later by validatePaste, but in the interim, the entire paste is held in memory, so a malicious client could trivially pipe /dev/urandom into curl and eventually cause your server to OOM.

I successfully deployed logpaste to Google Cloud on Google Cloud Run and Google Cloud Storage

I had the change the code in the following way:

• Remove these 3 lines from litestream.yml since litestream is able to pick up credentials from the environment directly
• Update the logic to decide to use litestream

Then, I built with Cloud Build gcloud builds submit . --tag gcr.io/<PROJECT>/logpaste:latest

And deployed to Cloud Run: gcloud beta run deploy logpaste --image gcr.io/<PROJECT>/logpaste:latest --set-env-vars DB_REPLICA_URL=gcs://<BUCKET>/db --execution-environment gen2 --no-cpu-throttling

I can try to send a PR: we can enable litestream if DB_REPLICA_URL is set, but I'm not sure about the best way handle the translation of envvars to litestream.yml

One small thing to mention: When using curl to upload text, the output URL defaults to http. Most webservers should already redirect from port 80 to port 443, but I think it would be nice to add an option to enable https everywhere instead of the http output.

Originally posted by @KoxSosen in https://github.com/mtlynch/logpaste/issues/121#issuecomment-963351527

We're using the third-party gorilla mux package, but I don't think we really need it. We can probably get away with the standard library implementation.

Thanks for making this great doc -- I just went through it and wanted to suggest some edits here:

1/ You don't need docker installed if you are just deploying following these instructions -- I say this because I deployed WITHOUT having docker installed. 2/ When I ran fly init "${APP_NAME}" --nowrite - the fly cli said Error We need your payment information to continue! Add a credit card or buy credit: https://fly.io/organizations/personal

Works fine in a local container, but fails for some reason on Google Cloud Run

+ litestream restore -v /app/data/store.db 
2021/02/22 15:11:08 /app/data/store.db(s3): starting restore: generation 68ce1ab8c28d0111, index 00000000-00000000 
2021/02/22 15:11:08 /app/data/store.db(s3): restoring snapshot 68ce1ab8c28d0111/00000000 to /app/data/store.db.tmp 
cannot restore wal: disk I/O error: invalid argument 

Hello, Thank you for making this.

I was curious if you would be able to add a customizable link length? Right now it's hard coded for 8 characters I believe, but would appreciate being able to set a custom length via a docker-compose variable

The PUT handler doesn't match the semantics of the traditional PUT verb.

I chose PUT because I wanted a way for the client to signal to the server that it wanted back the URL instead of a JSON object.

Revisiting the decision, I should have just used an Accept header in the request to let the client specify whether they want plaintext (default) or JSON. So we should combine the handlers for PUT and POST into a single handler that chooses output based on the content type and accept headers.

See similar work in PicoShare: https://github.com/mtlynch/picoshare/pull/318/files