Get/Set cookies from qml - cookies

I am writting a client program. When I login, the server will send some cookies to me in the 'Set-Cookie' header field.
I need to get the cookies, because the rest of the request will need them.
I try to get the cookies with xmlhttprequest.getResponseHeader("Set-Cookie"), but failed.
I don't want to use C++, so could it be possible?

No, it is not possible without using C++.
Look at source code for QDeclarativeXMLHttpRequest::fillHeadersList() method. It particularly removes set-cookie and set-cookie2 headers, following w3c specs for XMLHttpRequest object. Specifically behaviour of getAllResponseHeaders method. That is:
Return all the HTTP headers, excluding headers that are a case-insensitive match for Set-Cookie or Set-Cookie2, ...

Related

Difference between Response.Cookies and Response.AddHeader "Set-Cookie"

In classic ASP, when I am setting a cookie using Response.Cookies("data1") = "value1" then
I am able to read this cookie using Request.Cookies("data1") on the same page
But when I am using the syntax Response.AddHeader "Set-Cookie", "data2=value2" then
I am not able to read this cookie using Request.Cookies("data2") on the same page.
So What is the difference between these two syntaxes of setting cookie and if I want to read the cookie using the second syntax how sould the read statement look like
Both methods set the HTTP header
set-cookie
but with a key difference.
Response.Cookies is a collection that is pre-built then when the response is ready to send, the HTTP header set-cookie is created. This means that for the life of the page where the Cookie collection is specified, the values are available to manipulate as much as you want.
Response.AddHeader() sets the HTTP header set-cookie when the response is sent back to the client, it has no association at all to Response.Cookies() and setting
Response.AddHeader("set-cookie", "...")
will not magically populate the Response.Cookies collection. The only way to populate the Cookies collection without using Response.Cookies() is to make a round trip to the server after Response.AddHeader() has been set.

Set-Cookie for a login system

I've run into a few problems with setting cookies, and based on the reading I've done, this should work, so I'm probably missing something important.
This situation:
Previously I received responses from my API and used JavaScript to save them as cookies, but then I found that using the set-cookie response header is more secure in a lot of situations.
I have 2 cookies: "nuser" (contains a username) and key (contains a session key). nuser shouldn't be httpOnly so that JavaScript can access it. Key should be httpOnly to prevent rogue scripts from stealing a user's session. Also, any request from the client to my API should contain the cookies.
The log-in request
Here's my current implementation: I make a request to my login api at localhost:8080/login/login (keep in mind that the web-client is hosted on localhost:80, but based on what I've read, port numbers shouldn't matter for cookies)
First the web-browser will make an OPTIONS request to confirm that all the headers are allowed. I've made sure that the server response includes access-control-allow-credentials to alert the browser that it's okay to store cookies.
Once it's received the OPTIONS request, the browser makes the actual POST request to the login API. It sends back the set-cookie header and everything looks good at this point.
The Problems
This set-up yields 2 problems. Firstly, though the nuser cookie is not httpOnly, I don't seem to be able to access it via JavaScript. I'm able to see nuser in my browser's cookie option menu, but document.cookie yeilds "".
Secondly, the browser seems to only place the Cookie request header in requests to the exact same API (the login API):
But, if I do a request to a different API that's still on my localhost server, the cookie header isn't present:
Oh, and this returns a 406 just because my server is currently configured to do that if the user isn't validated. I know that this should probably be 403, but the thing to focus on in this image is the fact that the "cookie" header isn't included among the request headers.
So, I've explained my implementation based on my current understanding of cookies, but I'm obviously missing something. Posting exactly what the request and response headers should look like for each task would be greatly appreciated. Thanks.
Okay, still not exactly what was causing the problem with this specific case, but I updated my localhost:80 server to accept api requests, then do a subsequent request to localhost:8080 to get the proper information. Because the set-cookie header is being set by localhost:80 (the client's origin), everything worked fine. From my reading before, I thought that ports didn't matter, but apparently they do.

BIS setting http headers

I'm trying to perform a web call which requires a cookie.
Currently I am able to login and get the cookie from the Set-Cookie response header.
I then put this in the following requests' header under Cookie.
This is working perfectly on WiFi. But as soon as I try with BIS, I get the cookie but the following calls fail.
I have noticed the headers are lowercase for BIS, so I have to get the set-cookie field, but how do I use that cookie in the subsequent calls?
I have also tried setting x-rim-transcode-content: none with no luck.
I assume I'm just missing some small "feature" of blackberry that would resolve this. Any advice would be appreciated.
I finally found a fix for my problem. Extra cookies where being added to the set-cookie header, once I stripped them out it worked.

I want to check whether a page is using cookies or not?

Is it possible that I hit a page and in response I get the information that this page is using cookies.
You don't specify which tools you are using, but the cookies are set using HTTP headers, so look in the headers and you will see all the cookie information.
Using curl, --dump-headers may be interesting.
I am assuming c# from your "httpcookie" tag.
Use HttpWebRequest and make sure to assign its CookieContainer property before making the request. When the request completes, check the response.Cookies.

question about cookie

I'm stuck in a cookie related question. I want to write a program that can automate download the attachments of this forum. So I should maintain the cookies this site send to me. When I send a GET request in my program to the login page, I got the cookie such as Set-Cookie: sso_sid=0589a967; domain=.it168.com in my program. Now if I use a cookie viewer such as cookie monster and send the same GET request, my program get the same result, but the cookie viewer shows that the site also send me two cookies which are:
testcookie http://get2know.it/myimages/2009-12-27_072438.jpg and token http://get2know.it/myimages/2009-12-27_072442.jpg
My question is: Where did the two cookie came from? Why they did not show in my program?
Thanks.
Your best bet to figure out screen-scraping problems like this one is to use Fiddler. Using Fiddler, you can compare exactly what is going over the wire in your app vs. when accessing the site from a browser. I suspect you'll see some difference between headers sent by your app vs. headers sent by the browser-- this will likley account for the difference you're seeing.
Next, you can do one of two things:
change your app to send exactly the headers that the browser does (and, if you do this, you should get exactly the response that a real browser gets).
using Fiddler's "request builder" feature, start removing headers one by one and re-issuing the request. At some point, you'll remove a header which makes the response not match the response you're looking for. That means that header is required. Continue for all other headers until you have a list of headers that are required by the site to yield the response you want.
Personally, I like option #2 since it requires a minimum amount of header-setting code, although it's harder initially to figure out which headers the site requires.
On your actual question of why you're seeing 2 cookies, only the diagnosis above will tell you for sure, but I suspect it may have to do with the mechanism that some sites use to detect clients who don't accept cookies. On the first request in a session, many sites will "probe" a client to see if the client accepts cookies. Typically they'll do this:
if the request doesn't have a cookie on it, the site will redirect the client to a special "cookie setting" URL.
The redirect response, in addition to having a Location: header which does the redirect, will also return a Set-Cookie header to set the cookie. The redirect will typically contain the original URL as a query string parameter.
The server-side handler for the "cookie setter" page will then look at the incoming cookie. If it's blank, this means that the user's browser is set to not accept cookies, and the site will typically redirect the user to a "sorry, you must use cookies to use this site" page.
If, however, there is a cookie header send to the "cookie setter" URL, then the client does in fact accept cookies, and the handler will simply redirect the client back to the original URL.
The original URL, once you move on to the next page, may add an additional cookie (e.g. for a login token).
Anyway, that's one way you could end up with two cookies. Only diagnosis with Fiddler (or a similar tool) will tell you for sure, though.