Postman 401 Unauthorized using Ocelot - postman

I am implementing an Ocelot gateway. When I make the API call using my browser to http://localhost:5009/api/values, I get a valid json response back. However when I make the same request through Postman I get a 401 Unauthorized response. Any ideas if there is a setting in Postman I need to change or something else.

That is, the client must authenticate itself to get the requested response.
Most likely you have forgotten to put your token to the Header in Postman to be authenticated for the server in order to get a response.

Related

Postman 403 Token Issue

I am trying to get request with endpoint after successful login.
I achieved to be login and take the token but I could not take the list with this token. I am using postman. Whenever I click the url link i sent with token i can see the valid json with my safari.
{
"message": "Forbidden"
}
what i sent https://qo7vrra66k.execute-api.eu-west-1.amazonaws.com/products?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
How can I send and successfully take this request from postman ? Also I couldnt understand why postman don`t allow this like safari.
I tried your endpoint and got no error.

POSTMAN Digest authentication not working

I am trying to access a REST API (Shopware to be specific), which is hosted externally.
When I log in to the frontend in the browser, I first need to enter a set of credentials in the browser authentication pop up. And then the application opens and I need to enter the application credentials.
I assumed the authentication for the API would also be similar.
This is how I see this set up: (sorry for the crude image) Set up pic
So first, I use HTTP Basic auth and pass my browser credentials to the server.
I get the following response:
{
"success": false,
"message": "Invalid or missing auth"
}
But in the Response header I get
Basic realm="<Realm B>", Digest realm="<Realm B>", domain="/", nonce="<nonce>", opaque="<opaque value>", algorithm="MD5", qop="auth"
Does this response mean that both Basic and Digest are supported for Realm B and the client can use any one of these?
I tried to authenticate again with Digest Auth chosen in postman,and using the realm B, nonce, opaque and qop values provided in the previous request.
But I still get a 401 Unauthorized error.
What am I missing? How does this two factor auth work via Postman?
Thanks in advance for your help.

Could not get any response in postman for API post request

I am trying to do a post request in postman for jira Api testing. but keep getting could not get any response error. Please see pictures below. I have turn off SSL certificate as suggest one post here but still not able to get the response.

How to send a POST request which has Content-Type "application/x-www-form-urlencoded' by using AWS API Gateway?

I'm trying to send a POST request to a REST service via AWS API Gateway.
The content-type of the request should be 'application/x-www-form-urlencoded'. It's an authentication service that I'm trying to access. I'm sending 'username' and 'password' in my request body.
When I send the the request via Postman, it works ( It's giving me the proper response ).
But I want to create an API from the API Gateway to access this endpoint.
When I create a POST method in the API Gateway and try to test it without specifying any content-type, the back-end server tells me to send the request by using the content-type 'application/x-www-form-urlencoded'.
Then when I try to put the content-type in 'Mapping Template' section in the 'Integration Request' of the API, the request doesn't even hit the backend. There's an error ( a JSON response ) comes when I test it, saying 'Unsupported Media Type'.
Does anyone out here knows any workaround for this?
I found the solution.
In order to access a POST service using the content-type ‘application/x-www-form-urlencoded’ in API Gateway, make sure you are doing the following in the API console.
Make sure you have enabled the ‘Use HTTP Proxy integration’ as the following in the ‘Integration Request’ section.
When you test the request, make sure you are putting the content type ‘application/x-www-form-urlencoded’ inside the Header’s box as in the following.
And the request body should be like the following as well.
username=user#wellcomww.com.au&password=123456

AWS Serverless API Request

Whenever I begin to use the AWS_IAM authorizer on my function, my API GET request - which is being made from a web client - receives a No 'Access-Control-Allow-Origin' header is present on the requested resource. and I'm getting a 403 status code. When I remove the aws_iam authorizer, the API request - made via the same web client - succeeds. So I'm pretty sure it's not actually a CORS error since I've double checked that my API has cors enabled. I'm not sure if I'm using the AWS Javascript SDK wrong or if I'm not generating proper roles for AWS_IAM in my serverless.yml config.
When I run the request from postman with my personal access keys from AWS, the request succeeds. When I console.log the keys from the AWS.config.credentials and use those in postman, the request receives an invalid token error message. Maybe I haven't generated the proper role for my federated identity pool?
I'm using aws4 on the front-end to sign the request, and I use axios to make the request.
Any ideas?
Axios will make a pre-flight request. It's an OPTIONS type and expects a 200 response before it will make the GET request. It also needs to return the CORS header:
Access-Control-Allow-Origin: *
Postman won't make the same call automatically but you can use it to test that request. Ensure that your API is accepting OPTIONS request methods for that route and that it returns an empty 200 response with the CORS header and I think you'll be good to go.
AFAIK, the OPTIONS request needn't be authenticated. Just give a green light. It may be the case that your client is making calls to this endpoint as OPTIONS requests that are being authenticated, adding a second layer of confusion, or you may need to add an Access-Control-Allow-Headers to allow an Authorisation type header if AWS is using one.
Hard to give more information without debugging but I would start with an OPTIONS request.