postman-app-support
postman-app-support copied to clipboard
postmanlabs
Send Request confirmation button
Please read through the guidelines before creating a new issue.
Is your feature request related to a problem? Please describe. Having full exposed to a destructive API is dangerous. An API that does a hard delete on DELETE endpoints is very risky. One wrong click can cause damage. The actual UIs that expose these types of endpoints typically require confirmation before sending the request.
Describe the solution you'd like It would be great to have an option on all saved endpoints to require confirmation before the request is sent. The default would be to require no confirmation. But in dangerous scenarios, it could help prevent accidents. A simple "Confirm you want to send request X" with confirm/cancel buttons would be an excellent safeguard.
Describe alternatives you've considered I've had to remove DELETE saved endpoints because I'm worried I will press one accidentally.
@dmorrow Thanks for the input! This looks like it could be a pretty useful configuration to have. Out of curiosity, is this a problem you have across several collections? Or just a few important ones. Also, do you work on these APIs with a team?
At the moment this issue is only on a single collection, in a case where we don't own the API. But I can imagine it being useful on many collections.
To clarify my thought, I don't think this is a collection level setting - rather it is set per saved request. The default is no confirmation, so nothing changes for anyone. However, if you check the box, you will receive a warning and have to click again to send the request. See the mocks I made.
I do work on a team with a shared workspace.
@dmorrow That's super helpful, thanks! Let me discuss this with our team and get back to you on this.
@dmorrow is this feature available somewhere? I'm not seeing the option to add confirmation to a request. Would love this feature! Thanks.
No, this is something I requested that never got implemented as far as I can tell.
I think it should be possible to enable/disable this through the pre-request script and also via environmental variables. We might only want the popup for specific environments or if the request contains specific criteria.
the confirm feature would be good as it could save us accidently sending a request to the Prod environment.
Any updates on this? This would be very helpful for environments in order to avoid accidentally sending requests on a prod env.
+1 for possibility to configure via environment and / or pre request script!
Having a confirmation dialog for specific environments would be very helpful
Mi solucion, escribir este codigo en Pre-request Script
Antes debe crear una variable global
quiza no sea la mejor solucion pero no encontre otra forma
Mi solucion, escribir este codigo en Pre-request Script
Antes debe crear una variable global
quiza no sea la mejor solucion pero no encontre otra forma
This solution can set the variable "prd" to the same value again. So in these cases there is no warning shown.
You could change the line
prd = Math.floor(Math.random() * 5
to
prd = pm.globals.get("prd") + 1;
so it always increases.
Mi solucion, escribir este codigo en Pre-request Script Antes debe crear una variable global
This solution can set the variable "prd" to the same value again. So in these cases there is no warning shown. You could change the line
prd = Math.floor(Math.random() * 5toprd = pm.globals.get("prd") + 1;so it always increases.
Muchas gracias por la correccion
So when can we expect this? I would think having this customizable would be super helpful - ie - I would want to show this for PROD but not for QA!!!!
So slightly ressing an old thread. It'd be nice if this was native, but it's not. However what I've done might be "good enough"
So I've got my various GET, POST, DELETE etc requests in a collection. I have two environments, Production and Local. They have a hostname variable as well as a run-destructive-requests variable. On Production environment that variable is set to 0, on Local environment, it is set to 1.
In my Collection, I have the following Pre-Request script:
let method = pm.request.method
let envRunDestructiveRequests = pm.environment.get('run-destructive-requests')
if((method === 'POST' || method === 'PUT' || method === 'DELETE')
&& (envRunDestructiveRequests === '0')
) {
console.log('Found a destructive request on environment with destructive requests turned off')
let foundOverride = false
pm.request.forEachHeader((request) => {
if (request.key == 'run-destructive-request-on-prod' && request.value == "1" && !request.disabled) {
console.log('Destructive override request header found, allowing request!')
foundOverride = true
}
})
if (foundOverride === false) {
throw new Error('Cannot run destructive requests without override. To do this, set a request header "run-destructive-request-on-prod" with a value of 1')
}
}
So if I run a destructive request on Production environment, the request fails unless I add a header to the request with the value of 1 (and it must be active)
It's not foolproof but if you mess up after this, then it's on you 😁
Hopefully this helps someone.
P.S. Not claiming the best jS. I'm sure it can be better. But it works, so there's that... 😛
I have a similar script which I abandoned-seemed a good idea at first!! the challenge is that its tied to the discipline of each developer. In my team (22 developers reporting to me) - half dont have the discipline to remove the custom headers AFTER they're done using it. which kinda makes it pointless - one person went an accidently ran a PUT operation in PROD forgetting he hadn't removed the header override field and had not de-selected PROD environment (Thinking he was running in QA).
Its after he discovered he had forgotten to remove the override from the headers... fairly clumsy person generally... that once incident spurred me to reveoke permissions to everyone but 3 senior developers in rotation.
The Simplest solution is to have POSTMAN allow an OK/CANCEL alert that allows to move forward or reject based on the environment. Its pretty much foolproof with an either/or construct... cant imagine why its taking them forever to give such a demanded feature
I have a similar script which I abandoned-seemed a good idea at first!! the challenge is that its tied to the discipline of each developer. In my team (22 developers reporting to me) - half dont have the discipline to remove the custom headers AFTER they're done using it. which kinda makes it pointless - one person went an accidently ran a PUT operation in PROD forgetting he hadn't removed the header override field and had not de-selected PROD environment (Thinking he was running in QA).
Its after he discovered he had forgotten to remove the override from the headers... fairly clumsy person generally... that once incident spurred me to reveoke permissions to everyone but 3 senior developers in rotation.
The Simplest solution is to have POSTMAN allow an OK/CANCEL alert that allows to move forward or reject based on the environment. Its pretty much foolproof with an either/or construct... cant imagine why its taking them forever to give such a demanded feature
Yeah I wouldn't recommend this for other people, just those that are self-responsible. Care still needs to be taken, naturally.
That being said, I absolutely agree - having an environment-level toggle to confirm running of destructive queries is a must-have and as you say, baffling that it still isn't a thing.
Instead of a header, you can enforce setting a global variable that your script can reset before sending. Define a global function and just call that for each destructive call as a pre-request script.
The only caveat I found is that you seemingly can't set environment variables in a collection-level script, but you can use a callback in the request's pre-request scripts:
utils.protectDestructiveEvents(function(){pm.environment.set("allowDestructiveEvents", false)})
That being said, big +1 for this feature...
Instead of a header, you can enforce setting a global variable that your script can reset before sending. Define a global function and just call that for each destructive call as a pre-request script.
The only caveat I found is that you seemingly can't set environment variables in a collection-level script, but you can use a callback in the request's pre-request scripts:
utils.protectDestructiveEvents(function(){pm.environment.set("allowDestructiveEvents", false)})That being said, big +1 for this feature...
Not a bad solution. The problem with setting variables in collection-level scripts referenced from lower-level scripts seems to be with scoping of the 'pm' object. You could pass the 'pm' object to the 'protectDestructiveEvents' function like so:
utils.protectDestructiveEvents(pm);
This is really important for third-party APIs that don't have a sandbox/test environment. When developing, you want to be able to run the API requests, and use the postman requests as documentation. However, as soon as the app enters production, running these requests could be harmful, so a warning to make sure the person really means to run the request would be necessary.
I'm currently working with a digital archive that doesn't have a test environment, and we can't allow someone to upload nonsense to it as the whole point is it can't be deleted. However, we need to have the API request for documentation purposes and its useful during the development process.
You can instead use the pm.execute.skipRequest() in Pre-request script to not execute the request based. Additionally, you can add certain conditions on which you want this request to be skipped, and additionally add some messaging in the console.
Read more about this function here.
We aren't fully sure if adding another confirmation box will help with the use case. Let us know if this solution works
