I have been reading the questions on the stackoverflow regard CORS implementation for a couple weeks but I'm still stuck on a couple errors. Any pointers in the right direction would be great. Thanks in advance.
Here's what I have:
SERVER SETUP
public void doOptions(HttpServletRequest request, HttpServletResponse response)
throws IOException {
//The following are CORS headers. Max age informs the
//browser to keep the results of this call for 1 day.
response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Methods", "GET, POST");
response.setHeader("Access-Control-Allow-Headers", "Content-Type");
response.setHeader("Access-Control-Max-Age", "86400");
//Tell the browser what requests we allow.
response.setHeader("Allow", "GET, HEAD, POST, TRACE, OPTIONS");
CLIENTSIDE Javascript
OLVM Test Page
<SCRIPT language="JavaScript">
function setMessage(){
msg = "";
var xmlHttp;
msg = msg + "110###B#~20#OLVM-GL-ACCOUNT#~20";
xmlHttp=new XMLHttpRequest();
xmlHttp.open("POST","http://MYSITE.ceco.com:2900/OLVM/OLVMGateway",false);
xmlHttp.setRequestHeader("Content-Type","text/xml");
xmlHttp.send(msg);
alert(xmlHttp.responseText);
return;
}
</SCRIPT>
</head>
<body bgcolor="#FFFFFF">
<p> </p>
<p align="left"><font face="Arial" size="6"><b>OLVM - PBF </b></font></p>
<input type="button" name="submit" value="Submit To Server" onClick= "setMessage()" >
</body>
</html>
OPTIONS HEADER info I see when debugging
Request URL:http://MYSITE.ceco.com:2900/OLVM/OLVMGateway
Request Method:OPTIONS
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Access-Control-Request-Headers:content-type
Access-Control-Request-Method:POST
Connection:keep-alive
Host:MYSITE.ceco.com:2900
Origin:null
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Response Headersview source
Access-Control-Allow-Headers:Content-Type
Access-Control-Allow-Methods:GET, POST
Access-Control-Allow-Origin:*
Access-Control-Max-Age:86400
Allow:GET, HEAD, POST, TRACE, OPTIONS
Content-Length:0
Date:Wed, 02 Jul 2014 12:13:41 GMT
POST HEADER info I see when debugging
Request URL:http://MYSITE.ceco.com:2900/OLVM/OLVMGateway
Request Method:POST
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Content-Length:337
Content-Type:text/xml
Host:MYSITE.ceco.com:2900
Origin:null
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Request Payload
110###B#~20#OLVM-GL-ACCOUNT#~20
Response Headersview source
Content-Length:7
Content-Type:text/html
Date:Wed, 02 Jul 2014 12:13:41 GMT
ERROR I get
XMLHttpRequest cannot load http://MYSITE.ceco.com:2900/OLVM/OLVMGateway. No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'null' is therefore not allowed access. OLVM_V5.html:59
Uncaught NetworkError: Failed to execute 'send' on 'XMLHttpRequest': Failed to load 'http://MYSITE.ceco.com:2900/OLVM/OLVMGateway'.
You are only adding the headers to the OPTIONS response.
However, for the request to succeed you have to set those headers both on OPTIONS and on POST responses.
Also note that your code will not work in IE8 as it requires proprietary XDomainRequest object as you can see in HTML5Rocks.com example:
function createCORSRequest(method, url) {
var xhr = new XMLHttpRequest();
if ("withCredentials" in xhr) {
// Check if the XMLHttpRequest object has a "withCredentials" property.
// "withCredentials" only exists on XMLHTTPRequest2 objects.
xhr.open(method, url, true);
} else if (typeof XDomainRequest != "undefined") {
// Otherwise, check if XDomainRequest.
// XDomainRequest only exists in IE, and is IE's way of making CORS requests.
xhr = new XDomainRequest();
xhr.open(method, url);
} else {
// Otherwise, CORS is not supported by the browser.
xhr = null;
}
return xhr;
}
var xhr = createCORSRequest('GET', url);
if (!xhr) {
throw new Error('CORS not supported');
}
Related
I'm using FileUploader UI5 element to upload a file using XMLHttpRequest (POST operation), here below is my code snippet -
var input = document.querySelector('input[type="file"]');
var data = new FormData();
data.append("files", input.files[0]);
var xhr = new XMLHttpRequest();
xhr.open("POST","https://URL");
xhr.setRequestHeader('Content-Type', 'multipart/form-data');
xhr.setRequestHeader("apikey", "XXXXXXXXXXXXXXXXX");
xhr.setRequestHeader("accept", "application/json");
xhr.send(data);
But while pushing a request, i am getting below exception. Not sure why my post operation is getting failed, any help would be appreciated.
error description - This service requires at least 1 file. Please put your file(s) into the files field of the POST request"
This is how the request header and payload looks like -
Request Header -
Accept:*/*
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.8
apikey:RGIukzqxB0GWhRaMMcCTmYGHnEWgk5qI
Connection:keep-alive
Content-Length:15
Content-Type:text/plain;charset=UTF-8
Host:sandbox.api.sap.com
Origin:https://webidetesting2532276-be010f3f7.dispatcher.us1.hana.ondemand.com
Referer:https://webidetesting2532276-be010f3f7.dispatcher.us1.hana.ondemand.com/extended_runnable_file.html?hc_orionpath=%2Fbe010f3f7%24S0015741697-OrionContent%2Fsap.ui.unified.sample.FileUploaderComplex&origional-url=index.html&sap-ui-appCacheBuster=&sap-ui-xx-componentPreload=off
User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Request Payload -
[object Object]
You've explicitly set the Content-Type but it is missing the MIME boundary parameter. Omit the header entirely and allow XHR to infer the Content-Type from the FromData object.
I have a problem with my script where I got an error message such as this
XMLHttpRequest cannot load https://igoblogging.com/likebutton/. The
value of the 'Access-Control-Allow-Origin' header in the response must
not be the wildcard '*' when the request's credentials mode is
'include'. Origin 'http://nielinfo.com' is therefore not allowed
access. The credentials mode of requests initiated by the
XMLHttpRequest is controlled by the withCredentials attribute.
I tried to load a cookie from cross domain. Here is my javascript code
var xhr = new XMLHttpRequest();
xhr.open('POST', linkbased+'/likebutton/',true);
xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
xhr.withCredentials = true;
xhr.onreadystatechange = function () {
if(this.readyState == 4 && this.status == 200) {
if(document.getElementById("igblikebutton")){
document.getElementById("igblikebutton").innerHTML = this.responseText;
}
}
}
xhr.send(data);
And here is my php script
header('Access-Control-Allow-Origin: http://nielinfo.com');
header('Access-Control-Allow-Methods: POST');
header('Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept');
header('Access-Control-Allow-Credentials: true');
echo $_COOKIE['username'];
Here is the response headers
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods:POST
Access-Control-Allow-Origin:*
Cache-Control:max-age=604800
Content-Type:text/html; charset=utf-8
Date:Wed, 05 Jul 2017 07:09:04 GMT
Expires:Wed, 12 Jul 2017 07:09:04 GMT
Server:Apache/2.4.25 (CentOS)
Strict-Transport-Security:max-age=2592000; preload
Transfer-Encoding:chunked
Upgrade:h2
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Powered-By:PHP/5.4.45
X-Supported-By:Kloxo-MR 7.0
X-XSS-Protection:1;mode=block
And here is the request headers
Accept:*/*
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Content-Length:82
Content-type:application/x-www-form-urlencoded
Cookie:__cfduid=d239fe9b5de5b706676a60c112ccbd5d01497599052; _ga=GA1.2.91093954.1497599466; kloxo-clientname=admin; kloxo-classname=client; kloxo-session-id=L5b4xFTJphHH9kQN1AidVz6jpQw2QuazpkJd4TmW4E71fXMOPb; __atuvc=1%7C25; HstCfa3839354=1498146551883; HstCla3839354=1498146551883; HstCmu3839354=1498146551883; HstPn3839354=1; HstPt3839354=1; HstCnv3839354=1; HstCns3839354=1; username=flameblue59; ip=118.136.215.7; PHPSESSID=9614c4fcf759c74577837fdd5dad1c3f
Host:igoblogging.com
Origin:http://nielinfo.com
Referer:http://nielinfo.com/who-is-dullahan-the-headless-rider-who-will-terrified-you/
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
The weird thing, when I remove xhr.withCredentials. Its working fine but the cookie won't load. I think the problem because of withCredentials usage. I really appreciate any solution here. Thank you so much.
In the following code I am making a request from JQuery to method "save" on a JAX-RS server, with parameter userId. This JQuery runs from a Google Chrome extension (same issue when tested from localhost).
index.html (inside Chrome extension)
<script>
$.post('https://example.com:8082/save', { userId: 'myuser' } )
.done(function( data ) {
console.log(data);
});
</script>
The request is received, but I always get the error message ERROR: user not specified (see below).
JAX-RS Server side
#POST
#Consumes(MediaType.APPLICATION_FORM_URLENCODED)
#Path("/save")
public Response save(#FormParam("userId") String userId) {
if(userId == null) {
return Response.ok("ERROR: user not specified", MediaType.APPLICATION_JSON).build();
}
else {
[...]
}
}
I have tested the same request from CURL and it works well.
curl --data "userId=myuser" https://example.com:8082/save
Chrome Debug
Request URL:https://example.com:8082/save
Request Method:POST
Status Code:200 OK
Remote Address:131.224.32.213:8082
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://myteam.slack.com
Access-Control-Allow-Credentials: true
Content-Type: application/json
Content-Length: 25
Date: Wed, 14 Sep 2016 17:33:05 GMT
Connection: close
Accept:*/*
Accept-Encoding:gzip, deflate
Accept-Language:en,es;q=0.8
Connection:keep-alive
Content-Length:16
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Host:example.com:8082
Origin:https://myteam.slack.com
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36
userId=myuser
EDIT: Is it possible that it could be caused by a CORS rule? I am getting the POST request normally but no parameters. These are my filters on Tomcat. Do I need any CORS statements on JAX-RS?
Tomcat8 conf/web.xml
<filter>
<filter-name>CorsFilter</filter-name>
<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>CorsFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
I made it work with an XMLHttpRequest instead. Probably inserting the content-type header made the difference? This is the working code:
var http = new XMLHttpRequest();
var url = "https://example.com:8082/save";
var params = "userId=myuser";
http.open("POST", url, true);
http.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
http.onreadystatechange = function() {
if(http.readyState == 4 && http.status == 200) {
alert(http.responseText);
}
}
http.send(params);
I am using backbone to get data from an API. This all works fine when there is no authorization required and when I add the authorization to the API, I get the expected 401 - unauthorised response.
[from the console log:
GET http://localhost:999/api/tasks 401 (Unauthorized)
]
I've then add in this code to add the bearer authorization to the header for every call:
var backboneSync = Backbone.sync;
Backbone.sync = function (method, model, options) {
/*
* The jQuery `ajax` method includes a 'headers' option
* which lets you set any headers you like
*/
var theUser = JSON.parse(localStorage.getItem("happuser"));
if (theUser !== null)
{
var new_options = _.extend({
beforeSend: function(xhr) {
var token = 'Bearer' + theUser.authtoken;
console.log('token', token);
if (token) xhr.setRequestHeader('Authorization', token);
}
}, options)
}
/*
* Call the stored original Backbone.sync method with
* extra headers argument added
*/
backboneSync(method, model, new_options);
};
Once I include this code, the API sends the request with a method of OPTIONS instead of GET and I obviously get a 405 invalid method response.
Here is the console log output
OPTIONS http://localhost:999/api/tasks 405 (Method Not Allowed) jquery-1.7.2.min.js:4
OPTIONS http://localhost:999/api/tasks Invalid HTTP status code 405
Any idea why the send method would be changing?
ADDITIONAL DISCOVERY:
It appears when I do a model.save it does the same thing., even if I don't actually change the model.
FURTHER DETAILS: This is the Request/Response for the call without authorisation...
Request URL:http://localhost:999/api/tasks
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:application/json, text/javascript, */*; q=0.01
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Host:localhost:999
Origin:http://localhost
Proxy-Connection:keep-alive
Referer:http://localhost/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
Response Headersview source
Access-Control-Allow-Headers:*
Access-Control-Allow-Methods:GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Origin:http://localhost
Cache-Control:no-cache
Content-Length:3265
Content-Type:application/json; charset=utf-8
Date:Wed, 13 Nov 2013 14:51:32 GMT
Expires:-1
Pragma:no-cache
Server:Microsoft-IIS/7.5
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET
As soon as I add the sync override code in the response changes to this:
Request URL:http://localhost:999/api/tasks
Request Method:OPTIONS
Status Code:405 Method Not Allowed
Request Headersview source
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Access-Control-Request-Headers:accept, authorization
Access-Control-Request-Method:GET
Host:localhost:999
Origin:http://localhost
Proxy-Connection:keep-alive
Referer:http://localhost/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
Response Headersview source
Access-Control-Allow-Headers:*
Access-Control-Allow-Methods:GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Origin:http://localhost
Allow:GET,POST
Cache-Control:no-cache
Content-Length:76
Content-Type:application/json; charset=utf-8
Date:Wed, 13 Nov 2013 14:56:52 GMT
Expires:-1
Pragma:no-cache
Server:Microsoft-IIS/7.5
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET
It would appear you are issuing a "not so simple request ™":
you're making a CORS request
and you're setting a custom header
In that case, your browser divides your request in two : a preflight request (the OPTIONS verb you see) and the actual request once the permissions have been retrieved.
To quote the article linked:
The preflight request is made as an HTTP OPTIONS request (so be sure
your server is able to respond to this method). It also contains a few
additional headers:
Access-Control-Request-Method - The HTTP method of the actual request.
This request header is always included, even if the HTTP method is a
simple HTTP method as defined earlier (GET, POST, HEAD).
Access-Control-Request-Headers - A comma-delimited list of non-simple
headers that are included in the request.
The preflight request is a way of asking permissions for the actual
request, before making the actual request. The server should inspect
the two headers above to verify that both the HTTP method and the
requested headers are valid and accepted.
I have a Rails service returning data for my AngularJS frontend application. The service is configured to allow CORS requests by returning the adequate headers.
When I make a GET request to receive data, the CORS headers are sent, as well as the session cookie that I have previously received on login, you can see for yourself:
Request URL:http://10.211.194.121:3000/valoradores
Request Method:GET
Status Code:200 OK
Request Headers
Accept:application/json, text/plain, */*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:keep-alive
Cookie:_gestisol_session=BAh7B0kiDHVzZXJfaWQGOgZFRmkASSIPc2Vzc2lvbl9pZAY7AEZJIiVmYTg3YTIxMjcxZWMxNjZiMjBmYWZiODM1ODQzMjZkYQY7AFQ%3D--df348feea08d39cbc9c817e49770e17e8f10b375
Host:10.211.194.121:3000
Origin:http://10.211.194.121:8999
Pragma:no-cache
Referer:http://10.211.194.121:8999/
User-Agent:Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
X-Requested-With:XMLHttpRequest
Response Headers
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:X-Requested-With,X-Prototype-Version,Content-Type,Cache-Control,Pragma,Origin
Access-Control-Allow-Methods:GET,POST,OPTIONS
Access-Control-Allow-Origin:http://10.211.194.121:8999
Access-Control-Max-Age:1728000
Cache-Control:max-age=0, private, must-revalidate
Connection:Keep-Alive
Content-Length:5389
Content-Type:application/json; charset=utf-8
Date:Mon, 04 Nov 2013 14:30:51 GMT
Etag:"2470d69bf6db243fbb337a5fb3543bb8"
Server:WEBrick/1.3.1 (Ruby/1.9.3/2011-10-30)
X-Request-Id:15027b3d323ad0adef7e06103e5aa3a7
X-Runtime:0.017379
X-Ua-Compatible:IE=Edge
Everything is right and I get my data back.
But when I make a POST request, neither the CORS headers nor the session cookie are sent along the request, and the POST is cancelled at the server as it has no session identifier. These are the headers of the request:
Request URL:http://10.211.194.121:3000/valoraciones
Request Headers
Accept:application/json, text/plain, */*
Cache-Control:no-cache
Content-Type:application/json;charset=UTF-8
Origin:http://10.211.194.121:8999
Pragma:no-cache
Referer:http://10.211.194.121:8999/
User-Agent:Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
X-Requested-With:XMLHttpRequest
Request Payload
{valoracione:{revisiones_id:1, valoradores_id:1}}
valoracione: {revisiones_id:1, valoradores_id:1}
And the service answers with a 403 because the request does not contain the session cookie.
I don't know why the POST request fails, as the $resource is configured just like the other one and I have defined the default for $httpProvider to send the credentials (and it works right as the GET request succeeds):
.config(['$httpProvider', function($httpProvider) {
$httpProvider.defaults.withCredentials = true;
}])
This is the failing resource when I call $save() on an instance:
'use strict';
angular.module('gestisolApp')
.service('ValoracionesService', ['$resource', 'API_BASE_URL', function ValoracionesService($resource, API_BASE_URL) {
this.valoraciones = $resource(API_BASE_URL + '/valoraciones');
}]);
And this is the service that succeeds with the query() call:
'use strict';
angular.module('gestisolApp')
.service('ValoradoresService', ['$resource', 'API_BASE_URL', function ValoradoresService($resource, API_BASE_URL) {
this.valoradores = $resource(API_BASE_URL + '/valoradores');
}]);
They are much like the same.
Does anybody know why the POST is sent without the session cookie?
Edit
Just to complete the information, preflight is handled by the following method, and is handled OK as the request before the failing POST is an OPTIONS that succeeds with a 200 response code:
def cors_preflight_check
headers['Access-Control-Allow-Origin'] = 'http://10.211.194.121:8999'
headers['Access-Control-Allow-Methods'] = 'GET,POST,OPTIONS'
headers['Access-Control-Allow-Headers'] = 'X-Requested-With,X-Prototype-Version,Content-Type,Cache-Control,Pragma,Origin'
headers['Access-Control-Allow-Credentials'] = 'true'
headers['Access-Control-Max-Age'] = '1728000'
render :nothing => true, :status => 200, :content_type => 'text/html'
end
This is the CORS OPTIONS request/response exchange previous to the failing POST:
Request URL:http://10.211.194.121:3000/valoraciones
Request Method:OPTIONS
Status Code:200 OK
Request Headers
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Access-Control-Request-Headers:accept, x-requested-with, content-type
Access-Control-Request-Method:POST
Connection:keep-alive
Host:10.211.194.121:3000
Origin:http://10.211.194.121:8999
Referer:http://10.211.194.121:8999/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
Response Headers
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:X-Requested-With,X-Prototype-Version,Content-Type,Cache-Control,Pragma,Origin
Access-Control-Allow-Methods:GET,POST,OPTIONS
Access-Control-Allow-Origin:http://10.211.194.121:8999
Access-Control-Max-Age:1728000
Cache-Control:max-age=0, private, must-revalidate
Connection:Keep-Alive
Content-Length:1
Content-Type:text/html; charset=utf-8
Date:Mon, 04 Nov 2013 15:57:38 GMT
Etag:"7215ee9c7d9dc229d2921a40e899ec5f"
Server:WEBrick/1.3.1 (Ruby/1.9.3/2011-10-30)
X-Request-Id:6aa5bb4359d54ab5bfd169e530720fa9
X-Runtime:0.003851
X-Ua-Compatible:IE=Edge
Edit 2: I have changed the title to reflect clearly my problem
I had a similar problem and adding the following before angular $http CORS request solved the problem.
$http.defaults.withCredentials = true;
Refer https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#Requests_with_credentials for more details.
When CORS is involved, then your browser will send an OPTIONS request before the POST request.
I don't know the specifics with Rails, but I guess you have to configure Rails to actually answer the OPTIONS request with the adequate CORS headers.
The following code is just for comparison - it shows how you would address the issue in Java:
public void doOptions(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
resp.setHeader("Access-Control-Allow-Origin", "http://10.211.194.121:8999");
resp.setHeader("Access-Control-Allow-Credentials", "true");
resp.setHeader("Access-Control-Allow-Methods", "OPTIONS, POST, GET");
resp.setHeader("Access-Control-Allow-Headers", "X-Requested-With,X-Prototype-Version,Content-Type,Cache-Control,Pragma,Origin");
resp.setHeader("Access-Control-Max-Age", "600");
resp.setHeader("Access-Control-Expose-Headers","Access-Control-Allow-Origin");
super.doOptions(req, resp);
}
But it might get you on the right track how to configure it in Rails.
Ok, finally I figured out what was happening.
By the answer posted on this question, I removed the HttpOnly parameter from the cookie and got it working on Firefox. Later for Chrome was just a matter of applying the rest of recommendations from the answer to make it work, like setting a domain for the cookie.