search

sandstorm-io / sandstorm

Sandstorm is a self-hostable web productivity suite. It's implemented as a security-hardened web app package manager.
https://sandstorm.io
Other
6.68k stars 709 forks source link

Document remaining sandstorm.conf options #3339

Open ocdtrekkie opened 4 years ago

ocdtrekkie commented 4 years ago

This is a self-note, mostly because I need to figure out what these do/did in some cases. But the docs list deprecated settings, and people may want to know, if they have a deprecated setting, why it existed and if they should remove it. If it still functions in any way, it's important to note that.

Pulling from https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/config.c%2B%2B

zenhack commented 4 years ago

I don't think we should bother documenting EXPERIMENTAL_GATEWAY; all it does now is print a warning if you set it to false; having it in the docs seems like clutter given there's no reason for anyone to ever set it. Tbh, we could probably just remove it; it's been years since it did anything.

ocdtrekkie commented 4 years ago

@zenhack Indeed, but isn't that also true of other "historic" config options? I guess I imagined "historic" options were nonfunctional, but it appears WILDCARD_PARENT_URL is used to build WILDCARD_HOST if it's set. I'm not sure if MAIL_URL still makes it in there anywhere.

I feel we should document them if the code reads for them. But I'd like to get to the "deleting the code reading them" area where possible. I imagine EXPERIMENTAL_GATEWAY becoming an "unrecognized option" is perfectly fine, provided it only creates a log warning on startup (as of #3338).

zenhack commented 4 years ago

re: PRIVATE_KEY_PASSWORD, it looks like kj's TLS wrappers can use this to use a private key that's encrypted, and this just passes the value through to that. Which is super weird since afaik there's historically been no way to have sandstorm end up managing a cert with a password on it, though you could do it now with the manual upload option I guess... if you had a reason to.

@kentonv, was this used for something historically?

Re: TERMS_PAGE_PUBLIC_ID, it doesn't look like the personalization settings have an equivalent. It looks like this is basically a hack to let you use static publishing to handle /terms and /privacy urls; the value is the 'public id' of the grain that should handle these. I assume this is not documented because it's an awful hack that was put in place for oasis, and was never meant to be a general solution?

zenhack commented 4 years ago

Yeah, that was the distinction I had in mind; the option actually just doesn't do anything (other than log a warning).

Glancing at the code it looks like MAIL_URL does actually do something still. Maybe we could give it a similar treatment to what you proposed for HIDE_TROUBLESHOOTING.

ocdtrekkie commented 4 years ago

Regarding the Terms page feature, I assume it's somewhat similar to the splash page setting in how it works then? That one we expose to users, with the warning that it's experimental.

zenhack commented 4 years ago

Yeah, it looks like it functions a similar way.

The personalization panel let's you specify URLS for these things, but doesn't have the static publishing thing. The comments in the code suggest this was basically added so we didn't have to change the URLs on oasis when the gateway was written, since these were /terms and /privacy off of the main domain. Originally, these were handled separately by an nginx instance that was in front of sandstorm, but with the gateway handling traffic directly that was no longer an option.

I don't think we should support this. I'd like to just remove it, and it seems like with oasis shut off we could. @kentonv, how to you feel about that?

ocdtrekkie commented 4 years ago

If we remove it, we should probably have an idea what the "correct" way to do this is without the care about changing Oasis' existing URLs? Presumably something like being able to set a static publishing endpoint to terms.example.com?

zenhack commented 4 years ago

I'm not sure I follow. Now that Oasis doesn't exist, what functionality needs replacing?

ocdtrekkie commented 4 years ago

Presume someone wants to specify their terms and privacy policy, and that they should be on the same domain as their Sandstorm server. It would seem like static publishing to a subdomain would be the way to go, but presumably to a friendly named one.

zenhack commented 4 years ago

I think at some point we should have a way to request static publishing at a human-friendly subdomain in general. Once that's in place, then just pointing to such a grain seems reasonable to me.

-Ian

Quoting Jacob Weisz (2020-05-14 13:32:37)

Presume someone wants to specify their terms and privacy policy, and that they should be on the same domain as their Sandstorm server. It would seem like static publishing to a subdomain would be the way to go, but presumably to a friendly named one.

-- You are receiving this because you were mentioned. Reply to this email directly, [1]view it on GitHub, or [2]unsubscribe.

Verweise

  1. https://github.com/sandstorm-io/sandstorm/issues/3339#issuecomment-628781633
  2. https://github.com/notifications/unsubscribe-auth/AAGXYPUCXMBLUA7ART3IFV3RRQTLLANCNFSM4NAHXHLQ
ocdtrekkie commented 4 years ago

Okay, I agree that's the right approach. I just figure before removing a hack we should at minimum be agreed on what the right way to do it is. And given we're talking on IRC about a large Sandstorm instance today, I imagine even without Oasis, having a terms and privacy link is a need to be prepared for.