More Centralized API Key / Secret Structure For Gallery

[brianscott]

Hello Alteryx Devs - 

So, I'm poking around the Atlerxy Gallery API stuff with an eye toward building a set of classes that can interact with workflows without exposing Gallery proper to the community at large.  That being said, I was a little dismayed to find that all interactions require inclusion of *user specific* API Keys and Secrets.  It can be dealt with, but ultimately it means that configuring a middleware tier between the real world and Alteryx server requires an additional hierarchical level; i.e., understanding which of the developers came up with workflow X and having *their* API Key / Secret attached at configuration time.  

Anyways, it might be easier to just have a global trusted key / (super) secret.  If you get that, you can execute a workflow.  

Maybe we have a special studio that people could clone to, and in this way, you'd only have to track a single key/secret outside.  

I mean, the existing system works OK for one offs, but if you wanted to have a (semi) modular system in place, dependence on understanding publishing entity specifics seems to muck things up for no discernible benefit.  Of course, maybe in some places there is benefit to this scheme (?), but it is causing me to craft some weird work arounds early in development, which gives me a sinking feeling.

Or am I doing it wrong? 

Thanks for listening. 

brian

[JohnPelletier]

@brianscott I'd love to better understand your thoughts on the super key. We need to identify users in order to give proper permissioning and visibility on things when API calls are made. The API call from one user might return different results than that same API call from another user. We need that functionality. On the other hand, we want to help you any way we can to avoid weird workarounds. So please give me more details on what your problem case is, and then how you envision we can reconcile the need for RBAC with your functionality needs.

Thanks!