Should plugins store data to AssetPath()?

I’m finally attacking a oauth plugin again. Gonna make it work simpler this time. One aspect that I would like to simplify is supplying a secret with which to encrypt cookies. It should be some random data, possibly supplied by the user, but I feel bad requiring them to know about it if they don’t want to.

My solution:

  • Allow them to put it in the caddyfile:
oauth ... {
   cookie_secret: abclskdjlasdjldjlkasd
}
  • But if not given, generate one for them. The only catch is, the generated one needs to persist across caddy runs. My thought is to save it in {caddy.AssetPath()}/oauth/{servername}.key

I guess my questions are multiple:

  1. Do any other plugins write to the file system like this?
  2. I remember something about a file abstraction layer, but only found AssetPath() in the code. Will writing here hurt ability to abstract it later?
  3. Is there an easy to get at filename-safe version of the hostname for the server to use as a filename?
1 Like

I guess one problem with this approach is that if they change the servername slightly, the old secret will not be found and all existing cookies will be invalid. I don’t like that approach so much.

I could do a single global secret for any servers not explicitly giving one, and that simplifies it more, but also decreases the security slightly. Thoughts?

Yay an oauth plugin! \o/

You may definitely use $CADDYPATH to store things you need to. Just mention it in the documentation. (I should do better at this too.)

Do any other plugins write to the file system like this?

Yes, the tls plugin does this. I don’t know of any 3rd party plugins that do this, though.

I remember something about a file abstraction layer, but only found AssetPath() in the code. Will writing here hurt ability to abstract it later?

There is a TLS storage plugin type (sorta, need to finish it) but nothing for abstracting the file system entirely.

Is there an easy to get at filename-safe version of the hostname for the server to use as a filename?

Probably your best bet is to lowercase it (case-insensitivity) and strip any special characters, although I think hostnames are already fairly well restricted. Remember, though, that in the HTTP Caddyfile, site addresses can have path, scheme, and ports; if you only need hostname then it definitely is easier and you can just use the host.

Will this happen often, do you think?

What is the threat model? Specifically, how are secrets leaked? Is there a situation where one key will be leaked but not another? (The TLS plugin does use a different secret key per site, and it does store them by hostname, FWIW.)

I guess my main concern is that using a different key for each server name introduces a few issues, namely that cookies would not be compatible between servers that share config like

localhost:8888 foo.com { }

or

http://foo.com changing to https://foo.com would also invalidate all cookies. Maybe thats a good thing?

I guess I don’t have a good threat model where one would be compromised but not the other. If an attacker has file system access to read the key, they have them all anyway. If they divine one as a mitm they would have them for all servers on the machine, but that is a much smaller risk I think, unless there is a vulnerability in the crypto, in which case we are likely broken either way.

Gonna implement a single shared auto-key for now. If you want unique secrets per server you can provide it.

1 Like

Go ahead and start with that, then. :slight_smile: I bet it’ll be fine especially for now.

Also: have you added your plugins to the new website yet?