Make chained request values "environment aware"

[qJake]

• Insomnia Version: 5.12.4
• Operating System: Windows 10 Pro (10.0.16299.125)

Details

If a workspace contains a chained request value (e.g. a bearer token) and there is more than one environment (e.g. development and staging), if a request is executed in development that requires a chained request value, that value will persist if switching to the other environments.

Steps to Reproduce

1. Create "Development" environment
2. Create "Staging" environment
3. Create POST request which retrieves OAuth 2.0 Bearer token
4. Create GET request which requires Authorization: Bearer <token> header
5. Fill Auth Bearer Token value with Response => Body Attribute macro, executing the POST Token request from Step 3.
6. Execute request, and ensure bearer token was used in the request successfully
7. Switch environments
8. Execute the same request. Note that the previous bearer token was cached and used as part of the request (and, presumably, you will get either a 400 Bad Request or 401 Unauthorized error).

[welcome[bot]]

👋 Thanks for opening your first issue! If you're reporting a 🐞 bug, please make sure
you include steps to reproduce it. If you're requesting a feature 🎁, please provide real
use cases that would benefit. 👪

To help make this a smooth process, please be sure you have first read the
contributing guidelines.

[gschier]

Hi @qJake, thanks for the great issue report!

To clarify, this is not a bug but a limitation of the feature. The Response => Body Attribute simply pulls the value from the latest response of that request, meaning it has no concept of environments.

I think this can actually be treated as a larger issue with environments in general. Perhaps environments should affect the user's workflow more than they do? For example, only showing responses sent using the currently-active environment would prevent this from being an issue and possibly even be the desired outcome.

P.S. This does not solve the problem, but I'm curious... How come you are not using the official OAuth 2.0 support?

[qJake]

We interface with a custom third-party API we don't control, and they don't implement "proper" OAuth 2.0. I wish we could use it. 😄

I'm curious - you said it only pulls the last response from the referenced request - if there is no response, does it execute that request first in the background?

If so, would it be possible to just delete the "cache" upon an environment switch, so to speak? Or would that mess up some other use cases for environments...?

If it helps, I consider an environment an isolated entity - I would not want my staging responses being used in development, or worse, my production responses used somewhere else inadvertently. (Granted, this is just a random bearer token, but still.) We also use the environment switcher for accessing different client servers occasionally (we're talking a dozen or so, sometimes less) - so obviously any persistent data between those environments could present a problem (at the very least, auth won't work, as I reported ⏫).

For what it's worth, we just switched from Postman and I'm already loving Insomnia a lot more, so keep up the great work!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[qJake]

Could this be marked as an enhancement for future work on environments? I just don't want it to get closed - I think it's still a viable addition to Insomnia!

[devinsba]

I just ran into this using the official OAuth 2 support, it was completely unexpected. I certainly would like the "responses from one environment not available in another" feature. Would love to see that

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[qJake]

Bad stale bot! Bad!

Paging @gschier - can we switch this to an enhancement request so it doesn't get closed? Would love to see this functionality improve in future versions!

[gschier]

Yep, now it won't close 😄

[jmillxyz]

FWIW I just ran into the same issue -- we use bearer JWT tokens with multiple environments (dev, staging, prod, etc) and tokens are generated by scoping them to a single environment. Caching them across environments in my case was unexpected. What's the best way for us to help with this @gschier ?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[qJake]

Bad bot! No stale tag! This is still something I'd love to see - essentially having the history / response cache be per-environment instead of global. Would have numerous benefits!

[gschier]

Sorry about that. I was changing up the issue tag descriptions so the stale bot went on a rampage!

[qJake]

I have a follow-up suggestion to this that may work or be a bit easier to implement with regards to the suggestion above...

I noticed a new feature, Trigger Behavior, on the Response function. Would it be possible to add a new Trigger Behavior called "On Environment Change" that would cause the request to re-execute if the user switched environments? This would satisfy my previous concern about cross-contaminating environments and auth tokens.

Thoughts?

[nailgilaziev]

I was going to open a new thread about this issue, but it turns out that everything has already been thought up before me. I have the same problem and I came to the same solution: add a new menu item in "Trigger Behavior" - "On environment change".

I see that many people suffer from this isuue, I see that neighboring issues silently closed. Who can raise the priority for this feature?

[fcottet]

This is very similar to issue #260
It would be awesome to see these 2 questions solved in a similar manner - like an option at the workspace level to reset all the stored responses/tokens when switching between environments.

[iangus]

@wdawson why was issue #669 closed? As far as I'm aware this is still an issue that requires massive amounts of duplication to work around...

[subnetmarco]

@iangus not sure why this was closed, but thanks for bringing this to my attention. We will look into it.

[nailgilaziev]

What's wrong with the idea of ​​a new "Trigger Behavior" - "On environment change" menu item as a solution to the problem?

[cwangsmv]

@iangus @nailgilaziev If you're switching collection environment, you can enable Filter responses by environment and set Trigger Behavior - No History

By default, we will filter chained response with regardless of the environment you have selected.
After enable this option, we will find the required response by both request id and environment. So after switch environment, we will find the response matching your current environment.
If no response found, we will trigger your chained request automatically.

Hint: This only works with collection environment, global environment switch is not working now.

[cwangsmv]

This issue has been fixed in #7896 and any environment changes will trigger chained request resend unless you choose "Never" as Trigger Behavior. It will be available in Insomnia v10