The authentication settings will then be inherited from base environment -> environment -> request.įrom a UI perspective I would imagine that the current 'Manage Environments' screen (cmd+E) would have tabs like the requests have.
The only thing I can come up with is that you can define the authentication flow on a higher level, which would be environment and then base environment. is available in Insomnia on request level. While the whole functionality of authentication flows (oauth2 in our case), that fetches a new token, pass token as header, etc. Of course, storing a token in a variable is a work around that works, but still needs manual action every (in our case) 24 hours.
#Runemate bot doesnt launch instance update#
A few other – if your token can simply be entered in a header, you could make use of the Default Headers plugin to set it on every – to address your specific issue of having to modify each request to update your password, you can make use of Environment Variables instead, allowing you to store your password in a single place and update it easily.įirst of all, thanks a lot for looking into this. These entries would be selectable from the auth dropdown on each request. Do either of you have ideas for now re-usable authentication might work from a user-experience perspective? My initial idea would be to have a new dialog to create authentication entries. I'd like to open up this issue for discussion. Reusable authentication is perhaps one of the most requested features, however, so it might be good to solve it as a specific issue on it's own. However, I ended up deciding against it for now.
I think there are a few issues related to this floating around but they are fairly outdated at this point.Ī while ago, I tried to implement something called Parent Requests ( #598) which would provide a way for requests to inherit attributes from another one.
0 kommentar(er)
