Admins may configure instances with their Stripe platform account credentials

[bhaibel]

As an instance admin I would like to connect my instance to Stripe So that I and my creators can get paid

Given I am an instance admin And I have a Platform account with Stripe When I configure my instance with my Stripe credentials My instance should be configured to accept payments via the Stripe platform API

When I visualize this I see a CLI script -- maybe something like a bin/configure stripe command that's a thin wrapper around heroku set. The thing I don't like about that is that that would require admins check out a copy of the Nourish repo to their home boxes. Am I overthinking this? Is there some other pattern we could use to distribute a CLI?

[zspencer]

I would probably prefer we try to keep the configured via ENV to a minimum, so that moving between servers where you don't have access to that data is kept to a minimum. Wordpress, for instance, stores 99% of it's configuration in the database. I don't think that's terribly unreasonable.

[bhaibel]

That makes sense. I'm torn. Wordpress is also notorious for security vulns, and the sheer level of permissions available to folks who can escalate to admin access seems like it's part of that. I'm worried about that fact in the context of dealing with financial data credentials -- can you try to assuage those worries?

[zspencer]

If you want to write a feature test that demonstrates non instance admins cannot access stripe platform configuration page I think that’s a good test to write explicitely

Sent from my iPhone

On Dec 29, 2017, at 9:43 AM, Betsy Haibel notifications@github.com wrote:

That makes sense. I'm torn. Wordpress is also notorious for security vulns, and the sheer level of permissions available to folks who can escalate to admin access seems like it's part of that. I'm worried about that fact in the context of dealing with financial data credentials -- can you try to assuage those worries?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[bhaibel]

Okay, so, I guess part of it is -- if we're making "make a new admin" a CLI-only thing, why are we treating Stripe credentials as something that needs less security than that? That's pretty weird to me. I'd like both UX and code consistency in how we approach DANGERZONE features like this, so I'd rather we make BOTH Stripe creds AND admin promotion web-accessible features or NEITHER.

(I'm also not in love with prove-a-negative tests, but they might be the best we can do.)

[zspencer]

I think there's a few things at play here. One is I was conflating this with project creators connecting their stripe credentials and the platform level credentials because Github sends emails with the old issue title; so I didn't see that it was specific to instance admins and platform credentials since it's changed a few times.

The only thing I have a strong preference against is requiring instance admins to run code locally. That said, the Heroku Button feature allows users to set environment variables when they click the heroku button to set up the application. Further, setting the variable name to required in app.json I think makes deployments fail until the environment variable is set; which should provide feedback to instance admins getting started.

The other ones are more design considerations that we will need to work through at some point, but don't need to work through now:

Re: God-like admin powers as CLI Only - The initial admin being set via the CLI is because designing a user interface for "Making the first admin" is a non-trivial problem; It was not a "No admins may be promoted via the UI" decision.

Re: Preferring Less Environment Variables for Instance Configuration - Storing site-wide data in ENV can make migrating off of Heroku difficult. ENV variable management is one of the biggest difficulties I've seen new sysadmins struggle with when migrating from Heroku to their own servers. This is because there's some non-intuitive nuance around what environment variables are set at the process and user level depending on how processes are started as well as due to the fact that most of the time these variables are defined via filesystem, which means to change them in a "servers are impermanent" environment requires an image rebuild. This is by no means a blocking concern, but the more data we pull up into ENV variables the harder the work of fixing this becomes.