As I know, when a POST request has been submitted, it sends Header and Parameters to the web server and it gets the response.
I saw a Javascript Post request in a website that it returns a response, but when I send that Post request from my website, it returns error :
500 Internal Server Error
HEADERS
Connection: close
Content-Type: text/plain;charset=UTF-8
Date: Mon, 30 Nov 2015 15:03:52 GMT
Server: Apache/2.2.15 (CentOS)
Set-Cookie: JSESSIONID=47C9E12F87FC7345358782F6DA7C00E0; Path=/; HttpOnly
Transfer-Encoding: chunked
X-Frame-Options: SAMEORIGIN
BODY
Internal Server Error!
Any help would be appreciated.
Related
i am using the google calendar api to write events to my organization's calendar, but i cannot figure out how to refresh the access token so that my program can use the calendar for more than an hour at a time.
to recreate the error:
generate oauth client id and client secret from your project's google cloud console
select calendar and calender.events scope at https://developers.google.com/oauthplayground
exchange the Authorization Code generated by Google's OAuth Playground for a refresh token and a temporary access token
list https://developers.google.com/oauthplayground as a valid redirect uri for your client on your project's cloud console
attempt to refresh your access token using your client id and client secret from your cloud console
THE PROBLEM
Google's OAuth playground access token expires after 3600s (1hr). I am able to refresh the access token using google's stand-in client credentials, but when I try to make the request (either from the playground itself or from postman), I am met with the following error message
{
"error_description": "Unauthorized",
"error": "unauthorized_client"
}
I have verified that the oauth playground is listed as a valid redirect uri for my client in the cloud console. I have also compared my POST request to the one google sends when refreshing the access token with placeholder credentials to ensure that I am sending all necessary params.
REQUESTS/RESPONSES
POST request on Oauth playground using google's default client credentials
POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-length: 223
content-type: application/x-www-form-urlencoded
user-agent: google-oauth-playground
client_secret=************&grant_type=refresh_token&refresh_token=1%2F%2F04qg5N0zhIRbPCgYIARAAGAQSNwF-L9IrTEZny7y_4wpbjLUh7ImtWRu473AQeTG3NG49ogQVzDZJe99BnS1TwFjwX7S2mNbLOYQ&client_id=407408718192.apps.googleusercontent.com
Response from Google's oauth playground when making the above request
HTTP/1.1 200 OK
Content-length: 385
X-xss-protection: 0
X-content-type-options: nosniff
Transfer-encoding: chunked
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Vary: Origin, X-Origin, Referer
Server: scaffolding on HTTPServer2
-content-encoding: gzip
Pragma: no-cache
Cache-control: no-cache, no-store, max-age=0, must-revalidate
Date: Wed, 31 Aug 2022 22:13:53 GMT
X-frame-options: SAMEORIGIN
Alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
Content-type: application/json; charset=utf-8
{
"access_token": "ya29.a0AVA9y1sTkPpmJIHvIBNODwdXr36hzumPEmoJGFBB1y29SZVwiE_QBy7RuTjDNzPkKyBOJ7RD1LBceTooeUZuNl-wN5dkyqsjFF5ynMkcShwG_yADXazPUFXngsSGuW_WRuVR01s9FOnv2N5gzkPldvQEtLaZaCgYKATASAQASFQE65dr8ZDuFe5BQyBG8ostdxK5ObQ0163",
"scope": "https://www.googleapis.com/auth/calendar.events https://www.googleapis.com/auth/calendar",
"expires_in": 3599,
"token_type": "Bearer"
}
POST request to google's Oauth playground using MY client credentials
POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-length: 279
content-type: application/x-www-form-urlencoded
user-agent: google-oauth-playground
client_secret=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&grant_type=refresh_token&refresh_token=1%2F%2F04qg5N0zhIRbPCgYIARAAGAQSNwF-L9IrTEZny7y_4wpbjLUh7ImtWRu473AQeTG3NG49ogQVzDZJe99BnS1TwFjwX7S2mNbLOYQ&client_id=804898855072-r91v64ojblf83if1pe9f8vr4mumubecc.apps.googleusercontent.com
Response from Google's oauth playground when making the above request
HTTP/1.1 401 Unauthorized
Content-length: 75
X-xss-protection: 0
X-content-type-options: nosniff
Transfer-encoding: chunked
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Vary: Origin, X-Origin, Referer
Server: scaffolding on HTTPServer2
-content-encoding: gzip
Pragma: no-cache
Cache-control: no-cache, no-store, max-age=0, must-revalidate
Date: Wed, 31 Aug 2022 22:16:15 GMT
X-frame-options: SAMEORIGIN
Alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
Content-type: application/json; charset=utf-8
{
"error_description": "Unauthorized",
"error": "unauthorized_client"
}
Any guidance is greatly appreciated. Google seriously needs some better docs!
unauthorized_client
Normally means that the client id and client secrete you are using with a refresh token is not the client id and client secret that were used to create it.
You should not be using playground to create tokens. You should be creating them in your app and refreshing them in your app.
Remember you can not refresh an token using a client side language. I am not a reactJs dev so if this is running client side that could also be the cause of your error. Use a server sided language.
Yes, another question about httpOnly Cookies.
Like a lot of other people, i'm stuck at the same place.
I get the cookie from the server but it is never sent with other requests.
I have mysite.example.com in angularjs trying to connect to api.example.com.
Here is the response headers:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://mysite.example.com
Connection: keep-alive
Content-Length: 2855
Content-Type: application/json
Date: Wed, 09 Jun 2021 00:52:54 GMT
Server: Apache/2.4.46 (Amazon) OpenSSL/1.0.2k-fips
Set-Cookie: WEB-TOKEN=158b691a-65fb-49c2-9d88-63bd1935531f;Version=1;Comment=;Max-Age=3600;Secure;HttpOnly;Expires=Wed, 09 Jun 2021 00:52:54 GMT
vary: Origin
Then, in AngularJS, i send a request like this (from mysite.example.com):
$http.get('https://api.example.com/userdetails', { withCredentials: true, headers: { } });
Is there anything not sent or just wrong?
Thank you!
The Path. Yes. I was missing the Path to %x2F. :)
We have the following configuration:
testing.parentdomain.com
When you access this domain and create a basket we create a cookie stored for the basket value. The cookie domain is set to .testing.parentdomain.com, it is Httponly and has a path of /
We have a subdomain to the above which would like to access the cookie. subdomain.testing.parentdomain.com
This sub domain makes a call to an endpoint on the parent domain such as: testing.parentdomain.com/basketData. This call is a GET request that returns JSON.
Issue
The issue is that the subdomain does not appear to send the cookie value when making the request and therefore we do not get the expected response.
Attempts
Looking at other questions we have tried CORS and credential changes.
As an additional note, we bundle the below JS with webpack/babel.
Our request is from AJAX as follows:
$.ajax({
url: url,
type: 'GET',
xhrFields: {
withCredentials: true
},
crossDomain: true
})
The server is setup with CORS for the subdomain and allow-crendtials. In the response we can see these are returned.
access-control-allow-credentials: true
access-control-allow-origin: subdomain from above
Is there any reason that the cookie is not sent with the request to the parent domain? We have logged out the cookies on the server side response and they are not there as we expect.
Request Headers
:authority: testing.parentdomain.com
:method: GET
:path: /basket/data/
:scheme: https
accept: /
accept-encoding: gzip, deflate, br
accept-language: en-GB,en;q=0.9,en-US;q=0.8
origin: https://subdomain.testing.parentdomain.com
referer: https://subdomain.testing.parentdomain.com/
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-site
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36
Response Headers
access-control-allow-credentials: true
Access-Control-Allow-Methods: GET, PUT, POST, DELETE, HEAD, OPTIONS
access-control-allow-origin: https://subdomain.testing.parentdomain.com
cache-control: no-cache, no-store
content-length: 2238
content-type: application/json; charset=utf-8
date: Tue, 03 Nov 2020 20:39:36 GMT
expires: -1
pragma: no-cache
server: Microsoft-IIS/10.0
set-cookie: AWSALB=N0bcThdgRFzrSfQVNIsffgsvY6T/y2Bp47RZJCueeSLOS7eEjo0AThiElXmww6fy2eynRyyt8gAB8di/Mqy1x+Ds8Ig1TumKkWnQiFvIkoELI/rEYYgyUxbEtUI4; Expires=Tue, 10 Nov 2020 20:39:36 GMT; Path=/
set-cookie: AWSALBCORS=N0bcThdgRFzrSfQVNIsffgsvY6T/y2Bp47RZJCueeSLOS7eEjo0AThiElXmww6fy2eynRyyt8gAB8di/Mqy1x+Ds8Ig1TumKkWnQiFvIkoELI/rEYYgyUxbEtUI4; Expires=Tue, 10 Nov 2020 20:39:36 GMT; Path=/; SameSite=None; Secure
status: 200
strict-transport-security: max-age=31536000;
vary: Origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-robots-tag: noindex
x-ua-compatible: IE=edge
x-xss-protection: 1; mode=block
Even if you are calling the main domain from a subdomain, this is considered a cross-origin request.
Quote from the RFC 6454 which qualifies the "Origin" term:
Q: Why use the fully qualified host name instead of just the "top-
level" domain?
A: Although the DNS has hierarchical delegation, the trust
relationships between host names vary by deployment. For example, at
many educational institutions, students can host content at
https://example.edu/~student/, but that does not mean a document
authored by a student should be part of the same origin (i.e.,
inhabit the same protection domain) as a web application for managing
grades hosted at https://grades.example.edu/.
So all of the things you did are indeed required to make it work:
access-control-allow-credentials: true
access-control-allow-origin: subdomain.testing.parentdomain.com (not a wildcard)
withCredentials: true in the request
The SameSite=None cookie attribute is not required in this case because a request from a subdomain to another subdomain of the same domain is considered "same site" (Source).
So just check that everything is correctly set, it should work as is.
At beginning of your question you stated:
The cookie domain is set to .testing.parentdomain.com
but in the logged server response:
set-cookie: AWSALBCORS=N0bcThdgRFzrSfQVNIsffgsvY6T/y2Bp47RZJCueeSLOS7eEjo0AThiElXmww6fy2eynRyyt8gAB8di/Mqy1x+Ds8Ig1TumKkWnQiFvIkoELI/rEYYgyUxbEtUI4; Expires=Tue, 10 Nov 2020 20:39:36 GMT; Path=/; SameSite=None; Secure
the Domain=.testing.parentdomain.com; parameter is clearly missing.
I don't know which programming language you are using to set the cookie, but I strongly suggest you to check the call you use to set the cookie in your server response.
I'm use urllib craw a https web,
the response_header are:
HTTP/1.1 200 OK
Cache-Control: max-age=0
Content-type: application/octet-stream
Transfer-Encoding: chunked
Date: Wed, 07 Nov 2018 07:01:00 GMT
Server: lighttpd
response data are:
response data
The web display are:
response display
I know the content type application/octet-stream are not general encoding,but there must be some web js decode those response data,Does anyone know how to find the decode code from the web js or find out which web js file use the response data
I send ajax post request to server and respond with 302 redirect. All browsers follow this redirect except IE. I see in Network tab of IE dev tools that 302 response is received.
Also jQuery .fail(function(jqXHR, textStatus) {...}) callback return the following data in jqXHR:
[object Object]{readyState: 0, status: 0, statusText: "error"}
Which is strange because status is not 302.
Testing on IE 11.
EDIT
Response headers:
Response HTTP/1.1 302 Found
Date Tue, 27 Oct 2015 12:24:47 GMT
Server Apache/2.4.10 (Debian) PHP/5.6.7-1
X-Powered-By PHP/5.6.7-1
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache
X-Redirect http://mysiteaddress.com/somepage/
Set-Cookie PHPSESSID=123; path=/; HttpOnly
Content-Length 0
Keep-Alive timeout=15, max=96
Connection Keep-Alive
Content-Type text/html; charset=UTF-8
EDIT2 I guess it's Yii2 framework-specific bug. Client script must handle X-REDIRECT header, but can't do this in IE. See: http://www.yiiframework.com/doc-2.0/yii-web-response.html#redirect()-detail.
It's Yii2 specific bug/behaviour when you use yii\web\Response::redirect() method.
Everything seem to work fine if you return code 200 instead of proper redirection code 302.
See:
http://www.yiiframework.com/doc-2.0/yii-web-response.html#redirect()-detail and
https://github.com/yiisoft/yii2/issues/9670