I have a page on localhost:4000 that has a cookie set by the server.
The page also contains a script that successfully makes an XHR request back to the server upon the page loading. This XHR request response sets a second cookie. I can only see the non-XHR cookie in Chrome devtools under Application (tab) > Storage (menu group on left) > Cookies > http://localhost:4000.
I can see the XHR cookie returned from the server in the Network tab (which if the page is loaded a second time shows both the non-XHR and XHR cookies are correctly included in the XHR request:
Request Cookies
xhr_cookie valueABC
from_homepage value123
Response Cookies
xhr_cookie valueABC
So the XHR cookie is being persisted somewhere but I can't see it in Chrome's devtools.
Not the answer for Chrome but a work around is to use Firefox and enable the Storage "inspector" from the gear wheel on the web developer pane.
https://developer.mozilla.org/en-US/docs/Tools/Storage_Inspector
Same Origin request were fine.
Cross origin request has some limitations.
File:1.php:
<?php
setcookie("cookie_name_1", "cookie_value_1", time() + (86400 * 30), "/");
?>
<script>
var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://foo.ir/2.php', true);
xhr.withCredentials = true;
xhr.onreadystatechange = function() {
if(this.readyState == xhr.DONE) {
get_res();
}
}
xhr.send(null);
function get_res(){
var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://foo.ir/2.php?is_set', true);
xhr.withCredentials = true;
xhr.onload = function () {
if (xhr.readyState === xhr.DONE) {
if (xhr.status === 200) {
console.log(xhr.responseText);
}
}
};
xhr.send(null);
}
</script>
File:2.php
<?php
header('Access-Control-Allow-Origin: http://localhost');
header('Access-Control-Allow-Credentials: true');
if(isset($_GET["is_set"])){
if(isset($_COOKIE["cookie_name_2"]))
echo "cookies are set:".$_COOKIE["cookie_name_2"];
else
echo "cookies not set";
}else
setcookie("cookie_name_2", "cookie_value_2", time() + (86400 * 30), "/");
?>
Cross-origin cookies are working:You need to allow third party cookies to be set in
browser setting
I couldn't find where third party cookies are stored.
Chrome Won't show cookies and wont effect the real website.
Firefox & Edge save cookies in the third party website storage thus it will effect real third party website.
More information can be found on Here
According to the XMLHttpRequest Level 1 and XMLHttpRequest Level 2,
this particular response headers falls under the "forbidden" response
headers that you can obtain using getResponseHeader(), so the only
reason why this could work is basically a "naughty" browser
This should show up as a seperate "Cookies" tab when you inspect the XHR request. It's easy to miss because the tab only shows when withCredentials is set to true.
In Chrome, disable "Site isolation":
Go to 'chrome://flags/#site-isolation-trial-opt-out
Set Disable site isolation to Disabled
Relaunch
For further details see: https://blog.ermer.de/2018/06/11/chrome-67-provisional-headers-are-shown
Related
I have written this simple javascript code to perform a get request on my github repository
var url='https://github.com/mypath/AjaxPractice/myFile.json';
myBtn.addEventListener('click', function(){
let XHR = new XMLHttpRequest();
XHR.open('GET', url, true)
XHR.setRequestHeader('Access-Control-Allow-Origin','*');
XHR.onload = function() {
if (this.status === 200) {
console.log(JSON.parse(this.responseText));
}
}
XHR.send();
});
However I get this error message:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://github.com...(Reason: CORS header 'Access-Control-Allow-Origin' missing).
What is missing here?
If a correct request is not allowed because of CORS , you have no options other than use something something like CORS-ANYWHERE here: https://github.com/Rob--W/cors-anywhere
This is how I managed to do it:
Go to your github repo and click on settings
Scroll down to where it says source and change it from none to master branch.
Note: the example I used didnt require XHR.setRequestHeader('Access-Control-Allow-Origin','*');
I'm trying to login from one of my servers to another in order to send cross-origin requests that requires being logged. is it possible?
I have two web servers, A and B. Lets say www.a.com and www.b.com.
B has an API that can be used only if the client is logged in. I need to use that API from A clients.
So, I send from A client an ajax (post) login request to B. B responses with CORS headers, the session cookie and a successful redirection to B's home/index.
But when I make a second ajax request (jsonp request) from A client to B server, this request doesn't send the previous session cookie received, therefore the login request failed.
If I login to www.b.com manually (in a second browser tab), all requests from A to B are successful detected as a logged user, so, the B API works from A.
I think that the session cookie received from my login requests is not being saved to the browser.
This is my login request:
$.post("www.b.com/login", { 'j_username': 'username', 'j_password': 'password' } );
Using:
jqXHR.withCredentials = true;
settings.crossDomain = true;
Response headers:
Access-Control-Allow-Headers:x-requested-with
Access-Control-Allow-Methods:POST, GET, OPTIONS
Access-Control-Allow-Origin:*
...
Location:http://www.b.com/home
...
Set-Cookie:JSESSIONID=tY++VWlMSxTTUkjvyaRelZ0o; Path=/
The cookie received is being saved to www.a.com or to www.b.com? How can I set this cookie to www.b.com from an A client ajax request? I think that is the problem.
As apsillers said, we can't use the wildcard Access-Control-Allow-Origin:*.
But this doesn't solved the problem.
I was setting jqXHR.withCredentials = true; inside a beforeSend handler function.
$.post({
...
beforeSend: function(xhr) {
xhr.withCredentials = true;
},
...
});
And for some reason, this doesn't work. I had to set the use of credentials directly:
$.post({
...
xhrFields: {
withCredentials: true
},
...
});
This code works perfectly !
Thanks you.
I'm trying to do a ajax call between a server (http) that is on internet. And target that to my own localhost. FF/Chrome/ ETC... works. It's ONLY an IE issue. IM USING IE 11 AND 10.
The request is don't even done. The "denied access" is thrown instantly.
This is the code. Just for you to see.
Is not the classical HTTP/HTTPS error in IE8 AND IE9. This is something else, but the documentation is not helpful.
$jq.ajax({
contentType: 'application/json',
url: url,
dataType: 'json',
crossDomain: true,
beforeSend: function (xhr) {
xhr.withCredentials = true;
xhr.setRequestHeader("Authorization", "Basic " + $jq.base64.encode(username and password));
},
success: function (data, status, headers) {},
error: function (xhr, status, error) {}
The status is 0 in xhr object and error is "Denied access"
Internet Explorer raises this error as part of its security zones feature. Using default security settings, an "Access is Denied" error is raised when attempting to access a resource in the "Local intranet" zone from an origin in the "Internet" zone.
If you were writing your Ajax code manually, Internet Explorer would raise an error when you try to open the resource. For example:
var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://localhost/', true); // This line will trigger an error
xhr.send();
You can work around this error by adding the origin site to the "Trusted sites" security zone. You can test this by adding "http://client.cors-api.appspot.com" to your "Trusted sites" zone and using this test page at test-cors.org with your localhost site as the Remote URL.
In addition to the trusted site requirement I found that the problem was not fixed until I used the same protocol for the request as my origin, e.g. my test site was hosted on a https but failed with any destination using http (without the s).
This only applies to IE, Chrome just politely logs a warning in the debug console and doesn't fail.
If you are attempting to make cross-origin ajax requests in IE9, you'll need to use XDomainRequest instead of XMLHttpRequest. There is a jQuery plug-in that wraps XDR. You should be aware that there are some notable limitations of XDR.
Another option would be to use a library like this: https://github.com/jpillora/xdomain.
jQuery implements ajax calls using the XMLHttpRequest object which is not supported in IE9. You have to force it to use XDomainRequest instead.
I get around this problem using this jQuery plugin:
https://github.com/MoonScript/jQuery-ajaxTransport-XDomainRequest
Note:
Do not use "http://www.domain.xxx" or "http://localhost/" or "IP" for URL in Ajax.
Only use path(directory) and page name without address.
false state:
var AJAXobj = createAjax();
AJAXobj.onreadystatechange = handlesAJAXcheck;
AJAXobj.open('POST', 'http://www.example.com/dir/getSecurityCode.php', true);
AJAXobj.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded; charset=UTF-8');
AJAXobj.send(pack);
true state:
var AJAXobj = createAjax();
AJAXobj.onreadystatechange = handlesAJAXcheck;
AJAXobj.open('POST', 'dir/getSecurityCode.php', true); // <<--- note
AJAXobj.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded; charset=UTF-8');
AJAXobj.send(pack);
function createAjax()
{
var ajaxHttp = null;
try
{
if(typeof ActiveXObject == 'function')
ajaxHttp = new ActiveXObject("Microsoft.XMLHTTP");
else
if(window.XMLHttpRequest)
ajaxHttp = new XMLHttpRequest();
}
catch(e)
{
alert(e.message);
return null;
}
//-------------
return ajaxHttp;
};
I am redirecting every request to the same url in onBeforeRequest listener using redirectUrl directive. It works fine with all sites as Chrome eventually send the request to the url. But I am loosing an AJAX request for one site (the request is not sent at all, e.g. https://apiv2.abc.com/me?token=fiYoEdDLZxPJ...). If I replace return {redirectUrl: request.url}; with just return, everything is fine. Can I redirect every request to itself as the following? I tried this with and without requestHeaders permission. Your suggestions are needed please.
chrome.webRequest.onBeforeRequest.addListener(
function interceptRequest(request) {
if (request.tabId === -1) return;
console.log("In before request: " + request.requestId + ", URL: " + request.url);
return {redirectUrl: request.url};
}, {urls: ['*://*/*']}, ['blocking']);
I am getting status code 403 when I try to log in after successfully being logged in and logged out.
Client side is written in Angular and server side is in Django.
This goes as follows:
Client requests url '/' fetches main HTML template with all required static files ( angular, bootstrap, jQuery sources and angular sources defined by me) with
<div ng-view></div> tag into which further templates will be inserted.
Via $location service is redirected to url '/#/login'
This rule from $routeProvider is executed once '/#/login' is hit:
$routeProvider.when('/login', {
templateUrl: 'login.html'
});
'login.html' is served by django view and form for logging in is rendered to the user
User logs in successfully providing proper credentials
Then user logs out, by clicking on a button, which fires '$http.get(
'/logout/'
);' and then is redirected to url '/#/login'
Here is the problem. When user fills in credential form and sends 'POST' request, 403 is returned. I thought that it is, because this routing is done only by angular and since 'login.html' template has already been requested it has been catched and can be served without hitting backend, but after logging out currently possesed CSRF cookie is stale, so that's why I am getting 403. So I tried to remove that template:
logout: function(){
var forceLoginTemplateRequest = function(){
if( $templateCache.get('login.html') !== 'undefined'){
$templateCache.remove('login.html');
}
};
var responsePromise = $http.get(
urls.logout
);
responsePromise.success(forceLoginTemplateRequest);
return responsePromise;
}
After doing that I could see client side requesting 'login.html' template always after logging out, so I thought I could provide CSRF cookie when serving that template from backend:
#urls.py
urlpatterns = patterns(
'',
...
url(r'^$', serve_home_template),
url(r'^login.html$', serve_login_template),
url(r'^login/', login_view, name='login'),
url(r'^logout/', logout_view, name='logout'),
...
)
#views.py
#ensure_csrf_cookie
def serve_login_template(request):
return render(request, "login.html")
#ensure_csrf_cookie
def serve_home_template(request):
return render(request, 'home.html')
But still it doesn't work and I am getting 403 when trying to log in after logging out. The only way I managed it to work is to simply refresh the page so that every single file, whether template or source file is requested again from the backend and CSRF cookie is updated with them.
Here is my app's run section for making sure CSRF cookie is sent with every request:
mainModule.run(['$http','$cookies', '$location', '$rootScope', 'AuthService', '$templateCache',
function($http, $cookies, $location, $rootScope, AuthService, $templateCache) {
$http.defaults.headers.common['X-CSRFToken'] = $cookies.csrftoken;
$rootScope.$on( "$routeChangeStart", function(event, next, current) {
if ( !(AuthService.isLoggedIn() == "true")){
$location.path('/login');
}
});
}]);
This could be a cache problem. Try to add the never_cache decorator to all your views:
from django.views.decorators.cache import never_cache
...
#ensure_csrf_cookie
#never_cache
def serve_login_template(request):
return render(request, "login.html")
...
I solved this problem by setting X-CSRFTOKEN header in $routeChangeStart event.
I don't exactly know how module.run phase works, but it seems that when certain event defined within it occurs everything what is defined outside this event's handler body isn't executed.
mainModule.run(['$http','$cookies', '$location', '$rootScope', 'AuthService',
function($http, $cookies, $location, $rootScope, AuthService) {
$http.defaults.headers.common['X-CSRFToken'] = $cookies.csrftoken;
$rootScope.$on( "$routeChangeStart", function(event, next, current) {
// Added this line
$http.defaults.headers.common['X-CSRFToken'] = $cookies.csrftoken;
if ( !(AuthService.isLoggedIn() == "true")){
$location.path('/login');
}
});
}]);
This works together with removing 'login.html' template from $templateCache.
Instead of removing templates on client side with $templateCache service it is also possible to set your server to serve templates and set following headers:
Cache-Control: no-cache, no-store, must-revalidate
Pragma : no-cache
Expires : 0
Another way of dealing with this problem is to simply force page refresh, however I don't like this approach, since this is not pro-single-page-app approach. :)
One solution could be to read the current, fresh csrftoken directly from the cookie and then update the stale cookie using javascript.
var fresh_token = document.cookie.match('csrftoken=([a-zA-Z0-9]{32})