Friday, 31 August 2012

Difference between interface and abstract class in C#

Abstract Class:

An abstract class is a special kind of class that cannot be instantiated. So the question is why we need a class that cannot be instantiated? An abstract class is only to be sub-classed (inherited from). In other words, it only allows other classes to inherit from it but cannot be instantiated. The advantage is that it enforces certain hierarchies for all the subclasses. it is a kind of contract that forces all the subclasses to carry on the same hierarchies or standards.

Interface:

An interface is not a class. It is an entity that is defined by the word Interface. An interface has no implementation; it only has the signature or in other words, just the definition of the methods without the body.
As one of the similarities to Abstract class, it is a contract that is used to define hierarchies for all subclasses or it defines specific set of methods and their arguments. The main difference between them is that a class can implement more than one interface but can only inherit from one abstract class.
Since C# doesn’t support multiple inheritance, interfaces are used to implement multiple inheritance.

Both Together:

When we create an interface, we are basically creating a set of methods without any implementation that must be overridden by the implemented classes. The advantage is that it provides a way for a class to be a part of two classes: one from inheritance hierarchy and one from the interface.
When we create an abstract class, we are creating a base class that might have one or more completed methods but at least one or more methods are left uncompleted and declared abstract. If all the methods of an abstract class are uncompleted then it is same as an interface. The purpose of an abstract class is to provide a base class definition for how a set of derived classes will work and then allow the programmers to fill the implementation in the derived classes.

#
Feature
Interface
Abstract class
1
Multiple inheritance
A class may inherit several interfaces.
A class may inherit only one abstract class.
2
Default implementation
An interface cannot provide any code, just the signature.
An abstract class can provide complete, default code and/or just the details that have to be overridden.
3
Access Modfiers
An interface cannot have access modifiers for the subs, functions, properties etc. everything is assumed as public
An abstract class can contain access modifiers for the subs, functions, properties
4
Core VS Peripheral
Interfaces are used to define the peripheral abilities of a class. In other words both Human and Vehicle can inherit from a IMovable interface.
An abstract class defines the core identity of a class and there it is used for objects of the same type.
5
Homogeneity
If various implementations only share method signatures then it is better to use Interfaces.
If various implementations are of the same kind and use common behavior or status then abstract class is better to use.
6
Speed
Requires more time to find the actual method in the corresponding classes.
Fast
7
Adding functionality (Versioning)
If we add a new method to an Interface then we have to track down all the implementations of the interface and define implementation for the new method.
If we add a new method to an abstract class then we have the option of providing default implementation and therefore all the existing code might work properly.
8
Fields and Constants
No fields can be defined in interfaces
An abstract class can have fields and constants defined


Friday, 3 August 2012

Forms Authentication and Authorization in Web.config



Authentication is necessary to almost every application. ASP.NET brings different Authentication Providers to make the authentication process easier.
Among them, Forms-based authentication is the most often used one. With Forms Authentication, we create a login form with the logic to validate a user and .NET will create a Cookie on successful validation which the application will check for on each client request.
With Forms Authentication, we can configure the name of the cookie to use, the protection type, the URL to use for the loginUrl, the length of time (minutes) the cookie is in effect, and the path to use for the issued cookie. If no cookie name is specified, the default is .ASPXAUTH. The loginUrl is the location of the Login form and to which any unauthenticated requests for protected resources will be automatically redirected.
<configuration>
<system.web>
<authentication mode="Windows|Forms|Passport|None">
   <forms name="name"
          loginUrl="url" 
          protection="All|None|Encryption|Validation"
          timeout="30" 
          path="/" 
          requireSSL="true|false"
          slidingExpiration="true|false">
      <credentials passwordFormat="Clear|SHA1|MD5">
         <user name="username" password="password"/>
      </credentials>
   </forms>
   <passport redirectUrl="internal"/>
</authentication>
</system.web>
</configuration>
ASP.NET also allows us to define login credentials in the Web.config file and Authenticate against them using the Authenticate() method of the FormsAuthentication provider.
Configures ASP.NET authorization support. The <authorization> tag controls client access to URL resources.
<configuration>
<system.web>
<authorization>
   <allow users="comma-separated list of users"
          roles="comma-separated list of roles"
          verbs="comma-separated list of verbs"/>
 
   <deny users="comma-separated list of users"
         roles="comma-separated list of roles"
         verbs="comma-separated list of verbs"/>
</authorization>
</system.web>
</configuration>
users: A comma-separated list of user names that are granted access to the resource. A question mark (?) allows anonymous users; an asterisk (*) allows all users.
roles: A comma-separated list of roles that are granted access to the resource.
verbs: A comma-separated list of HTTP transmission methods that are granted access to the resource. Verbs registered to ASP.NET are GET, HEAD, POST, and DEBUG.

We only consider this way if there are a relatively small number of users; or else we’d better authenticate a user against a database of user credentials.
<system.web>
    <authentication mode="Forms">    
      <forms name="MyLoginCookie" loginUrl="Login.aspx" protection="All" timeout="30" path="/">       
        <credentials passwordFormat="Clear">
          <user name="ravi" password="ravi" />
          <user name="raman" password="raman"/>
          <user name="raj" password="raj"/>
        </credentials>

        <!--<credentials passwordFormat="MD5">
          <user name="ravi" password="63dd3e154ca6d948fc380fa576343ba6" />
          <user name="raman" password="3e8961306a7d9c49c15e97d4943b2529"/>
          <user name="raj" password="3e8961306a7d9c49c15e97d4943b2529"/>
        </credentials>-->

        <!--<credentials passwordFormat="SHA1">
          <user name="ravi" password="aa153b5d1fcb55096034df7a27565f4297f195d2" />
          <user name="raman" password="a70152cf6bb9e9e0bacb875e74416ebebf1f8ea4"/>
          <user name="raj" password="3055effa054a24f84cf42cea946db4cdf445cb76"/>
        </credentials>-->
      </forms>         
    </authentication>
  </system.web>

If we want to deny access to anonymous users, configure the Authorization section in the following manner:
<system.web>
    <authorization>
      <allow users="ravi"/>
      <deny users="raj"/>
    </authorization>
  </system.web>

Login.aspx.cs
protected void btnLogin_Click(object sender, EventArgs e)
{
        if (FormsAuthentication.Authenticate(txtUserName.Text, txtPassword.Text))
        {
            FormsAuthentication.SetAuthCookie(txtUserName.Text, false);
            FormsAuthentication.RedirectFromLoginPage(txtUserName.Text, false);
            Response.Redirect("ValidatedPage.aspx");
        }
        else
        {
            Response.Write("Invalid credential.");
        }
}

ValidatedPage.aspx.cs
protected void Page_Load(object sender, EventArgs e)
{
        if (User.Identity.IsAuthenticated == false)
        {           
            Response.Redirect("Login.aspx");
        }
        else
        {
            lblUserName.Text = User.Identity.Name;
        }
}

protected void btnLogout_Click(object sender, EventArgs e)
{
        FormsAuthentication.SignOut();
        FormsAuthentication.RedirectToLoginPage();
}