Multiple feature requests about ots HOT 3 CLOSED

First of all: Please - and I think I speak for every OSS project out there - create one issue for one request. This is just barely actable anymore and cannot be properly worked on. (As you seem to come from a corporate environment, like you would create one Jira ticket for one request.)

Using environment variables for configuration does not provide a secure way to manage Redis credentials.
I propose implementing a configuration file to prevent credentials from being accessible through the environment.

Please elaborate. Environment variables are an issue for systems with shared access, files are too. Environment variables will fall when the system is compromized, files will too. Environment variables can be injected by a wrapping process, files cannot.

So how would the security increase by writing the redis credentials into a file on disk in opposite to taking environment variables from a security store?

The expiry settings on the web interface should be clearer.

#153

The app should not be able to change the web interface at runtime.

OTS contains compiled-in assets. They cannot change during runtime. There is barely a difference between statically compiling the frontend and baking it into the binary and statically compiling the frontend and hosting it using the nginx. The second variant can be changed easier.

Aside if you really want to go that way: make generate, edit the index.html in the frontend directory, let nginx serve it at ots.yourdomain.com and pass through the /api to the Go application: You're done. I don't see the benefit as you will loose the customization feature but you can do that.

Uploading needs an authorization system to control uploads.

#92

This can be done through the isWritable endpoint. It can't be called, the frontend will not display the creation form. It can be called, the frontend will display the creation form. Limit it on the proxy you put in front of the instance by applying access-control to /api/isWritable and /api/create to only be useable by employees and nobody else can create secrets.

from ots.

First of all: Please - and I think I speak for every OSS project out there - create one issue for one request. This is just barely actable anymore and cannot be properly worked on. (As you seem to come from a corporate environment, like you would create one Jira ticket for one request.)

I intended for this to be more of a discussion then a full on feature request. It doesn't have the technical dept for a feature request imo. I see that it can be cumbersome to manage. I will split this into distinct issues.

from ots.

To add to that. I wanted to know whether you want those features in OTS at all, before opening issues. Discussion are not enabled on the repo, so I opted for a single issue instead.

from ots.