I'm currently trying to send an email from our Squarespace newsletter signup to our Everlytic but I'm hitting 401 response headers from Cloudflare. The support agent suggested I send through the call (The Auth header is already base64 encoded):
javascript sends an email address to a contact list (id 31188). It currently works in Postman but has issues when it's sent through the browser. It's not CORS and the response header shows a 401 from cloudflare.
Related
Having application with SAML authentication along with Azure AD as IDP. When I hit Login SSO button the following happens:
Hits SAML Redirect URL (/Saml/SAMLLoginRedirect)
Redirects automatically to Ping Federator. Redirected URL is received with the response header of the first request. URL consist some SAMLRequest Token and RelayState value. Final response has Submit Form along with new SAMLRequest token and RelayState.
Hitting IDP (login.microsoftonline.com//saml2 with the SAMLRequest and RelayState from the final response not works as expected.
I have resolved this issue in jmeter. I have just enabled Follow Redirect so jmeter provides the response and cookie. I am extracting the Header value of first the request from URL. It is just because Jmeter has the feature of accumulating redirect sample into the original request.
So I am again hitting Ping Federator with the Token and RelayState received using URL extractor along with final response Cookie.
Further I am able to complete the IDP process successfully.
I am not able to achieve the same using RestAssured. When I disable redirect I am able to get the url from header. Processing the URL from the header value throws 500 error code though I have added the cookie information.
If I enabled redirect I am getting 200 response code along with expected response body and cookie.
But I am unable to proceed to the Ping Federator with the token and relay state received from the response. So I have to hit again the Ping Federator with the previous SAML Token again as I did with jMeter to achieve the proper response.
Problem: Unable to get the header value if I enable the redirect and further processing fails. If I disable the redirect then I am not getting Cookie and expected response when processing the URL from header value. Here all are GET request until the IDP (login.microsoftonline.com)
JMeter's HTTP Cookie Manager automatically extracts cookies from the Set-Cookie response header and sends them with the next request via Cookie request header if domain and path match and the cookie isn't expired.
RestAssured doesn't do this automatically so you will need to extract the cookies from the response and add them to the next request manually.
References:
REST Assured Tutorial 49 – How To Retrieve Single and MultiValue Headers From Response Using Rest Assured
Headers, Cookies and Parameters with REST-assured
Going forward you can just use a sniffer tool like Fiddler or Wireshark to compare requests coming from JMeter and RestAssured, given you send the same request (apart from dynamic parameteres which need to be correlated) you will get the same response
I followed the Sonos docs for adding app authentication and the page for using authentication tokens and the result is that the SMAPI server correctly returns an authToken together with a privateKey back to the controller. I can see the authToken being present in the credentials header inside the SOAP messages sent to my SMAPI server.
However, despite the many mentions of this inside the Sonos docs pages related to HTTP requests (I will list the resources links down below), the same authToken is not being sent inside the HTTP header Authorization, this making my CQ server unable to validate requester identity.
I tried the following, without success:
checking "Requires authorization header" capability in the customsd page of my Sonos device (I tried this because the docs page about capabilities precisely indicates that checking this "Sends OAuth token in the HTTP Authorization header.")
identifying some correlation between the "X-Sonos-" prefix HTTP headers used when the controller sends SOAP messages to my SMAPI server and the "X-Sonos-" prefix HTTP headers used when the device sends HTTP requests to my CQ server (eventually, I could not find any information that would identify the user based on this)
From Sonos device:
X-Sonos-Playback-Id: RINCON_48??????D201400:3165321802 <= deviceId inserted after RINCON_
X-Sonos-Device-Id: Sonos_U????????????????????????6 <= householdId
X-Sonos-Corr-Id: 267e3e0c-75ca-4b9d-8be4-b8a795a462a3 <= unique each time
From macOS Controller:
X-Sonos-Controller-ID: 68:??:??:??:??:07 <= the same each time
X-Sonos-Api-Key: 8??????e-7??7-4??f-b??6-7??????????0 <= the same each time
X-Sonos-Corr-Id: 648ec896-e043-44f8-bfba-cd0a80c9d857 <= unique each time
checking both "Include SMAPI context headers with all requests" and "Include Zone Player IDs in credentials header" capabilities in the customsd page of my Sonos device (I tried this following the answer to this sonos tagged stackoverflow question Now that device ID is deprecated, is there another way to identify the client?)
The docs links I mentioned above that refer the presence of the auth token inside the HTTP Authorization header are the following:
the GET /context CQ API method page says to return 401 Unauthorized when "The access token has expired or is invalid."
the GET /itemWindows CQ API method page says "the player can use this API to obtain a new access token in the response from your cloud queue server" and "The request contains the access token in the authorization header" and "If the access token is set to expire soon, an updated one is included in the X-Updated-Authorization header of the response"
the POST /timePlayed CQ API method page says "The request header contains the access token in the authorization header" and that the method returns ERROR_SONOS_TOKEN_EXPIRED when "SMAPI OAuth token is expired, and user must re-authorize the account"
the GET /version CQ API method page says again that "The request contains the access token in the authorization header" and talks about a now deprecated updateToken parameter and also says that "If the access token is set to expire soon, you should include an updated token in the X-Updated-Authorization header."
But the most clear mention is in the page about HTTP requests, because it's not particular just for the CQ API endpoints but for all HTTP endpoints, even those hosted by the SMAPI server itself. The page reads the following 2 excerpts:
and
To conclude, with so many mentions of it in the official Sonos docs, why isn't this essential header being transmitted in the HTTP Authorization header? And how should a CQ verify the identity of the requester without the presence of this authToken on each API method request?
The auth token is sensitive information and will not be included in the HTTP headers if it's being sent to an endpoint that is insecure.
Try again with your CQ server behind an https:// address.
If I follow you correctly, the token is passed in the header under loginToken, see https://developer.sonos.com/build/content-service-add-features/add-authentication/use-authentication-tokens/
This is not an http header, this is a section of the SOAP envelope. Like this:
I am trying to integrate a third party API. I was provided with a username and password.
When I use Postman to send a post request to the login webpage; the request header contains a postman token:
Postman-Token: vvvvvvvvv-wwwww-xxxx-yyyy-zzzzzzzzzz //this is not the real value
If I supply the postman token to every request after the login request (as shown below) then everything still works as expected:
If I access the api through my webpage, then everything also works as expected. My questions are:
What is the Postman token? I have looked already here: https://stackoverflow.com/questions/36883046/what-is-the-postman-token-header-attribute-in-generated-code-from-postman#:~:text=1%20Answer&text=This%20is%20primarily%20used%20to,random%20token%20avoids%20this%20issue.
What is the alternative to the Postman token when accessing the API though a webpage. I can see no token in the request when looking at it using Fiddler. Were is the bearer token in Fiddler?
Postman Token :
So it is just a custom header to track and debug postman requests in the receiving server
It doesn't do any authorization
Why no token in fiddler:
Because you haven't added it . You can add any custom header to the request you are sending
Why it works when used as bearer token
Because in your login call your session is cached . So for subsequent requests it is using cached session
To close the session , update the Connection header from keep-alive to close
Try setting second request to no auth:
and see if the request is still successful to confirm you are using cached session
I am building a intergration in Zapier (not a ZAP) to retrive dat from Monday.com Monday uses an API key that is required to be passed in the header to authenticate requests.
In Zapier developer I have set up the authentication as API Key. I have set up a field api_key for the user to add their key.
I have set up the test get request and in the HTTP Headers tab have added the api_key
When I send the reqest authentication fails with the folloaing error
authentication failed: The app returned "Not Authenticated". What happened (You are seeing this because you are an admin): Stack trace: ResponseError: {"status":401,"headers":{"content-type":"application/json; charset=utf-8"},"content":"{"errors":["Not Authenticated"]}","request":{"url":"https://api.monday.com/v2?query=%7Bme%7B%7D%7D"}} at
The Authentication code is
I think the issue is that you are sending API key as api_token header.
You need to send this API key as "Authorization" header of your request to monday.com.
example
I am struggling to understand how to implement a Google login. This is currently where I am at:
The client loads a default static HTML page from the server with a login button. Once clicking the login button it redirects them to the /login endpoint on my server. This redirects the user to the Google login and then consent page. Once the user logs into Google it redirects them to the /oauth2callback endpoint on my server. The response from Google contains the token that I need to get all the user info that I need. After I get the info from Google's services I need a way to send this info to the client in a JSON format. This info will be used in order for the client to connect to a websocket endpoint on my server.
I don't understand how I can send this info to the client. The client has been redirected to pages with no GET requests made to my server so I cannot send a JSON response. I don't want the client to make an additional GET request to the server if at all possible. How can I send the data I need to to the client?
I'm guessing your oauth2callback redirects to, or serves a page to your user. How about setting the JSON into a cookie that your JavaScript can then parse.