This topic was automatically generated from Slack. You can find the original thread here.
is it possible to create a custom app that is private to my paid workspace? I run an obscure vendor app API behind an authentication-checking proxy, and right now if I want to access that API from a step, I configure four different step props with the API location and various credentials with values from environment variables, and this would be less tedious if those credentials were all saved in a private app configuration that I could select just once per step. Two alternatives I can think of would be to hardcode those values into a custom action, using a prop to choose between alternate configurations, or to put all of the props into a single environment variable as a JSON string so that they can be passed all at once. Neither alternative is ideal for various reasons.
Yes, it is possible to create a custom app that is private to your paid workspace in Pipedream. You can achieve this by creating a custom app in Pipedream that encapsulates all the necessary credentials and configurations for your obscure vendor app API. This approach allows you to manage these credentials in a single place and select the app once per step, simplifying your workflow configuration. Here’s a general approach to achieve this: 1. Create a Custom App: You can create a custom app in Pipedream that includes all the necessary credentials and configurations as app props. This app can then be used in your workflows to access the API. 2. Use Environment Variables: Store your sensitive credentials in environment variables and reference them in your custom app. This keeps your credentials secure and separate from your code. 3. Define App Props: In your custom app, define props for the API location and credentials. These props can be populated using the environment variables. Here’s an example of how you might define a custom app with props: import { axios } from "@pipedream/platform"; export default defineComponent({ props: { my_custom_app: { type: "app", app: "my_custom_app", }, }, async run({ steps, $ }) { const response = await axios($, { url: `${this.my_custom_app.$auth.api_location}`, headers: { "Authorization": `Bearer ${this.my_custom_app.$auth.api_token}`, }, }); return response; }, }); In this example, my_custom_app is a custom app that you define with props for api_location and api_token. These props can be populated using environment variables. 4. Use the Custom App in Workflows: Once your custom app is set up, you can use it in your workflows by selecting it as a connected account. This will automatically populate the necessary credentials for API access, reducing the need to configure multiple step props. By following this approach, you can streamline your workflow configuration and maintain security by managing credentials through environment variables. If you need further assistance or have specific requirements, you can reach out to Pipedream support at Support - Pipedream.
Yea 100% we intend to support this. for your specific ask, can you confirm how the auth works? Want to make sure the current model I have in mind would support your use case.
In this particular case, the vendor app API uses basic auth (technically the “username” portion is a composite of three different values, one of which selects from available permissions roles), but I don’t expose this API to the internet except via a Traefik proxy which checks for a pre-shared token in a custom HTTP header. Just an extra layer “belt and suspenders” approach.
The way I would want to implement a configuration instance of this is with six different properties: API location, username, access role, a third secret thing, password, and proxy access token.
The way I would want to implement a configuration instance of this is with six different properties: API location, username, access role, a third secret thing, password, and proxy access token.
And these are all static values that you’d manually input? When you say the “username” for Basic Auth is a composite of 3 values, are they literally just concatenated, or is there a more complex computation or encoding process that you do with then to generate that “username” value?
yes, it’s all just manual input – which means I could turn it all into a JSON string or something like I mentioned in my OP; it’s just an ease of use consideration. I don’t know how an app configuration presents these values to an action step that consumes them – if the app can transform them at all, or if the values just get made available to the step. So inside the step, if I create a little axios API client, I can either build the basic auth string from the raw values in the step, or use a basic auth string pre-transformed by the app. The way you do it is instead of base64-encoding username:password you do base64-encode username:accessrole:thirdthing:password and stick that in Authorization: Basic ___ as usual
In practice if I’m using a generic API client, I can usually put username:accessrole:thirdthing into the username field of a basic auth config and everything will work… as long as the client doesn’t insist that : is an invalid character in the username field
