Showing posts with label Cookies. Show all posts
Showing posts with label Cookies. Show all posts

Monday, October 19, 2009

Chapter 5-Lesson 3

  • Webparts are components within a webpage that can have their own personalization, positioning and event systems.
  • Any control can be a webpart.
  • Using webparts on ASP.NET pages requires ASPNETDB (a SQL Express) database to be used which keeps track of user personalizations for specific webparts.
  • Webparts are placed inside WebpartZone controls that define an area within a page that contains or may contain webpart(s).
  • Within WebpartZone control we need a ZoneTemplate to allow us to place standard controls within a zone.
  • Webparts may be created by simply placing standard ASP.NET controls or even a user control inside the ZoneTemplate. The WebpartManager will take care of the rest.
  • A WebpartManager control (non-visual) is required on every page that uses webparts (or any controls present in System.Web.UI.WebControls.Webparts). It handles events and other stuff related to the Webparts.
  • Webparts may be displayed in various modes allowing users to view, design and even edit the webpart.
  • We may switch between different webpart display modes by setting DisplayMode property to one of SupportedDisplayModes collection values of the WebPartManager class.
  • Webparts within a same page may connected statically or dynamically.
  • Static connections are the ones that are defined by the developer and cannt be modified or removed by the user. On the other hand, Dynamic Connections are modifiable by users.
  • To create a static connection, we create a Provider class, a Consumer class and then tell the WebPartManager control about these two using StaticConnections markup within WebPartManager markup.
  • The provider class should have a method decorated with ConnectionProvider attribute. Similarly, the consumer class should have a method decorated with ConnectionConsumer attribute. The value returned by the Provider method would go as argument into the Consumer method.
  • For dynamic connections, all we need is to add a ConnectionsZone object to the page and enable the user to switch to Connect mode using WebPartManager. Once in this mode, the user can create or break connections between any existing Provider and Consumer.
  • Personalization is enabled by default for WebParts, and it uses client-side Cookies to match the user with his/her record in ASPNETDB.
  • If we wish to disable this personalization, we need to set WebPartManager.Personalization.Enabled property to false, either by using code or markup.
  • We may also allow some users of the site to apply changes to WebPart page in such a way that the changes are visible to all users. This is called Shared Personalization.
  • To enable Shared Personalization, we add authorization tag within section of web.config file. Then we define allow tags to specify which users are allowed to do what to our page.

Sunday, September 27, 2009

Chapter 4:Lesson 1

  • Server-side state is secure but not quite scalable.
  • Client-side state is quite scalable but not secure.
  • Persisted state means saving state information into a database. Can be utilized if database server is heavy.
  • Shared state means storing copies of commonly accessed data on the server (caching) so that the server does not need to process page (or part of page) for every request.
  • ViewState stores object data that is not already represented as HTML in the page response.
  • Page.ViewState property is a Dictionary of type StateBag.
  • Object values on a page are hashed, compressed and encoded into Unicode string and stored using one or more hidden HTML fields (depending on how Page.MaxPageStateFieldLength is set)
  • ViewState includes MAC (Message Authentication Code) used by ASP.NET to check if it has been tampered with during the round trip.
  • ViewState can also be made to encrypt data, both on website level and individual page level.
  • For website level, we may enable viewStateEncryptionMode to Always in web.config, and for page level we set this value to Page directive of the page we want it encrypted for. (Page 189)
  • EnableViewState property on every server control allows for turning on/off ViewState management for that control.
  • ViewState and ControlState are handled as two different values in ASP.NET 2.0 and above. ControlState manages how a control would keep its appearance during Postbacks and therefore a control may still contribute to page size even if EnableViewState is set to false.
  • ViewState does not transfer from one page to another.
  • All Serializable objects can be embeded in ViewState.
  • ControlState cannot be disabled for a control and is used specially in case of custom server controls. (Refer back to Page 192)
  • Hidden Fields may also be used in place of ViewState, except that the Value property of a HiddenField control is not hashed, compressed or chunked nor does it support encryption.
  • Furthermore, HiddenField values would be accessible on server only if page is sent via POST method (and not GET method). So they won't work if user clicks on a Hyperlink on the page.
  • ASP.NET uses Cookies to maintain user sessions.
  • Cookies can be temporary or permanent. To make a Cookie permanent we set its Expire property. To delete a Cookie we may set Expire to a past date.
  • Like Session variables, Cookies need not necessarily be added to the Response.Cookies using Add( ) method. They may also be created using something like
    Response.Cookies["lastvisit"].Value = something;
  • Path property of the HttpCookie class may be used to restrict Cookie access to pages from a specific directory. Similarly, Domain property may be used to restrict Cookie access to a specific domain.
  • Typically, 20 cookies (each of max 4 KB) are allowed per site.
  • A single Cookie may contain multiple Key-Value pairs, e.g.
    Response.Cookies["pref"]["color"] = Color.Blue;
    Response.Cookies["pref"]["lang"] = "en-us";
  • When using QueryStrings, some browsers restrict URL size to 2083 characters which may become a problem. Moreover, QueryStrings require page submission using HTTP GET method.
  • Tip: Always validate values from QueryStrings.
  • QueryStrings provide advantage of maintaining state when users bookmark or email a URL. Typically URL should be limited to 70 characters to enable it to be sent via plain text email.
  • Tip: Always HtmlEncode( ) values from QueryStrings and Cookies, so that client-side scripts may not get processed.
  • Passing HTML code to a QueryString throws HttpRequestValidationException (if not disabled by web server administrator)