I have two postman requests x,y which hit endpoints in two different rest api X,Y. x will give me an authentication token which is necessary to make the y request. How do I make the request x inside request y ? That is, call x from inside y.
PS - I have already figured out how to use request x to setup environment variables (auth token) which will be picked up by y.
If you want to do it in one shot, you can use the pre-script option.
Pre-script are triggered before the request. So if you make a request and set the token in an environnement variable, the next call can use the token. You should check that page. It seems outdated, you should replace pm by postman.
You might also want to add a pre script request to your collection. This way, every request of that collection will be precede by a request to the authentification route for exemple.
Have a look at this:
https://blog.postman.com/conditional-workflows-in-postman/,
if you want to call a specific request from within a request,
the postman.setNextRequest() function will do the job.
Alexandre
The official documentation has you covered big dog - Branching and looping.
When running a collection, you can branch and loop across API requests
in Postman using the postman.setNextRequest("request_name"); function.
Then you use the collection runner to run the API requests in sequence.
Think about using the Collection Runner to execute a sequence of requests.
Related
I want to check whether my deployed ASP.NET application returns Healthy from health check endpoints or not.
Unfortunately, the success criteria samples of the "Invoke Rest API" release gate only show how to evaluate JSON responses like eq(root['status'], 'successful') or eq(count(jsonpath('Items[?(#.price<50)]')).
As my endpoint doesn't return any JSON I wonder if it's possible to do a simple stupid string equality check somehow?
Of course I could rely on checking the HTTP status code, I feel like it should be possible to access the response body.
This is the exception I get when using eq(root, "Healthy"):
If your endpoint returns just a string try simply this:
eq(root, 'SomeString')
This is really strange that you get such error. It works on my release pipeline:
Here is settings:
And here result:
Agree with Krzysztof Madej
Exception Message: Error parsing API response into a JSON object.
You could check the “URL suffix and parameters” field in “Invoke Rest API task”.
Please make sure that the whole URL is valid.
The whole URL contains the Server URL (Set in service connection) and the URL suffix and parameters (Set in Invoke Rest API task).
Hope this helps.
I have a need to pass data from one system to another, during SSO using PingFederate.
Currently my link looks like this:
https://pingfederate.myexample.org/startSSO.ping?TargetResource=https%3A%2F%2Fwebapp.othercompany.org%3FkeepParam%3DkeepThisOnURLparamOne%3DvalueOne%26paramTwo%3DvalueTwo
TargetResource, decoded, looks like this:
https://webapp.othercompany.org?
keepParam=keepThisOnURL
¶mOne=valueOne
¶mTwo=valueTwo
After pingfederate processes the request, it ends up making a post to othercompany, copying the entire TargetResource into RelayState, params and all:
POST https://sso.othercompany.org
SAMLResponse: {paramOne: valueOne; paramTwo: valueTwo} //(in actual saml format)
RelayState: https://webapp.othercompany.org?keepParam=keepThisOnURL¶mOne=valueOne¶mTwo=valueTwo
My goal is to pass paramOne and paramTwo into SAML attributes somehow, but NOT carry those params over onto RelayState, keeping only keepParam=keepThisOnURL:
POST https://sso.othercompany.org
SAMLResponse: {paramOne: valueOne; paramTwo: valueTwo} //(in actual saml format)
RelayState: https://webapp.othercompany.org?keepParam=keepThisOnURL
Is this possible to do with PingFederate?
E.g., is there any other way to pass data into startSSO.ping from a browser request besides sneaking them into TargetResource?
Or if they can only be appended to TargetResource, can the value be modified (strip off most params) before copying into RelayState?
The reason that the parameters were tacked into the Relay State is because you URLEncoded them, So PingFed thought they were just part of the TargetResource.
Instead, you would do something like this:
https://pingfederate.myexample.org/idp/startSSO.ping?
paramOne=valueOne&
paramTwo=valueTwo&
TargetResource=https%3A%2F%2Fwebapp.othercompany.org%3FkeepParam%3DkeepThisOnURL
I should point out two things, the first being a showstopper:
fulfilling attributes via parameters passed in the startSSO.ping calls is not supported and won't work properly until at least one of two current feature requests are fulfilled, PPQ-1141 and PPQ-2815. Neither of these are currently scheduled (low request volume) in the development trains, so if this is critical to your work, get in touch with your Ping account executive to have your needs communicated.
I should point out that this overall methodology probably doesn't make a whole lot of sense from an operational standpoint, simply because it means that you will be dependent on an IdP initiated transaction because you have no way of fulfilling this with an SP-initiated transaction.
Based on those, I would recommend trying to architect another solution by which you could set those attributes, which I recognize may be difficult - especially if they are only derived at runtime, rather than via query to a datastore.
I want to use Postman to test the REST API of a project, and I'm trying to a generic request. For example:
I have a POST request that makes a research, the parameters of this research
are in the body. How do I automate the request with a pre-request-script that modifies the body at each iteration?
Because I don't want to create a collection with 20 POST requests where only the body changes. I tried to use a while loop in pre-request-script or in test script but Postman executed the request only once. Then I tried to use the runner for calling the request 5 times, for example, and i wrote a script that modified a variable each time, but I think that global and environment variable are reset at each iteration of the runner.
Do you have any ideas?
enter image description here
I tried that to modify value of password when I use the runner. But if the runner reset variables at each iteration it can't work.
It's ok I found an other solution:
For example I want to test the request with 5 different password, i create 5 file json who correspond to my global variables or environment variables and in this files I modify just one variable. I use newman i a loop script to call the same request with different global variable file to modify just one parameter of the request.
You can also use set_nextRequest() (see http://blog.getpostman.com/2016/03/23/conditional-workflows-in-postman/). With this you should be able to force calling your request again with the new value for your password and not perform multiple iterations. If you use a global variable in your json body and you update it in your loop, it should work.
hope this helps
Alexandre
From a lambda implemented api gateway resource, how to get the original request URI. Or even just the original path?
Lacking a better way I'm currently using the following three variables that I pass down to the lambda using the default request template:
$context.resourcePath contains the path with variable names ex: "/blah/{var}"
$input.params().path contains the variable names and values ex: {"var":"something"}
$context.stage contains the stage ex: "prod"
That's quite a hassle since it requires path variable substitution to get the original call path:
/prod/blah/something
How can I get the original URL or URI?
I'm not finding anything in the documentation that lets you get the original call URI. I can add a feature request to consider adding it. Can you describe your use case. Why do you want to get the original URI?
I found a 'workaround'.
If you create a custom domain name with a BasePathMapping, and call the API using this custom domain, the original request uri actually has your stage name in there:
Call directly to the API gateway:
curl -v 'https://some-id.execute-api.eu-central-1.amazonaws.com/v1/ping'
...
request.url: https://some-id.execute-api.eu-central-1.amazonaws.com/ping'
But if we call it through te custom domain (which is actually a cloudfront distribution):
curl -v -X GET https://api.our.domain.name.com/v1/ping
...
request.url: https://api.our.domain.name.com/v1/ping
In my opinion, the direct call gives you an INCORRECT request url in the lambda function, as the url very clearly has the stage name in there.
This breaks the routing middleware of at least flask.
Any update on the feature request?
I am trying to redirect all traffic for one domain to another. Rather than running a server specifically for this job I was trying to use AWS API Gateway with lambda to perform the redirect.
I have this working ok for the root path "/" but any requests for sub-paths e.g. /a are not handled. Is there a way to define a "catch all" resource or wildcard path handler?
As of last week, API Gateway now supports what they call “Catch-all Path Variables”.
Full details and a walk-through here: API Gateway Update – New Features Simplify API Development
You can create a resource with path like /{thepath+}. Plus sign is important.
Then in your lambda function you can access the value with both
event.path - always contains the full path
or event.pathParameters.thepath - contains the part defined by you. Other possible use case: define resource like /images/{imagepath+} to only match pathes with certain prefix. The variable will contain only the subpath.
You can debug all the values passed to your function with: JSON.stringify(event)
Full documentation
Update: As of last week, API Gateway now supports what they call “Catch-all Path Variables”. See API Gateway Update – New Features Simplify API Development.
You will need to create a resource for each level unfortunately. The reason for this is API Gateway allows you to access those params via an object.
For example: method.request.path.XXXX
So if you did just /{param} you could access that with: method.request.path.param but if you had a nested path (params with slashes), it wouldn't work. You'd also get a 404 for the entire request.
If method.request.path.param was an array instead...then it could get params by position when not named. For example method.request.path.param[] ...Named params could even be handled under there, but accessing them wouldn't really be easy. It would require using something some sort of JSON path mapping (think like what you can do with their mapping templates). Sadly this is not how it's handled in API Gateway.
I think it's ok though because this might make configuring API Gateway even more complex. However, it does also limit API Gateway and to handle this situation you will ultimately end up with a more confusing configuration anyway.
So, you can go the long way here. Create the same method for multiple resources and do something like: /{1}/{2}/{3}/{4}/{5}/{6}/{7} and so on. Then you can handle each path parameter level if need be.
IF the number of parameters is always the same, then you're a bit luckier and only need to set up a bunch of resources, but one method at the end.
source: https://forums.aws.amazon.com/thread.jspa?messageID=689700򨘤
Related to HTTPAPI that AWS introduced recently, $default is used a wildcard for catching all routes that don't match a defined pattern.
For more details, refer to: aws blogs
You can create a resource with path variable /{param}, and you can treat this as wildcard path handler.
Thanks,
- Ka Hou