One thing that could maybe work is to offer generic apps with various standard auth schemes:
• Generic App with HTTP Basic auth.
◦ Option to toggle base64 encoding of the credentials.
• Generic app with OAuth.
• Generic app with API key.
• etc.
Yea that’s essentially how it’ll work
It’s more or less exposing our current internal UI to everyone, and letting you publish your own apps to your own workspace (along with an option to submit an app for us to publish publicly)
How about an empty form where you can input the key and values?
Ah gotcha
There’s some duct tape and glue and “known quirks” we need to iron out first 
(and enable publishing to an individual workspace only)
: Custom app properties would definitely be useful, because not everything an app needs is related to authentication!
Yea the no auth case is supported today and would be supported w/ this
You’d be able to define inputs that you could configure and access via this.your_app.$auth, like with existing apps today
Here’s a good example where we’d need custom properties for an app (per each account):
• Authentication is done against a single API endpoint (e.g. someapi.com/auth)
• But then further communications with the API are done with a custom subdomain per customer/account (e.g. mycompany.someapi.com/)
• So for each account we create for this app, we need to be able to specify what the subdomain is so that we can use it in our actions.
And yeah… custom properties could just be a big json field. :man-shrugging:
But specifying expected keys is a bit better to standardize things and avoid typos, etc.