Limit who can write snips

[rugwirobaker]

What is the feature or enhancement?

If I'm self-hosting my own instance I'd like to somehow limit who can write snips to it.

[robherley]

Love the idea, want to toss around some ways we can achieve this:

1. Do we want this to be a configuration file (think like an authorized_keys file) where the allowed fingerprints are stored on disk?
2. A new attribute in the DB (e.g. public_keys table). But how would this be controlled by the admin? (e.g. command line args to the image, manually editing sqlite)

I'm leaning more towards (1) since having it in the DB may be awkward to setup. The amount of configuration options for snips are getting large, could warrant some kind of toml/yaml support for config too.

[xabru]

Using a configuration file in TOML or YAML format is a great idea and would be the next step to consider. Additionally, including the corresponding binaries in the releases section would be beneficial. For instance, the Filebrowser project serves as an excellent source of inspiration.

[tigh-latte]

I like the first idea too, as it can leverage the current authorized_keys file on my setup without any duplication of config.

[robherley]

Here's a PR for the authorized_keys approach, I think that makes the most sense given the nature of the program 😄

• #47

You should totally be able to use ~/.ssh/authorized_keys too, users can configure it how they want, I left some info in the docs (like getting other user's public keys from https://github.com/<username>.keys)

Lemme know what y'all think 👍

[robherley]

@xabru

Using a configuration file in TOML or YAML format is a great idea and would be the next step to consider

Totally agree! The list of environment variables is getting quite long, I do like the idea of a snips config file to make it a bit easier. May roll with YAML because I'm personally not the biggest fan of TOML 😅 I'll take another look at viper but might be super overkill for this use case.

including the corresponding binaries in the releases section would be beneficial

I'm 50/50 on adding the binaries. In a perfect world, they'd be statically linked and set to go. But since we need libtensorflow dynamically linked for guessing the language, it can be a bit confusing with just the binary release, which is why I opted to use container images. I do have some (possibly bad) ideas to get around that, may open a discussion it.

[robherley]

With #47 this is now possible!