I am stuck with this error.
I just successfully received an authorization code and I am trying to exchange it for an access token, but I get the error message "invalid_request".
I am using Apache HttpComponents library (current version) for the request, and there the UrlEncodedFormEntity as I am making a post request.
Here is my request information:
Request body: scope=&client_secret=[my_secret]&grant_type=authorization_code&redirect_uri=http%3A%2F%2Fmydomain.org%3A8080%2F[some parameters etc...]%3FplatformID%3D3&client_id=23[...]-rg[...].apps.googleusercontent.com&code=[my_encoded_authorizationCode]
Request-URL: https://accounts.google.com/o/oauth2/token
Request-Method: POST
Request headers --
User-Agent = MAC: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.25 (KHTML, like Gecko) Version/6.0 Safari/536.25 // this is a fake user agent I have set by the header manipulation
Content-Type = application/x-www-form-urlencoded
Response headers --
Cache-Control = no-cache, no-store, max-age=0, must-revalidate
Pragma = no-cache
Expires = Fri, 01 Jan 1990 00:00:00 GMT
Date = Sun, 02 Dec 2012 11:44:34 GMT
Content-Type = application/json
X-Content-Type-Options = nosniff
X-Frame-Options = SAMEORIGIN
X-XSS-Protection = 1; mode=block
Server = GSE
Transfer-Encoding = chunked
Response:
{
"error" : "invalid_request"
}
Any help?
I am stuck for days, researching and implementing other OAuth2-protocols, but Google's one does not work...
Best greetings and thanks,
Martin Bories
Related
I'm trying to cache a menu on my page that is being called and rendered on every page of the application. I'd like the server to return a new menu only if the user is stale (I update the user object when the user accesses a different part of the site)
The Javascript call to get the menu is:
$.ajax({
url: slideMenuPath,
method: 'get',
cache: true,
ifModified: true,
success: function(response) {
$('#left-nav-container').html(response);
}
});
And the Server-side code is as follows:
def index
latest_user = User.find(session.user_id)
if stale?(etag: latest_user, last_modified: latest_user.updated_at)
#menu_info = Menu.new(latest_user)
render partial: 'navigation/menus/slide_out', layout: false
end
end
What I am seeing happening is a bit bizarre. The first time the user accesses the site it loads the menu via Menu.new() (expected), and then every page that is hit it does not do the Menu.new() (again expected) and renders the cached version of the menu in the browser.
The problem I am seeing though is that when the User object is updated, the Menu.new is then called as expected, but then every page load after that calls the Menu.new for a minute or so and then starts caching the response.
The behaviour almost acts like the last_modified and updated_at comparison doesn't account for seconds and makes sure the updated_at is < last_modified and not <=, with the timestamp being in minutes.
What's even more confusing is that I am always getting a 200 back, not a 304 on the cached responses.
Bottom line is that the site is working, but the caching isn't really working for a minute or so after the User object is updated. Any help would be appreciated!
Additional details:
Here is the raw request:
GET /ben_admin/menus/slide_out?current_url=%2Fben_admin%2Fwork_status_events%2Flist HTTP/1.1
Host: localhost:3000
Connection: keep-alive
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
Accept: /
X-CSRF-Token: CtWkubye++oI7AU3xSjSeD2Z4mmRO9jC74kKhzT2evA2jwmD+Z578+4b2778/rRpex/hHqIZIlGha9XY/FQ0Rg==
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36
X-Requested-With: XMLHttpRequest
sec-ch-ua-platform: "macOS"
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: http://localhost:3000/ben_admin/work_status_events/list
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,es;q=0.8
Cookie: external_logon_page=; _session_id=6c6f1228d24a863228d1e3275c16888a; _device_id=LzhmZGtDZ0NBNGc4Y0ZlTmhMenhTby9sQWFzd3pibVJIUTBYS0c4UWtTSTBjNSt6L2k3OW1DU1BXUC8yQWlZdS9GRGNsTUMwaUVCcW1wVHQzMmZ6NGI0M3RVUGtnL01rZ0RWV2FqQys1aE09LS1lcFBkdzhldUh6aVVNT242QVpmTXpnPT0%3D--12816efa203b8f8788844830a6c9589f0f2add1a
If-None-Match: W/"709672ed9c25fd368b4ab51f83a2a690"
If-Modified-Since: Mon, 03 Jan 2022 16:31:21 GMT
Here is the response: (with a 200)
Cache-Control: max-age=0, private, must-revalidate
Content-Encoding: gzip
Content-Security-Policy: default-src http: ws: 'self' http://0.0.0.0:8080 'unsafe-inline' 'unsafe-eval'; style-src 'self' http://0.0.0.0:8080 'unsafe-inline'
Content-Type: text/html; charset=utf-8
ETag: W/"960d12d5161594dcb1572e39e797b38b"
Last-Modified: Mon, 03 Jan 2022 19:12:13 GMT
Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
Set-Cookie: _device_id=; path=/; expires=Fri, 03 Jan 2042 19:29:57 GMT; HttpOnly; SameSite=Lax
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: ALLOWALL
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: 88100f73-c264-45a6-a42a-1b0fde01bf12
X-Runtime: 5.397817
X-XSS-Protection: 1; mode=block
I am on Rails 4 and learning http caching from here https://devcenter.heroku.com/articles/http-caching-ruby-rails
I am trying to set cache-control header with rails expires_in method. please see this link https://devcenter.heroku.com/articles/http-caching-ruby-rails#time-based-cache-headers
i am able to set cache-control value to max-age = 180. however when i refresh my web page again within 180 seconds after previous http request the request is hit to the rails entire stack again. i was expecting rails to return 305 not modified response because the cache-control header max-age value is set to 180 seconds.
Request headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:_demo_app_session=elhZMUpaQkNJRGlwZG00R24vTEpyaWgzWCswckJ3eFU5bGFkM2lleGF3dDZOcnd1YXlyanNhY2lYb1pUTWJIZU4wK1FUNlRKWDh3LzVlamR0eUJrUFJ4c3UveFFyWVNWUHNCVHBGeGtYWTg2MmFmVnFTdU85TG96Vk5UOE5MMXFXWHBQYld0OTIxSFVId3lGZzdPSDVnPT0tLU5FZEhGbkppa0tkL0FQYkRYU0xPTUE9PQ%3D%3D--f8d61e1b9dd668b366e14271ac8412cb2579945a
Host:localhost:3000
If-None-Match:W/"bae944fae4d6e7f37fceeb0e4dd272c8"
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.101 Safari/537.36
Name
Path
Response headers
Cache-Control:max-age=120, public
Connection:Keep-Alive
Content-Length:3188
Content-Type:text/html; charset=utf-8
Date:Thu, 14 Apr 2016 17:39:08 GMT
Etag:W/"946d51d48e02b01a99af19862d2afc3e"
Server:WEBrick/1.3.1 (Ruby/2.2.1/2015-02-26)
Set-Cookie:_demo_app_session=TjFxZWlrT3hacFhhUEp0SXpTb3drNG9SeWZranV6TFlyc0dtRFpWUDFlRkY3eU90aEJPZTZNUmRlTThxQnF4SUxxM1g5QjVSUUxWYlUrd3NUbGxna0o0bHVMeXVHN0tiNUlSN2hndFE3a0U2Y28yemhzWUgzMWJIWCsyS0t2WFlLSWdmSWNuV0txVVJUYzhMZlA2eGRnPT0tLUhIZ1dHVkVZd05URFY2Y3ArQVBMU2c9PQ%3D%3D--f6bc45cb12c14978ed5df4ea3b136b80cb4cecaf; path=/; HttpOnly
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Request-Id:bafba51d-480e-4597-9c1a-56785fdc4704
X-Runtime:0.013116
X-Xss-Protection:1; mode=block
Am i missing something here??
I have a very strange behavior in my MVC 5 application. This only happens when the connection is a mobile connection like 3G or GPRS. On a Wifi connection all works well.
The application is hosted on iis 7.5. It uses Form authentication. The app is developed in .Net 4.5 MVC 5.
In my view I use Razor html helpers and it seems that IIS cache the views with these helper values and if the connection is slow like GPRS it renders these cached views with the wrong values.
One example is:
#System.Web.HttpContext.Current.User.Identity.Name
In my _Layout view I use the #System.Web.HttpContext.Current.User.Identity.Name to display the username in the right corner of the site:
<span>
<img class="StatusImage" src='#Url.Content("~/Content/images/User16.png")' />
#System.Web.HttpContext.Current.User.Identity.Name
</span>
If the connection is slow, IIS renders a other username than what the user logged in with.
Another obscure example is a situation where we display project names as buttons. These buttons are dynamically created according to data in the database.
#foreach (var item in Model.List)
{
<div>
<a class="linkButtonLarge" href="#Url.Action("ProjectIndex", "AssetCapture", new { ProjID = #item.ID })" >
<img src="~/Content/images/ProjectItem.png" />#item.Name
</a>
</div>
}
So if there are three items in the list, then three buttons will be displayed, each one with its unique href.
When a button is clicked the URL request will be for instance
http://www.example.com/AssetCapture/ProjectIndex/?ProjID=PROJ1
The controller Action rendering the view looks like this:
public ActionResult ProjectIndex(string ProjID)
{
ModelState.Clear();
Models.ProjectModel model = new Models.ProjectModel();
model.SelectedProject = ProjID;
return View("ProjectIndex", model);
}
On a slow connection like GPRS the value #Model.SelectedProject is not always correct in the view that is rendered.
Lets say the user clicked on the button with value "PROJ1" the URL in the URL box will show up as
http://www.example.com/AssetCapture/ProjectIndex/?ProjID=PROJ1
but #Model.SelectedProject will show "PROJ2" when the page is rendered. It seems like a other user selected "PROJ2" previously and that view was cached. Now that the user on a poor connection try to access the same view with a different parameter "PROJ1" it renders the cached version of "PROJ2".
I think it is an IIS issue, but it could be something else. If anyone can help I would really appreciate it.
EDIT
Here is the Request Header when connected through Wi-Fi:
GET http://www.ams360-tlokwe.co.za/AssetCapture/ProjectIndex/?ProjID=PROJ2 >HTTP/1.1
Host: www.ams360-tlokwe.co.za
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.101 Safari/537.36
Referer: http://www.ams360-tlokwe.co.za/AssetCapture/Project/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Cookie: ASP.NET_SessionId=oonansf0eotsv1z13ey2ukkr; AspxAutoDetectCookieSupport=1; .ASPXAUTH=60026C569909566F84B004A4E06671ED9ECA88F279D25E55D7A283A7E732D6E50EE5B0401C1D3EE2BDF5A9F828CD5B56891C2EB0C05BE007F3D43DBD7923D5D384AE59C16EE8043766176F46162387073090F344E2CB799843FED12946ADE1E90D8F978E1DDEC91997E618655B4D520EE0DE467C52DD905C000C4C7B0C8C2558
And here is the Request Header when connected through the Mobile Connection:
GET http://www.ams360-tlokwe.co.za/AssetCapture/ProjectIndex/?ProjID=PROJ2 HTTP/1.1
Host: www.ams360-tlokwe.co.za
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.101 Safari/537.36
Referer: http://www.ams360-tlokwe.co.za/AssetCapture/Project/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Cookie: ASP.NET_SessionId=oonansf0eotsv1z13ey2ukkr; AspxAutoDetectCookieSupport=1; .ASPXAUTH=60026C569909566F84B004A4E06671ED9ECA88F279D25E55D7A283A7E732D6E50EE5B0401C1D3EE2BDF5A9F828CD5B56891C2EB0C05BE007F3D43DBD7923D5D384AE59C16EE8043766176F46162387073090F344E2CB799843FED12946ADE1E90D8F978E1DDEC91997E618655B4D520EE0DE467C52DD905C000C4C7B0C8C2558
They are exactly the same.
Response Headers
From a WiFI connection:
HTTP/1.1 200 OK
Cache-Control: public, no-store, max-age=0, s-maxage=0
Content-Type: text/html; charset=utf-8
Expires: Mon, 30 Mar 2015 07:18:51 GMT
Last-Modified: Mon, 30 Mar 2015 07:18:51 GMT
Vary: *
Server: Microsoft-IIS/7.5
Access-Control-Allow-Origin: *
X-AspNetMvc-Version: 5.2
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 30 Mar 2015 07:18:51 GMT
Content-Length: 136803
And from the Mobile Connection
HTTP/1.1 200 OK
Vary: User-Agent
Cache-Control: public, no-store, max-age=0, s-maxage=0
Content-Type: text/html; charset=utf-8
Expires: Mon, 30 Mar 2015 07:20:09 GMT
Last-Modified: Mon, 30 Mar 2015 07:20:09 GMT
Vary: *
Server: Microsoft-IIS/7.5
Access-Control-Allow-Origin: *
X-AspNetMvc-Version: 5.2
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 30 Mar 2015 07:20:09 GMT
Content-Length: 54498
EDIT2
The Response Header is actually different when on a mobile (3G) connection. It returns with a Transfer-Encoding: chunked mode.
Fiddler gives you an option
Response is encoded and may need to be decoded before inspection.Click here to transform
If I click on this the response header change from
Transfer-Encoding: chunked mode
to
Content-Length: 54498
I'm working on an AngularJS project, and I need to perform a cross-domain (CORS) POST.
It took me a (long) while to get it working, and well, it now sort of work:
The pre flight (OPTIONS) request is sent correctly, and my server
responds to it correctly as well.
The actual POST request is sent
correctly as well, my server receives it all right, and returns a 201
(created) response as it should.
So what is the problem?
Well the Angular $http object doesn't then go to the "success" callback, but to the "error" callback instead... with a status code of 0 and no specific error.
So from my page, I have no way to know if my request actually worked. The only way I know that it does work is by controlling (debugging) the server and using Fiddler.
Did anybody run into this problem before? It's a bit frustrating to have a working solution but not being able to tell that it actually worked :)
Here is my $http request:
this.simulate = function (url, content) {
var deferred = $q.defer();
var data = { "Data": content, "Timestamp": new Date() };
$http.defaults.useXDomain = true;
$http.post(url, data)
.then(function(response) {
deferred.resolve({
isSuccess: true,
httpCode: response.status,
errorMessage: "",
url: url,
data:data
});
},function(response) { // This is this error callback that is being called, despite the fact that my request is working fine...
deferred.resolve({
isSuccess: false,
httpCode: response.status,
errorMessage: response.data.Message + " " + response.data.ExceptionMessage,
url: url,
data: data
});
});
return deferred.promise;
};
In fiddler, this is what I get:
The pre-flight request:
OPTIONS http://myServer:82/xclient/event/volupdate HTTP/1.1
Host: myServer:82
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://myClient:1855
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36
Access-Control-Request-Headers: accept, origin, x-requested-with, authorization, ssotoken, content-type
Accept: */*
DNT: 1
Referer: http://myClient:1855/XClient/testharness/eventing
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,fr-FR;q=0.4
Which gives me that pre-flight response:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Server: Microsoft-IIS/7.5
Access-Control-Allow-Origin: http://myClient:1855
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: accept, origin, x-requested-with, authorization, ssotoken, content-type
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 07 Aug 2013 10:13:05 GMT
Content-Length: 0
And then this is followed by the actual POST request:
POST http://myServer:82/xclient/event/volupdate HTTP/1.1
Host: myServer:82
Connection: keep-alive
Content-Length: 56
Origin: http://myClient:1855
Authorization: SSOB2L1ax<BLAHBLAHBLAH>EP49w=|0|jaussan|System X|20130825131712|1748001|
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36
Content-Type: application/json;charset=UTF-8
Accept: application/json, text/plain, */*
X-Requested-With: XMLHttpRequest
DNT: 1
Referer: http://myClient:1855/XClient/testharness/eventing
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6,fr-FR;q=0.4
{"Data":"SomeData","Timestamp":"2013-08-07T10:13:06.533Z"}
And then followed by a normal 201 created response to the POST:
HTTP/1.1 201 Created
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 07 Aug 2013 10:13:05 GMT
Content-Length: 0
As you can see everything seems normal, but yet $http seems to think it's not.
Here are a few screenshots from Firebug:
$http goes to the wrong callback:
And this is the response I'm getting from $http... not really my 201!:
It appears as if your server is handling the OPTIONS (preflight) request correctly, but not the actual POST request. Your server needs to at least include an Access-Control-Allow-Origin header in the response to your POST request. In your case, that would be: Access-Control-Allow-Origin: http://myClient:1855.
For future reference, there is an excellent article about CORS that everyone who has to support a cross-origin environment should absolutely bookmark: MDN on HTTP access control.
I have some static content on my web site that I have set up caching for (using Asp.NET MVC). According to Firebug, the first time I open the page, Firefox sends this request:
GET /CoreContent/Core.css?asm=0.7.3614.34951
Host: 127.0.0.1:3916
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/css,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://127.0.0.1:3916/Edit/1/101
Cookie: .ASPXAUTH=52312E5A802C1A079E2BA29AA2BFBC5A38058977B84452D62ED52855D4164659B4307661EC73A307BFFB2ED3871C67CB3A9AAFDB3A75A99AC0A21C63A6AADE9A11A7138C672E75125D9FF3EFFBD9BF62
Pragma: no-cache
Cache-Control: no-cache
Which my server replies to with this:
Server: ASP.NET Development Server/9.0.0.0
Date: Mon, 23 Nov 2009 18:44:41 GMT
X-AspNet-Version: 2.0.50727
X-AspNetMvc-Version: 1.0
Cache-Control: public, max-age=31535671
Expires: Tue, 23 Nov 2010 18:39:12 GMT
Last-Modified: Mon, 23 Nov 2009 18:39:12 GMT
Vary: *
Content-Type: text/css
Content-Length: 15006
Connection: Close
So far, so good. However, if I refresh Firefox (not a cache-clearing refresh, just a normal one), during that refresh cycle Firefox will once again go to the server with this request:
GET /CoreContent/Core.css?asm=0.7.3614.34951
Host: 127.0.0.1:3916
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/css,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://127.0.0.1:3916/Edit/1/101
Cookie: .ASPXAUTH=52312E5A802C1A079E2BA29AA2BFBC5A38058977B84452D62ED52855D4164659B4307661EC73A307BFFB2ED3871C67CB3A9AAFDB3A75A99AC0A21C63A6AADE9A11A7138C672E75125D9FF3EFFBD9BF62
If-Modified-Since: Mon, 23 Nov 2009 18:39:20 GMT
Cache-Control: max-age=0
to which my server responds 304 Not Modified.
Why does Firefox issue this second request? In the first response, I said that the cache does not expire for a year (I intend to use query parameters whenever things change). Do I have to add another response header to prevent this extra roundtrip?
Edit: It does not matter whether I press refresh, or whether I go to the page again (or a different URL, which references the same external files). Firefox does the same again. Also, I don't claim this to be a bug in FF, I just wonder if there is another header I can set which means "This document will never change, don't bother me again".
This behavior seems to be "by design" for all modern browsers. In IE you can investigate the same situation. Hitting F5 always causes browser to check whether content was modified. During cache-clearing request browser do not pass Last-Modified header and server must return HTTP 200 (not HTTP 304), so 304 in your situation is not so bad.
Apparently, the issue was due to a Vary: * header being added to the response. To remove this in Asp.Net, add this to web.config inside the <system.web> section:
<caching>
<outputCache omitVaryStar="true"/>
</caching>
To me it seems this switch is "yes, I want a working behaviour rather than a non-working one", but once you find it, flipping it is trivial.