Calling https service in Postman client after providing auth credentials in Chrome - google-chrome

I'm testing a REST service provided by a vendor and I'm using Postman client. Initially if I tried to make service call with necessary authorization headers, the client spits out a response (not from the service but Postman) where it says something similar to cannot get a response. But once I attempt the same GET request through Chrome, a username and password is prompted from the browser and once I provide that the JSON response is shown in browser screen.
Once that is done , when I attempt the same request or other request from Postman it works fine and gives me response JSON from service.
Could someone please help me understand what happens here, thanks.

Related

Google Apps Script return 405 for POST request

I have a problem with handling POST requests in Google Apps Script. I've created simple project with following functions:
function doGet(e){
return ContentService.createTextOutput("test").setMimeType(ContentService.MimeType.TEXT);
}
function doPost(e){
return ContentService.createTextOutput("test").setMimeType(ContentService.MimeType.TEXT);
}
When I try to send a GET request from postman I get correct response - as expected. However when I try to send POST request I get 405 Method not allowed and HTML error page in response. In deployment settings I set that it should execute as me and should be accessible to everyone.
What am I missing? How to make POST requests work with Google Apps Script?
EDIT:
So as Heiko Theißen wrote below there is 302 redirect at first.
As I can see Postman follows that redirect and sends POST once again to new URL but this request fails and I still don't know why unfortunately. I can see in security section that there is header Allow: HEAD, GET.
I cannot see any preflight request from Postman (as TheMaster suggested).
About reproducibility: I've pasted complete content of google apps script, and I mentioned that I am making request from postman. Here is link to current deployment of that script: https://script.google.com/macros/s/AKfycbyHdVpclM7pH1BB3IzwNjtcH07DF75H8ldqeLQCwQnX71lMs371g-UO-i8JaI5_zRqrDw/exec
Also here is screenshot from Postman - I'm just sending empty POST request without any custom headers. Tried also sending plain text or json as payload but results were the same each time.
So back to my original question: How can I receive POST request successfully in google apps script deployed as Web App?
I make it workable from postman by disabling the annotated option from settings.
If the preflight explanation given by TheMaster does not solve your problem, the following might help:
Requests to Google Apps Script always happen in two stages: The first request draws a redirection response to a generated URL, and the second request to that URL draws the response that you programmed (the text output "test").
When the first request is a POST request, the redirection response has status "302 Found", and the specification is ambiguous about what method the second request should have:
Note: For historical reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this
behavior is undesired, the 307 (Temporary Redirect) status code
can be used instead.
Google Chrome makes the second request as a GET request (without repeating the POST payload, which the server already knows under the generated URL) and this works.
However, if your browser or Postman client does not change the method and makes the second request again as a POST (and your screenshot shows this is true), the server does not accept this and responds with "405 Method Not Allowed".
In other words: Google Apps Script expects the second request to be a GET request, but not all clients behave like that, because the specification is ambiguous at this point. Workarounds:
You can influence the behavior of Postman so that it does not preserve the POST method between the first and second request. See here.
Google Apps Script could avoid the ambiguity by responding to the first request with "303 See Other", but it does not. Perhaps create an issue for that?

Why my website cookies are not being set on my browser?

Hello I am developing a web app, with a microservices architecture.
I am using golang (Fiber) on the backend and Next.js on the frontend.
When I send a request from restaurant.quiqr.co/signin to api.quiqr.co/auth/signin, I am sending a cookie along side the response from api.quiqr.co containing the jwt token.
Everything works fine on Postman, i can see the cookie being stored and sent with any follow up request.
But when it comes to web browsers, my cookie is not being stored. What could be the issue?
I am using kubernetes with Ingress nginx, but as i mentioned before everything works on Postman.
I tried to modify the cookie domain to .quiqr.co or restaurant.quiqr.co, but this did not work, I even tried all of the SameSite attributes, but nothing worked.
The only solution that worked is when I put all of them under the same domain. For example: quiqr.co/api/auth/signin and quiqr.co/restaurant/signin, the returned cookie will have a .quiqr.co domain and everything would work fine.
I also realized that when I do so, the browser wont send a Preflight request, but if i separate them again to subdomains the browser would send a Preflight request and the returned cookie wont be stored.
So what could be the issue here? Thank you.
Both requests- Preflight and xhr
xhr request content
No cookies in my devtools

Trestle Request unsuccessful. Incapsula incident WebApi error

I'm working with Trestle which is real estate MLS service to get property data etc. I have followed their WebApi docs but I'm getting this error whenever I hit their api it looks like their server thinks that request is from some BOT. Even they recommend using Postman to test api:
Its been 3 days and still cant find any fix. Any help?
You do not seem to be following this documentation correctly.
https://docs-trestle.corelogic.com/GettingStarted/WebAPI
At the moment you are entering the token URL (https://api-prod.corelogic.com/trestle/oidc/connect/token) in the main Postman request URL field. The documentation states that you should use the Get New Access Token button on the Authorization tab of a request. You are entering the token URL in the main Postman request URL field.
This is a default flow for oAuth 2.0 requests in Postman.
https://learning.postman.com/docs/postman/sending-api-requests/authorization/#oauth-20
Example:
This could be your request to retrieve data:
https://api-prod.corelogic.com/trestle/odata/$metadata
On the Authorization tab you should select oAuth 2.0; select Get New Access Token and you will see a view which gives you the functionality you are looking for.
When successful, you will get a pop-up which you need to accept in order to use the API.

Unable to get the Gravitee API gateway respone from CHROME but able to get from POSTMAN

I am trying to hit a GET request which is a Gravitee API Gateway URL on which my web API are exposed. whem I hit the URL from POSTMAN with no headers and no Auth. , I am able to get the response but when I hit the URL from chrome or any other browser, i get this error
this site can't be reached
'ERR_SPDY_PROTOCOL_ERROR'
Please help me out ? I have tried all the methods to resolve this but still stuck.
It seems that your gateway is exposed in HTTP2.
A fix has been provided in latest 1.23.0 of Gravitee.io

How to get mosync app to use RESTful APi and json payload

I have written a mosync application that interacts with a REST we service. I am using the AMDownload package. Wat is the right way to send the json payload required by the REST API?
The HTTP 400 Bad Request perhaps happens because the MoSync Android runtime messes up the URL, causing the server to return this error. Alternatively, perhaps the MoSync Android runtime considers the URL to be wrong, and sends back the HTTP 400 Bad Request.
Is it possible for you to test on an Android device? To see if the result is the same.
Also, is it possible to find the exact URL/data sent to the server? Perhaps using some network monitor software. If you have access to the server, can you see the request it receives? If you would enter the same request in a client like the Firefox RESTClient, do you get the same response?