Skip to main content

70-562 Cookies


COOKIES SUMMARY
http cookies are hidden message that travel between the webservers and their client, they are created on the server, and sent to the client. When client makes subsequent request to the web site, the cookie is embeded in the http header of that request. By default cookies remain in the browser memory and expires when the browser closes. By setting the Expires property of the cookie, you can control how long it will be kept, and save to disk on the client. Until the cookie expires, the browser automatically sends it with any request to the site where it originated from. Cookies were created in the last milenium for netscape explorer, specificaly to remember a shopping cart, between requests.

COOKIES LOCATION ON THE SYSTEM
The cookies for internet explorer are kept in the hidden appdata folder, and hidden Cookies folder and/or file of the logged in user, IE in windows 6 or later this is AppData\Roaming\Microsoft\Windows\Cookies, other browsers store in different locations. Chrome puts them in a signle hidden file at AppData\Local\Google\Chrome\User Data.

COOKIES COLLECTIONS IN CODE, AND PROPERTIES TO REMEMBER
Using coookies is simple, to read cookies you use the Request objetct like this Request.Cookies which is the cookies collection. The request object is actually an HTTPRequest object wich contains alot of properties about the request the server is receiving from the client. The cookies collection is a HTTPCookiesCollection consisting of HTTPCookie object.

You write cookies using the Response.Cookies collection. This Response object is actually an HTTPResponse object containing an HTTPCookiesCollection object which contains HTTPCookies objects.Page_Load is a good method you can use the Resquest.Cookies["UserName"] != null to see if the cookie exists. Before doing this you check if it's a postBack, because if it's a postback it's likely the user change the value that needs to go in the cookie, and you have to update it. This is also the time at which you would set the Response.Cookies["User"].Expires property to a DateTime to a future date like DateTime.Today.AddDays(1).


LIMITATIONS OF COOKIES
Users can turn off cookie
Users may accept only in-memory cookies but not persistent cookies, this doesnt cause an error, but the session is not persisted.
Typical max size is 4096 characters, and 20 cookies for a single domain.
Cookies are saved as simple text files, hidden text files
Privacy risk(DoubleClick stores a 1px by 1px image to make it something allowed to store cookies and use that for tracking).

In classic asp, the session state was stored in process, the webserver process, lost on a restart. Also this aint usefull with server afinity and web farms since the request would have to be routed to the same web server it had it's previous session at.

In asp.net there is the possibilty to put the sessionID in the query string if cookies are not enabled on the browser.

Default session state management behavior
Default session state management behavior: uses temporary cookies to hold session IDs, holds sessions state in process, the default session timeout is 20minutes.the Session["PageLoadTime"] is part of the page, so to create a variable called PageLoadTime you'd do Session["PageLoadTime"] =datetimeyou can get access to the session object through, Page.Session, Context.Session, Application.Session, WebService.Session, UserControl.Session.

Important properties: 
CookieMode: are cookies use
Count: numebr of items stored in session state
IsCookieless: indactes if the session is passed through the URL or through a cookie(incase cookies disabled in the client)
IsNewSession: indicates whether the session was created with the current request of the client, incase intialization special is required.
Item: lets you get or set individual items, wtf...
Keys: returns a collection of all items stored in session state
Mode: how is session state is store, in mem, sql server, etc
SessionID: Returns the identifier created by the web server, to uniquely identify the session, always passed as part of the

http header for each request and response
Timeout: default 20min timeout for a session, max 1 year, always set in seconds

Methods of the session object:
Session.Abandon(); //used when use uses a logout feature, server considers it a brand new request from unknow user
Session.Clear(): clears all the keys from a collection
Session.Remove(): removes a specific item at the given index

CAn store more than strings in session state, you can actualy store objects, and they usualy will need a cast to be casted back from System.Object (the format it which they are stored in teh session object) back to the type of object originally stored.

Typically, database data can be stored to session state. First in the page_load check if it's a postback, if it isnt, we make sure the the variable in the session state is null, if it is then it's time to load that table from the database. Then would set it in the session state providing a variable name in brackets like Session["myTable"] = myDataTable;

If it already exists, if it is a postback, it need to be retrived form the session state myTable = (DataTable)Session["myTable"]; then we bind it the the drop down list if thats what is using this table. So in this case we would set the DataTextField the DAtaValueField, the DataSource and call the DataBind() method.

Reminder: to filter a table, it is best to get the DefaultView property of the table to work with the dataview, this one can also be stored in Session State. This dataview allows to set a RowFilter to act as a where clause to filter.

No binary blobs stored in sessions state, but a serialized stream, and occurs at the end of the page request.

So in page cycle, at the end of the page cycle, asp.net does, when a request comes in, asp.net looks for a session id cookie, or in the url, if it finds an id, it retrievs the binary data for the session, if it doesnt find it, it creates one and initialize a session. The session_Start and session_end even in the global asax allow to take actions either at begining or end of the session, if for example persistence is required.



Comments

Popular posts from this blog

React JS Patterns

React JS is always evolving, and evolving quickly. These evolutions can be very significant ones, for example, the addition of hooks. React has a lot of code patterns, often these patterns are motivated by the DRY and/or the open-close principle. These patterns sometimes come in to replace a previous one, yet the previous ones still stays in use, as a consequence, the list of patterns keep growing. The goal of the next few posts will be to list the patterns commonly used in React JS developpement. Some patterns are more specific to JSX and I will start with these, and maybe add patterns specific to Redux.

Rxjs Forkjoin vs Zip

These Rxjs combination operators are handy to make Rest calls in parallel and combine their results. Both take n observables and will return the results, with the difference that forkJoin will complete even if one of the nested observables errors of completes.

Object.create vs. Object.Assign

The two functions return a new Object but with a difference. Object.assign will go through an enumerable and copy it's properties. Object.create will create a new empty object but link it's proto chain to the old object. One way to view this is with JSON.stringify(newCreatedObject) this would return an empty object, since all the properties are not part of the object's own properties, but inherited through prototype inheritance. In both case, the advantage is it allows to extended existing objects without modifying the original. This is particularly important when receiving arguments from a caller, in this case it's better to use these methods instead of modifying the caller's object since he might have planned to use it again later, expecting it to be in it's original state.