The question that I have is very basic: Is there a way to inform the web browser that the content of the cookie has changed?
I don't want to keep looking at the file and check if it has been updated because it'll cause performance degree on my app.
Thanks in advance!
It's always the job of the server to "push" the new cookie to the browser (in ASP.NET, by setting Response.Cookies("cookie_name")).
I'm not sure to understand your concern, only your application can know that the user's cookie needs to be changed, but it's usually not stored as a file on the server.
You would probably have to check for the Cookie or Set-Cookie http headers that come with the ASP page whenever it reloads in your application, though this would not account for changes made by javascript.
If the ASP page is refreshing each time a cookie changes, that is likely to be a much larger overhead than the WPF reading the cookie from the disk.
Well, since the ASP page needs to be active in order to SET the cookies, why couldn't you just use a HttpClient to request the cookies in your WPF app and on the server, set the cookies. Then send HTTP Response depending on whether or not you set the cookies. If you receive a 200 OK response, you can know your cookies are set. If there's an error, send a 500 Server Error back.
Related
In my web application, there's a link sending a redirect (302 to another GET request) together with some cookies. It works fine, except when used from MS Access by a guy I remotely work with. I know close to nothing about what and how he does, I only know that he uses Application.FollowHyperlink.
The link from Access should be opened in a browser, but after the redirect, there seem to be no cookies there. When used normally, there's no problem. Can it be like that Access handles the link itself and sends the redirected URL to the browser?
Maybe a stupid question, but I have no idea about Access (never ever seen it) and I'm sitting only on the server side. There's nothing interesting in the server logs...
The problem was MS doing some complicated things like here instead of simply opening an URL in a browser. Access accesses the page, sees the new URL, and gets and eats all cookies. While digesting the cookies, it points the browser to the new URL. The browser has no cookies and no access to anything.
This summarizes it nicely:
This problem occurs because of missing session cookies for the Web server. This problem is specific to certain Web-server designs that depend on cookie information instead of authentication information or that depend on cookie information plus authentication information.
To me it sounds like "works with MS only", though I'm not exactly sure what "authentication" they mean.
I was using Fiddler see on-the-field how web sites use cookies in their login systems. Although I have some HTTP knowledge, I'm just just learning about cookies and how they are used within sites.
Initially I assumed that when submitting the form I'd see no cookies sent, and that the response would contain some cookie info that would then be saved by the browser.
In fact, just the opposite seems to be the case. It is the request that's sending in info, and the server returns nothing.
When fiddling about the issue, I noticed that even with a browser cleaned of cookies, the client seems to always be sending a RequestVerificationToken to the server, even when just looking around withot being signed in.
Why is this so?
Thanks
Cookies are set by the server with the Set-Cookie HTTP response header, and they can also be set through JavaScript.
A cookie has a path. If the path of a cookie matches the path of the document that is being requested, then the browser will include all such cookies in the Cookie HTTP request header.
You must make sure to be careful when setting or modifying cookies in order to avoid XSS attacks against your users. As such, it might be useful to include a hidden and unique secret within your login forms, and use such secret prior to setting any cookies. Alternatively, you can simply check that HTTP Referer header matches your site. Otherwise, a malicious site can copy your form fields, and create a login form to your site on their site, and do form.submit(), effectively logging out your user, or performing a brute-force attack on your site through unsuspecting users that happen to be visiting the malicious web-site.
The RequestVerificationToken that you mention has nothing to do with HTTP Cookies, it sounds like an implementation detail that some sites written in some specific site-scripting language use to protect their cookie-setting-pages against XSS attacks.
When you hit a page on a website, usually the response(the page that you landed on) contains instructions from the server in the http response to set some cookies.
Websites may use these to track information about your behavior or save your preferences for future or short term.
Website may do so on your first visit to any page or on you visit to a particular page.
The browser would then send all cookies that have been set with subsequent request to that domain.
Think about it, HTTP is stateless. You landed on Home Page and clicked set by background to blue. Then you went to a gallery page. The next request goes to your server but the server does not have any idea about your background color preference.
Now if the request contained a cookie telling the server about your preference, the website would serve you your right preference.
Now this is one way. Another way is a session. Think of cookies as information stored on client side. But what if server needs to store some temporary info about you on server side. Info that is maybe too sensitive to be exposed in cookies, which are local and easily intercepted.
Now you would ask, but HTTP is stateless. Correct. But Server could keep info about you in a map, whose is the session id. this session id is set on the client side as a cookie or resent with every request in parameters. Now server is only getting the key but can lookup information about you, like whether you are logged in successfully, what is your role in the system etc.
Wow, that a lot of text, but I hope it helped. If not feel free to ask more.
I'm in the middle of making a small scraping utility which is designed
to run as quickly as possible using multiple http connections to the server.
How does one handle cookies in this situation..
For example if the first connection scrapes the page for links, and the server
sets the cookie to something,, wouldn't firing off additional connections
cause the cookies to be out of sync ?
The answer is it really depends on the server.
If the server changes the cookie with each and every request
yes it will throw off the cookie. What exactly this does again
depend on the server.
If say the cookie is just set once at login, then it wouldn't really matter.
I'm implementing http authentication using basic schema for my server.
Sever sends a 401 response to client and then browser will pop up a window asking for credentials. And then browser will send username/passwd in Authorization header.
The question is, when browser opens the link for a second time, Authorization header was included in the request header but there was no pop up window, seems these credentials
were remembered(cached).
any one knows how to control this? what to do if I need user input passwd every time? what to do if I need to set a valid duration for this cache?
Great thanks!
You can't do it manually. Read here
In my previous understanding, for a web site, only login user of a web site (no matter what login/authentication approach is used) could have cookie as persistent identifier, so that if the user close the browser, open browser again to go to the same web site, the web site could remember the user.
But I learned recently that it seems for non-login user, there could still be a cookie associated with the user (after the user close browser, and then open the browser again to go to the same web site, the web site could remember the user), and it is called browser cookie? Is that true?
If it is true, who is responsible to set the browser cookie? i.e. need some coding/config at web server side, client browser configuration (without coding from server side), or both? How could web server access such cookie? Appreciate if any code samples.
thanks in advance,
George
Whether you actually "log in" or not is irrelevant to what cookies are stored.
If the browser requests a page, and the server includes a Set-Cookie response header, then the browser will store the value of that cookie in a local cache and every time it requests a page from the same server, it sends the value of the cookie back as well (in the Cookie request header).
It just so happens that when you "log in" to a website, the website will usually use the Set-Cookie header to tell the browser to store a value that indicates that you're already logged in (and your user-id and some other security-related stuff). But there's nothing stopping the web server from using Set-Cookie at any other time.