Calling a rest api from a customer's web api and it's returning duplicate Access-Control-Allow-Origin: * and it causing COR errors.
I've tested locally and the duplicate does cause the error whereas a single Access-Control-Allow-Origin: * works.
Is there a way around this from my side when calling the GET?
HTTP/1.1 200 OK
Date: Wed, 28 Nov 2012 19:40:10 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: *
Set-Cookie: TargetToken=AB3Hirk0TNDPCfVY6LZd1Fs1; Expires=Fri, 28-Nov-2014 19:40:10 G11T; Path=/; HttpOnly
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Content-Type: application/xml; charset=utf-8
Content-Length: 590
XMLHttpRequest cannot load http://target.com/api/getstuff?stuffid=4.
Origin http://mysite.com is not allowed by
Access-Control-Allow-Origin.
The CORS spec explicitly states that multiple Access-Control-Allow-Origin headers are not allowed: http://www.w3.org/TR/cors/#resource-sharing-check-0
Is there any way to convince the client to fix their server implementation?
Related
I am using Jmeter 5.4.1 version, my API is of oauth1.0 type. When I ran my api through postman , it gave my proper json response for example an proper id, but the same api when ran through jmeter gives 200 response code but giving details of server and connection in response body and not the reponse that is expected(a proper id).
Below is the response :
HTTP/1.1 200 OK
Server: nginx/1.14.0 (Ubuntu)
Date: Wed, 12 May 2021 12:33:10 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Set-Cookie: PHPSESSID=eqvp0l22u2jo30moqn194meugp; expires=Wed, 12-May-2021 13:33:10 GMT; Max-Age=3600; path=/; domain=dev.moorup.no; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
X-Frame-Options: SAMEORIGIN
Cache-Control: no-store
enter image description here
You're looking at Response Headers tab of the View Results Tree listener therefore you're seeing the HTTP Response Headers
Just switch to Response Body tab and you will be able to see "raw" HTML Response and several options of rendering it:
Also be aware that it is possible to convert your Postman scripts to JMeter, for OAuth you will still have to do some correlation, but for the main logic record and replay should work more or less fine
I'm using RestSharp to interface with the Auth0 and Sisense APIs. Everything's working fine except when deleting a user in Auth0. I send the delete request as a DELETE and Auth0 successfully deletes the user.
Here is the response I'm getting from Auth0:
HTTP/1.1 204 No Content
Date: Wed, 19 Feb 2020 16:35:28 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Server: nginx
ot-tracer-spanid: 21cd87957d9bac76
ot-tracer-traceid: 25a636cb6e5fd4ca
ot-tracer-sampled: true
x-ratelimit-limit: 50
x-ratelimit-remaining: 49
x-ratelimit-reset: 1582130129
vary: origin,accept-encoding
cache-control: no-cache
Strict-Transport-Security: max-age=15724800
X-Robots-Tag: noindex, nofollow, nosnippet, noarchive
And here's what I'm getting in the RestSharp response:
System.Runtime.Serialization.SerializationException: Invalid JSON string
at RestSharp.RestClientExtensions.ThrowIfError(IRestResponse response)
at RestSharp.RestClientExtensions.DeleteAsync[T](IRestClient client, IRestRequest request)
I'm making a call to a Sisense web service and RestSharp is handling the 402 just fine. Here's the Sisense response:
HTTP/1.1 204 No Content
Date: Wed, 19 Feb 2020 16:32:14 GMT
Connection: keep-alive
Set-Cookie: sisense-cookieCORS=***************************; Path=/; SameSite=None; Secure
Set-Cookie: sisense-cookie=***************************; Path=/
X-UA-Compatible: IE=Edge
x-xss-protection: 1; mode=block
x-frame-options: ALLOW-FROM https://****************************************************
content-security-policy: frame-ancestors ****************************************************
Cache-Control: private, no-cache, no-store, must-revalidate
Expires: -1
Pragma: no-cache
The main difference between the two is the Content-Type directive present in Auth0. Is that what's causing the problem? Is there a workaround?
I am not sure why i am getting this error message. i have inserted the ids
POST /oauth2/v4/token HTTP/1.1
Host: www.googleapis.com
Content-length: 322
content-type: application/x-www-form-urlencoded
user-agent: google-oauth-playground
HTTP/1.1 400 Bad Request
Content-length: 68
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
Transfer-encoding: chunked
Vary: Origin, X-Origin, Referer
Server: ESF
-content-encoding: gzip
Cache-control: private
Date: Sun, 11 Nov 2018 23:59:34 GMT
X-frame-options: SAMEORIGIN
Alt-svc: quic=":443"; ma=2592000; v="44,43,39,35"
Content-type: application/json; charset=utf-8
{
"error_description": "Bad Request",
"error": "invalid_grant"
}
Bad Request error occurs when the request syntax are wrong (i.e. when a parameter or a header you are supposed to send is missing or contains an incorrect/invalid value). Best option is to check OAuth Specification are figure out what you have done wrong in the token request. Google might have a slightly different implementation from the actual specification, but I think it won't be difficult to find the issue after checking the documentation.
Access token request specification for authorization code grant can be found here.
I've been using the Office 365 Calendar REST api for a few weeks with several users.
I'm currently experiencing something very wierd:
When fetching events of a specific user with the /calendarview call (via OAUTH2). I get perfect results (though very slow), EXCEPT when 25/01 is between my start_date and end_date, I get :
{"error":{"code":"ErrorInternalServerError","message":"Object
reference not set to an instance of an object."}}"
I suspect one the event of this user is causing this, but still, the API should not bug ?
Any clue?
Here are the instrumented logs:
GET /api/v1.0/me/calendars/AQMkAGVmMjlhY2E5LWE4MmMtNGFhAGMtYjY5OC0wNmRiMWYxZDJkM2UARgAAA4ZtZygzpnpGt-RyQ8uQQ80HAG6teJW1hzZBuLm47wZiBYIAAAIBBgAAAG6teJW1hzZBuLm47wZiBYIAAAIM4gAAAA==/calendarview?&startDateTime=2015-02-24T23:55:38Z&endDateTime=2015-02-25T23:55:38Z&$top=50&$skip=0
HTTP/1.1
Content-Type: application/json
Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
Accept: */*
User-Agent: Ruby, JulieDesk
Authorization: Bearer $REFRESHTOKEN$
Return-Client-Request-Id: true
Client-Request-Id: be203946-93b7-47f6-b402-edbd0ed49653
Host: outlook.office365.com
HTTP/1.1 500 Internal Server Error
Cache-Control: private
Content-Type: application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8
Server: Microsoft-IIS/8.0
request-id: 4a0fe2ba-a761-4526-bd09-70c81e084cb5
client-request-id: be203946-93b7-47f6-b402-edbd0ed49653
Set-Cookie: ClientId=LSM5BXAUPUIJBVFLY0LDA; expires=Tue, 16-Feb-2016 23:55:39 GMT; path=/; secure; HttpOnly
X-CalculatedBETarget: co1pr07mb316.namprd07.prod.outlook.com
OData-Version: 4.0
X-DiagInfo: CO1PR07MB316
X-BEServer: CO1PR07MB316
X-AspNet-Version: 4.0.30319
Set-Cookie: exchangecookie=7b08adfab00641009c1cbbf90594797d; expires=Tue, 16-Feb-2016 23:55:40 GMT; path=/; HttpOnly
Set-Cookie: X-BackEndCookie2=3bd486f8-787b-435b-8269-5359cdbcc7ce=u56Lnp2ejJqBxsmZysiemc/SyMmazNLLyJvO0sbGxs3Smc+bm87Pz8+dm8aegYHNz87K0s/M0s7Hq83MxcrKxcvJgZGeko+Nm8/I0Y+NkJvRkIqLk5CQlNGckJI=; expires=Wed, 18-Mar-2015 23:55:46 GMT; path=/api; secure; HttpOnly
Set-Cookie: X-BackEndCookie=3bd486f8-787b-435b-8269-5359cdbcc7ce=u56Lnp2ejJqBxsmZysiemc/SyMmazNLLyJvO0sbGxs3Smc+bm87Pz8+dm8aegYHNz87K0s/M0s7Hq83MxcrKxcvJ; expires=Wed, 18-Mar-2015 23:55:46 GMT; path=/api; secure; HttpOnly
X-Powered-By: ASP.NET
X-FEServer: DM2PR09CA0014
Date: Mon, 16 Feb 2015 23:55:45 GMT
Content-Length: 111
-> "{\"error\":{\"code\":\"ErrorInternalServerError\",\"message\":\"Object reference not set to an instance of an object.\"}}"
Sorry about the odd error! I'd definitely like to find out more. Could you add client instrumentation to your request, reproduce the error, and let me know the values of the HTTP response headers in that article?
I had this issue when filtering by Subject where some events didn't have a subject.
I fixed this by including Subject ne null in the filter query
I have been trying to obtain new oauth2 refresh tokens using oauth1 access token but it constantly returns an "invalid_token" error. I have checked and the access token is working correctly. I have also tested the same creds/params in oauth2 playground and result is the same. Any help is appreciated...
Here is the curl verbose output:
> POST /o/oauth2/token HTTP/1.1
Host: accounts.google.com
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth oauth_nonce="cb7407355fe20f509cb6bf901eae2d24", oauth_timestamp="1389169471", oauth_consumer_key="***", oauth_token="1%2FFVy....", oauth_signature_method="HMAC-SHA1", oauth_signature="0YL1hH5R571nOH1byeHxQlg%2Fa6g%3D"
Content-Length: 444
* upload completely sent off: 444 out of 444 bytes
< HTTP/1.1 400 Bad Request
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Date: Wed, 08 Jan 2014 08:24:31 GMT
< Content-Type: application/json
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
* Server GSE is not blacklisted
< Server: GSE
< Alternate-Protocol: 443:quic
< Transfer-Encoding: chunked
<
* Connection #0 to host accounts.google.com left intact
string(415) "HTTP/1.1 400 Bad Request
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Wed, 08 Jan 2014 08:24:31 GMT
Content-Type: application/json
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Alternate-Protocol: 443:quic
Transfer-Encoding: chunked
{
"error" : "invalid_token"
}"
Can you check if you are putting the client_secret in {} in the POST Body?
grant_type=urn:ietf:params:oauth:grant-type:migration:oauth1&client_id=xxxxxxx.apps.googleusercontent.com&client_secret={xxxxxxx}
You will also need to put {} around the client_secret value when you are generating the oauth_signature
We have made a few changes to the validation pieces of the OAuth1->OAuth2 token migration. Would you mind checking your migration flows again and updating this thread with the results?