Below are two suggestions for improvement for this platform. Maybe these are already implement, and i’m missing something, but I can’t find them.
Actions Do Not Update automatically. The point of actions is to be able to re-use your code across many workflows. However, if you update an action, it does not automatically update in the workflows that use the Action. You have to manually go into each workflow and update the action to the latest version. This is an insanely difficult process when you have tons of workflows and we are going thru this nightmare now after updating a crucial action that is in many of our workflows. Basically, I see no point in Actions if this is the intended functionality. If possible, it would be better to have some utility that updates the Actions in each workflow they are used in, so you don’t have to go into each workflow individually.
Webhook Triggers don’t create a secret and are unprotected by default. When you create a Webhook you need some sort of way of validing that the request to that webhook comes from a trusted source. This sort of protection is not available out of the box with webhook triggers, even though I think it should be. Basically, when you create a webhook, the system should create a sort of secret, which must be passed in an authorization header to the webhook to allow the webhook to execute. You can of course, build this functionality on your own to protect the webhooks, but it’s a pain to do on every webhook, and it would be better if Pipedream just offered this out of the box.
For #1: when using the GitHub sync, it’s possible to do a replace all of the old version to the new version, and then push that change in one single commit. Overall it’s good not to automatically update everything though, because ideally we should be able to test workflows first (the changes could break something). But maybe they could provide a button to update everything, for those who want to do that. A GitHub feature request would probably be the best way to go! It could even be nice to have the ability to revert to a previous version.
For #2: there is this feature request which is a step in the right direction. Otherwise, webhooks are usually meant to be public and it is up to you to validate the signature of incoming requests. But I agree that if Pipedream could bake in signature verification for the major web standards (such as JWT, with the secret specified as a prop from an app or env var), it would be pretty awesome. Maybe you could create a feature request for it on GitHub? I’ll definitely add my +1!
Github sync is a custom feature for some reason and not available on the advanced plan. So we can’t use it. Incidentally, Github synch shouldn’t be some premium feature. This is a coding platform, how can it not integrate with GitHub especially at the Advanced Plan? Overall, I view Pipedream as the coder’s Zapier b/c if I didn’t need to code, I would use Zapier instead. But, the problem is that when use Pipedream to code, you end up repeating the same code in every workflow, because you can’t ever update Actions and if you do, you have to go into every workflow to update it. So you wind up with an unmaintable mess of code as there is no solution for code re-use. There is no way around it right now, that I can see. So I think they would be smart to develop some automated feature that allows you to update shared code across all your workflows with one click.
I find it very doubtful that many Pipedream customers use the platform for public facing applications. Maybe a tiny minority due, but the vast, vast majority are using this to communicate with server based applications, i.e. machine to machine to automate tasks. In that case, you need verifications out of the box. Take a look at Retool workflows for a simple solution to this. When you create a workflow on Retool, they automatically create the secret for you. It’s not a JWT, but probably should be. But, at least you have this available and don’t have to create it on your own every time. Then it’s trivial to create a Step in the workflow to do the verification, though that itself, should probably be some sort of integration to make it super easy to implement.
@osseonews thanks for the feedback and product suggestions!
Is this something you’re primarily looking to do for custom actions that you’ve published to your workspace? Or is it also something you’d want to do for the public registry actions?
We’re gathering requirements for this now – the use case that you described makes total sense, and as @mroy pointed out, this has been a frequent ask. From your perspective, would the implementation you described, to just require a secret key passed in the headers (for example) satisfy your general use case?
Yes, it’s for custom actions used internally, not public registry actions. Honestly, the way we are thinking of doing this now is to just put the actions in separate workflows with a webhook trigger, and then have the workflows they are needed on Fetch those workflows - so basically have 1 workflow call another for certain results. This is the only way we see how we can reuse code, because then the “Action Workflows” can be updated and whatever fetches them will get the newer code. Of course, this can get expensive as these “Workflow Actions” are called alot. Maybe you should have a concept of “Action Workflows” which are different than regular workflows? Overall, I view Pipedream as a kind of coding platform. But as mentioned above, once you start coding on it, you can quickly find yourself overwhelmed with tons of workflows and becomes very difficult to maintain because there is no built in way to reuse code, which is a fundamental aspect of all good programming. Unfortunately, we did a lot of stuff with internal custom actions, but these are not really good for code reuse, but you can’t automatically update any workflows that use them and now we are need to rebuild a lot of stuff because there is no way, we are going to manually update all our workflows.
“Reuse Secret Key”: I think you need a new “secret” per Workflow to keep it secure. What I guess can be done (this is just a suggestion - not sure if it’s the correct path), as we do this internally/manually now is that Pipedream provides a Global Workflow JWT signing key (maybe allow for multiple keys). Then when you create a Workflow, Pipedream creates a JWT using that Key and the ID of the workflow (some some other data to sign). The JWT is presented to the user when you create the workflow and you need to pass that JWT into Authorization Bearer when trying to access the workflow. Then you can just have a basic Action which verifies the JWT. This is very basic to build and we do it manually now, but it would be a huge time saver, if this was just handled by Pipedream automatically. One global JWT signing key would probably work, but in theory, over time, you might want to offer multiple keys so they can be rotated in some fashion.