Caveman's Blog

My commitment to learning.

Posts Tagged ‘ASP.Net

File upload – attachment size validation

with one comment


Restricting the size of a file upload is an important validation that needs to be performed by an online application so avoid the risk of filling up the server disk space by a malicious intent. ASP.Net provides an upload control that only provides a server side validation of file size. By the time the control validates the size of the uploaded file, the physical file would have been already been copied to the server, which is tool late in avoiding the issue.

Client side technologies comes to the rescue in this scenario, where the validation of an attachment size can be implemented using a browser run-time like Flash, Silverlight, ActiveX, HTML5 etc. This way, if attempts were made to upload files with unsupported sizes, the run-time plug-in can thwart the attempt without any impact on your web server. Following are two free tools that can be employed for this purpose:

  • SWFUpload is a flash based tool.
  • PLUpload is a versatile plugin that can support multiple run-times. This plugin slices a large file in small chunks and will send them out one by one to the server. You can then safely collect them on the server and combine into the original file. The size of the chunks and the acceptable file formats can be defined in the plugin UI definition.

We have implemented PLUpload with good success. This plugin also support multiple file uploads. Visit the plugin homepage to see the other rich features that are supported. The online forum is a treasure trove, where you can find the various implementations, code snippets and will be able to participate in contributing to the community.

PLUpload

References:
1. SWFUpload
2. PLUpload
3. PLUpload Forums

Written by cavemansblog

February 20, 2013 at 10:02 am

Factoring the Web.Config

with one comment


Web.Config is a XML document file in a ASP.Net application that is used to store configuration settings related to the web application. The web.config file contains information about database configuration, control module loading, security configuration, session state configuration, Custom configuration and compilation settings. Each web application in ASP.Net inherits their base web.config from the machine’s web.config located in %SystemRoot%\Microsoft.Net\Framework\v#.#.#.#\CONFIG. The applications own web.config is physically located at the root of the web application and sub directories inherit the configuration setting unless they have their own web.config with in the respective sub-directories.

Usually as the application size grows, so does the number of settings and the size of the web.config file. The settings in config file become so many that it will be pretty tough to manage them and also hard to read. There is one less known optional string attribute called “ConfigSource” that specifies the name of the include file in which the associated configuration section is defined, if such a file exists. The configsource attribute was introduced in .NET Framework 2.0 to support external configuration files. This attribute can be added to any configuration section to specify a an external file for that section. Following is an example of a before and after scenario for using the configsource attribute. This example demonstrates how the database connection settings can be separated into an external config file:

Before:

<configuration>
    <configSections>
        <section name="ConnectionStrings" restartOnExternalChanges="false"/>
    </configSections>
    <connectionStrings>
        <add name=“Inventory” connectionString=“Database=MYINVENTORYDB;Server=<SERVER-NAME>;User ID=<USERNAME>;Password=<PASSWORD>;Trusted_Connection=False;” providerName=“System.Data.SqlClient”/>
    </connectionStrings>
.
.
<configuration>

After:

Following are two sections from the web.config and the dbsetting.config files. The dbsettings.config file has the database connection configuration information.

web.config

<configuration>
    <configSections>
        <section name="ConnectionStrings" restartOnExternalChanges="false"/>
    </configSections>
    <connectionStrings configSource="dbsettings.config">

      </connectionStrings>
.
.
<configuration>

dbsettings.config

<configuration>
    <connectionStrings>
        <add name=“Inventory” connectionString=“Database=MYINVENTORYDB;Server=<SERVER-NAME>;User ID=<USERNAME>;Password=<PASSWORD>;Trusted_Connection=False;” providerName=“System.Data.SqlClient”/>
    </connectionStrings>
</configuration>

Example 2

Here is another example of separating the database configuration settings into multiple files. These settings are for Enterprise Library External file configuration source for Application blocks. Following are the sections of the web.config and the entlib.config files into which the database Connection string configuration has been separated:

Web.Config

<enterpriseLibrary.ConfigurationSource selectedSource=“File Configuration Source”>
    <sources>
        <add name=“File Configuration Source” type=“Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=X.X.X.X, Culture=neutral, PublicKeyToken=null” filePath=“entlib.config”/>
    </sources>
</enterpriseLibrary.ConfigurationSource>

entlib.config

<configuration>
    <connectionStrings>
        <add name=“Inventory”connectionString=“Database=MYINVENTORYDB;Server=<SERVER-NAME>;User  ID=<USERNAME>;Password=<PASSWORD>;Trusted_Connection=False;” providerName=“System.Data.SqlClient”/>
    </connectionStrings>
</configuration>

The end result is that this feature of web.config file has been very useful to me so far in keeping the config files neat and simple to read. Also note that the restartOnExternalChanges property is set to false in the “section element for config sections” so that the application does not restart when a change to the external config file is made.

Tip: ConnectionStrings.com has nice list of connection strings for various databases.

References:

1. MSDN Online

Written by cavemansblog

June 4, 2009 at 2:39 pm

State Management in ASP.NET

with 2 comments


Web form pages are HTTP-Based, they are stateless, which means they don’t know whether the requests are all from the same client, and pages are destroyed and recreated with each round trip to the server, therefore information will be lost, therefore state management is really an issue in developing web applications. We could easily solve these problems in ASP with cookie, query string, application, session and so on. Now in ASP.NET, we still can use these functions, but they are richer and more powerful, so let’s dive into it.

Mainly there are two different ways to manage web page’s state

  • Client-side
  • Server-side

Client-side state management

There is no information maintained on the server between round trips. Information will be stored in the page or on the client’s computer.

1) Cookies

A cookie is a small amount of data stored either in a text file on the client’s file system or in-memory in the client browser session. Cookies are mainly used for tracking data settings. Let’s take an example: say we want to customize a welcome web page, when the user request the default web page, the application first to detect if the user has logined before, we can retrieve the user information from cookies.

//to create a cookie variable
Response.Cookies[“username”].Value=name;

//to access a cookie variable
Request.Cookies[“username”].Value

2) Hidden Field

A hidden field does not render visibly in the browser, but you can set its properties just as you can with a standard control. When a page is submitted to the server, the content of a hidden field is sent in the HTTP Form collection along with the values of other controls. A hidden field acts as a repository for any page-specific information that you would like to store directly in the page. Hidden field stores a single variable in its value property and must be explicitly added it to the page. ASP.NET provides the HtmlInputHidden control that offers hidden field functionality.

protected System.Web.UI.HtmlControls.HtmlInputHidden Hidden1;//to assign a value to Hidden fieldHidden1.Value=”this is a test”;//to retrieve a value string str=Hidden1.Value;

Note: Keep in mind, in order to use hidden field, you have to use HTTP-Post method to post web page. Although its name is ‘Hidden’, its value is not hidden, you can see its value through ‘view source’ function.

C. View State

Each control on a Web Forms page, including the page itself, has a ViewState property, it is a built-in struture for automatic retention of page and control state, which means you don’t need to do anything about getting back the data of controls after posting page to the server. Here, which is useful to us is the ViewState property, we can use it to save information between round trips to the server.

//to save informationViewState.Add(“shape”,”circle”);//to retrieve informationstring shapes=ViewState[“shape”];

Note: Unlike Hidden Field, the values in ViewState are invisible when ‘view source’, they are compressed and encoded.

D.Query Strings

Query strings provide a simple but limited way of maintaining some state information.
You can easily pass information from one page to another, But most browsers and client devices impose a 255-character limit on the length of the URL. In addition, the query values are exposed to the Internet via the URL so in some cases security may be an issue.

This is an article in its entirity has been posted on http://www.csharphelp.com/ by Eric Zheng. I am reposting this on my blog since it is very well written and is very useful.

Reference:
1. http://www.csharphelp.com/archives/archive207.html – Eric Zheng

Written by coolgirlsblog

January 31, 2008 at 12:20 am