In pageload, if you do Response.Cookies.Add(..., immediately in the next line, you can access that cookie via Request.Cookies(...
I know that under the covers, the cookie is added to Request.Cookies by .net, but the original request never had that cookie.
If what I'm saying is correct, why is it this way? Shouldn't the cookie be available in the following request? Shouldn't the immediate access to Request.Cookies(... be null?
You're right, ASP.NET does do that behind the scenes:
After you add a cookie by using the
HttpResponse.Cookies collection, the
cookie is immediately available in the
HttpRequest.Cookies collection, even
if the response has not been sent to
the client.
-- HttpRequest.Cookies page on MSDN
Why is it like that? At a guess, it's because that's how developers expect it to work.
Related
I post this question cause i've passed lot of time to find the solution and find nothing about this on SO.
I'm using a .NET WebAPI as back end and store the user informations in the session.
For any reasons the session is lost in Chrome.
I receive the Set Cookie with the session id on my first request but the session is not set in Chrome but is set in IE.
I've try to change the web.config several time and change the configuration of the server but nothing changed.
I'm using fetch API for call my services.
Fetch does not send cookies by default. If your cookies are not HTTP only, you have to set them manually in the headers collection.
The issue is on the fetch and not on the server side.
The strange thing is that it's work on IE. Apparently IE don't have the same policy for the fetch API.
You have to make sure to add the property credentials to include or same-origin to keep the session on your request.
Warning : Put credentials to include fire a security error in Chrome.
The same-origin value resolved my problem.
Example of request :
fetch(uri,{
method:'GET',
credentials:'same-origin'
})
.then()
.catch()
There was a weird issue yesterday about asp.net's outputcaching (webforms). We were using page-level caching (not partial caching) for a multi-lingual site (language is determined via querystring key) and for some purpose, caching stopped working for some languages. I kept track of GetVaryByCustomString method of Global.asax file but, it didnt worked. I will give more details in answer...
Perhaps you need to set the Shareable attribute on your cookies to true?
If a given HttpResponse contains one or more outbound cookies with
Shareable is set to false (the default value), output caching will be
suppressed for the response. This prevents cookies that contain
potentially sensitive information from being cached in the response
and sent to multiple clients. To allow a response containing cookies
to be cached, configure caching normally for the response, such as
using the OutputCache directive or MVC's [OutputCache] attribute, and
set all outbound cookies to have Shareable set to true.
https://msdn.microsoft.com/en-us/library/system.web.httpcookie.shareable(v=vs.110).aspx
Thanks to subversion, i kept track of recent commits. We made a mechanism allowing specific users to view some languages that have not been published yet, using cookies instead of session variables. This was the cause of problem. If a request comes to a language which is not the default language, this mechanism checks whether it should allow user to view page. And IMHO if you modify response's cookie collection, asp.net disables outputcache for that request. I tested it and it really disables cache if you add a cookie to response.
I'm implementing analytics event and page view tracking on a Roku box (brightscript). That part isn't so important, but know that JS is not an option, nor is cookie setting. I can set variables, but they're not typical cookies. Ok - so I've implemented a great solution (google-analytics-for-roku-developers/) and all is well - EXCEPT!!
Analytics doesn't seem to track uniques, and is listing ZERO. It is tracking events beautifully, however :)
Here's a sample of my URI request (decoded for clarity):
http://www.google-analytics.com/__utm.gif?utmwv=1&utmn=1736644096&utmsr=720p HDTV&utmsc=24-bit&utmul=en-us&utmje=0&utmfl=-&utmdt=RokuPageView&utmhn=Home&utmr=-&utmp=Home&utmac=UA-5035974-13&utmcc=__utma=1394882688.2097034752.1347384621.1347384621.1347384621.2;+__utmb=1394882688;+__utmc=1394882688;+__utmz=1394882688.1347384621.2.2.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none);+__utmv=1394882688.13C1CJ109560;
so, question #1 - I understand from the docs that the __utma is the element that tracks uniques. Do you see anything there that's wrong?
question #2 - The development code I implemented sends a NEW random cookie for EACH EVENT. That seems wrong to me. I'm considering changing it to a session-based cookie that persists through all events. That's when I'm way beyond my understanding. Any guidance on this?
I think the answer to #2 is the answer to #1. Basically, you need to emulate how a browser handles cookies within your code. A "session cookie" is just a cookie, that is, a value passed as an HTTP header along with the request and response -- what makes it a session cookie is that it's expiration date is set to the past, which tells the browser to delete it when the browser instance closes.
Cookies are pretty straightforward -- a mechanism to get around the fact that HTTP is stateless (has no memory). If you pass an HTTP header Set-cookie: <value> in the response, the client is supposed to remember the value and pass it back in a Cookie: <value> header in subsequent requests. (There's a bit more to cookies relating to domains and expiration, and so on, but it's not that much).
So if your client (the Roku) has some mechanism for persistance, then you just need to store any new cookie, then before setting a new random one, check the header and if the cookie has been stored, just send it back as is. You'll probably need to implement some sort of task that cleans up expired cookies periodically, and so on.
Do not fear the cookie. It's just a header (with browser-imparted magical powers).
I would like to load cookies everytime and everywhere in my website because when my RoR application receives and accepts an "external" HTTP request (ex: REST API), cookies are not loaded (see RFC2109). So their values are inaccessible.
Cookies are accessible only when the HTTP request is made "internally" in my application.
new_cookies = {"Cookie" => "mycookie=1234;myothercookie=4567"}
Net::HTTP.get( URI.parse( http: //app1.website.com/users ), new_cookies)
All browsers will automatically send any cookies you set from your domain, you can check them simply by calling request.cookies from any controller method. It doesn't matter if the request was initiated from within your application (such as a 302 redirect) or not.
I just tried this with Firecookie:
Created a cookie "mycoolcookie" for the domain ".stackoverflow.com"
Went to stackoverflow.com, firebug showed that the cookie was sent in the request header.
Went to meta.stackoverflow.com, firebug showed that the cookie was sent in the request header.
Went to chat.stackoverflow.com, firebug showed that the cookie was sent in the request header.
A cookie is sent automatically by the browser, the server can never request for a cookie to be sent to it.
REST APIs are generally stateless, therefore you should avoid the use of server-side sessions or client-side cookies. If you want to indicate that a user only grabs resources belonging to them, use the Rails nested resources approach, that results in a call like:
http://abc.com/user/user001/books
For all books that belong to user001.
If you are looking to implement security, first you have to use HTTPS instead of HTTP. For the actual implementation you can use Basic Authentication and set the username/password in the request header or you can use something like OAuth which sets up a token for the user that they pass in with each request.
H
Regarding this URL
http://www.codeproject.com/KB/aspnet/FlashUpload.aspx
User.Identity as System.Web.Security.FormsIdentity is always null, because the Identity is GenericIdentity, I assumed it will be as in the tutorial FormsIdentity, what is chances.
Thanks
Rather than Casting to FormsAuthentication, Simply get the cookie .ASPXAUTH (or the name specified in the web.config) and send it to flash and then let flash put it as a POST variable while uploading, then Read Request.Forms[POSTVariable] and create the FormsAuthenticationTickt as illustrated by the tutorial in the question.
This is the problem with Flash, and it has nothing to do with your server side code and here is why.
When Flash makes web service calls, http service calls to the same domain it came from, it regains cookies and in turn the each calls are made within your session (ASP.NET Session), but when you upload something flash does not send cookie (A bug reported to adobe with no response till date).
This is the reason FormsIdentity is null, because ASP.NET Server needs cookie in order to assign FormsIdentity to properly authenticated user request.
Thats why when you upload, you will never get the session, the work around this is, we pass a custom authentication hash in querystring that we can validate on the server side.