Friday, December 28, 2012

Connect to SSMS through other domain-user's Windows Authentication

Usually we have only two options to run the SQL Server Management Studio (SSMS):
1. Windows Authentication
2. SQL Authentication
Ofcourse everyone knows this :)

Obviously, Windows Authentication works with currently logged-in user.
But sometimes, we need to run SSMS with other domain user i.e who had little more permissions than us.

To do so the trick is to Create a shortcut for SSMS as follows:

C:\WINDOWS\system32\runas.exe /user:DOMAIN-NAME\USERNAME /netonly "C:\Program Files\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe"

Provisw domain and username of the user specifically. While opening SSMS, it opens command prompt and concern user's password to be entered.

Thats it, now we can have SSMS opened in another user's Windows Authentication mode.

Hope it helps you too.

Friday, December 21, 2012

Load IIS configured web projects while IIS is not installed in your system

Hi Guys.. 

There could be situation where web applications would be created under IIS and while opening the projects if IIS is not configured or respective virtual directories are not created then we encounter with following error message:

The Web Application Project XXXXXXX is configured to use IIS. The IIS Web server is not installed on this computer.

Solutions:

1. If IIS is installed then create a virtual directory and reload the project.
2. If IIS is not installed in your system , then open the respective .csproj/.vbproj in notepad and modify an XML attribute. i.e. Modify from <IISUrl> to <CustomServerUrl>

E.g. 
<IISUrl> http://localhost/MyWebPrj</IISUrl>
to 
<CustomServerUrl> http://localhost/MyWebPrj </CustomServerUrl>

Now, reload the project. From now on it will work through file system. i.e. http://localhost:xxxx/MyWebPrj

where xxxx = port no.

Hope it helps you.

Cheers.

Thursday, December 13, 2012

Return user control from web service and performance boost details

Great article from Encosia.


1. Boost ASP.NET performance with deferred content loading
2. Creating usercontrol and adding to page control at server from web service method and returning it to consumer.
http://encosia.com/boost-aspnet-performance-with-deferred-content-loading/

Parsing of XML in C# - 5 ways

Parsing of XML in C# - 5 ways


1. Using XmlTextReader class
2. Using LINQ to XML methods
3. Using the XmlReader.Create Method
4. Using the XmlDocument.GetElementsByTagName Method
5. Using Dataset and DataTable Object

For detailed explanation please refer http://www.aspfree.com/c/a/C-Sharp/5-Ways-to-Parse-XML-in-C/

Tuesday, September 4, 2012

Test & Debug WCF service using WCFTestClient.exe


VS.NET 2010 provides WCFTestClient.exe for us to test and debug the WCF service. 
Please follow me to test and debug the service.
Generally, first debug and then test the service, but here first I will tell you how to test it and then how to debug it J

Test the WCF service using WCFTestClient.
1.       Open “Visual Studio Command Prompt (2010)”
2.       Go to “c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\”
3.       Run WcfTestClient.exe
4.       It will open WCF Test Client, now add WCF Service (URL)
5.       Select the service method, from left panel
6.       Provide request data (i.e. values to parameters) on right panel and click on Invoke button. It gives you the response.




Debug the WCF service, follow the commands.
1.       Go to WCF service project properties
2.       Go to Web menu on left menu
3.       Select WcfTestClient.exe from “c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\” for “Start external program”
4.       Provide service in command line arguments, for which the service to be debug.
5.       Place break points on the service source code
6.       Set WCF project as “Startup Project” from properties
7.       Run the project (F5).
8.       Now it will build the project(s), and start debugging the WCF service.





Alternate to Dynamic SQL for Search SPs


Today had a chance to work on ‘Search’ functionality using SQL Server stored procedure. Usually we write dynamic SQL in stored procedure for ‘Search’ing purpose. End user might consider few or all attributes as search criteria. To execute the SQL statement, we use sp_executesql
We have an alternate to dynamic SQL, using simple select query. Below is the sample.

Dynamic SQL Sample:
CREATE PROCEDURE [SearchOffcie]     
(  @OfficeName VARCHAR( 100 )     
 , @OfficeType VARCHAR( 50 )     
 , @Address1 VARCHAR( 100 )     
 , @Address2 VARCHAR( 100 )     
 , @City VARCHAR( 50 )     
 , @State CHAR( 2 )     
 , @OfficeTypeID INT     
 )
AS     
    
BEGIN     
SET NOCOUNT ON 

    DECLARE @SqlQry NVARCHAR( 4000 ) = ''     
    DECLARE @WhereCondition VARCHAR( 200 ) = ''     
    DECLARE @SearchCriteria VARCHAR( 200 ) = ''     
    -- Criteria     
 BEGIN      
  IF @OfficeName <> ''     
   BEGIN     
    SET @SearchCriteria = @SearchCriteria + ' AND Office.OfficeName LIKE ' + CHAR( 39 ) + '%' + @OfficeName + '%' + CHAR( 39 )     
   END     
     
  IF @OfficeType <> ''     
   BEGIN     
    SET @SearchCriteria = @SearchCriteria + ' AND Office.OfficeType LIKE ' + CHAR( 39 ) + '%' + @OfficeType + '%' + CHAR( 39 )     
   END     
     
  IF @Address1 <> ''     
   BEGIN     
    SET @SearchCriteria = @SearchCriteria + ' AND Office.Address1 LIKE ' + CHAR( 39 ) + '%' + @Address1 + '%' + CHAR( 39 )     
   END     
     
  IF @Address2 <> ''     
   BEGIN     
    SET @SearchCriteria = @SearchCriteria + ' AND Office.Address2 LIKE ' + CHAR( 39 ) + '%' + @Address2 + '%' + CHAR( 39 )     
   END     
     
  IF @City <> ''     
   BEGIN     
    SET @SearchCriteria = @SearchCriteria + ' AND Office.City LIKE ' + CHAR( 39 ) + '%' + @City + '%' + CHAR( 39 )     
   END     
     
  IF @State <> ''     
   BEGIN     
    SET @SearchCriteria = @SearchCriteria + ' AND Office.State LIKE ' + CHAR( 39 ) + '%' + @State + '%' + CHAR( 39 )     
   END     
 
 END     
      
 -- Prepare query for dynamic execution based on the given criteria     
    SET @SqlQry = N'     
 SELECT Office.OfficeID     
       , Office.OfficeName     
       , Office.OfficeType     
         , (IsNull(Office.Address1,'''') + '', '' + IsNull(Office.Address2,'''') + '', '' +  Office.City + '', '' + Office.[State] ) [Address]
       , Office.OfficeEMail   
  FROM [MyOfficeDetails] Office WITH (NOLOCK)      
  INNER JOIN [MainOfficesRef] ORCRef WITH (NOLOCK) ON ORCREF.OfficeID = Office.OfficeID   '     
     
 -- Applying criteria
  SET @WhereCondition = ' WHERE 1 = 1 '
  SET @WhereCondition = @WhereCondition + ' AND Office.OfficeType <> 3 '     
  SET @SqlQry = @SqlQry + @WhereCondition     
     
    IF @SearchCriteria <> ''     
        BEGIN     
            SET @SqlQry = @SqlQry + @SearchCriteria     
        END     
     
    -- Execute sql query     
    EXEC sp_executesql @SqlQry     
         
    Select @@ROWCOUNT [ResultCount] 
    -- Record Count  
     
END

Sample on “Alternate to dynamic SQL using simple select”

Note:
1.       Search is of two types –
a.       Specific search – exact values should match
b.       Contains search – given value could match on the column somewhere. i.e. Name like ‘%Srinivas%’
2.       So we had an assumption that, end user will either prepend or append ‘%’ for Contains search.
 
CREATE PROCEDURE [SearchOffice1]     
(  @OfficeName VARCHAR(100)     
 , @OfficeType VARCHAR(50)     
 , @Address1 VARCHAR(100)     
 , @Address2 VARCHAR(100)     
 , @City VARCHAR(50)     
 , @State CHAR(2)     
 , @OfficeTypeID INT     
 , @MaxRecordCountToReturn INT = 50
 , @MessageToUser NVARCHAR(MAX) = '' OUTPUT )     
AS  
BEGIN     
  
 DECLARE @Spacer Varchar(1)= SPACE(0) 
 DECLARE @ResultSetCount BIGINT =
 SET NOCOUNT ON 
 
  SELECT TOP (@MaxRecordCountToReturn) 
      O.[OfficeID] 
     ,O.[OfficeTypeID] 
     ,O.[OfficeName] 
     ,ISNULL(O.[OfficeType],@Spacer) [OfficeType] 
     ,(IsNull(O.Address1,'') + ', ' + IsNull(O.Address2,'') + ', ' +  O.City + ', ' +  
     O.[State]) [Address]       
     ,ISNULL(O.[OfficeEMail],@Spacer) [OfficeEMail] 
     ,OST.OfficeStatusTypeDesc 
  FROM  
    [Office] O WITH (NOLOCK) 
    INNER JOIN [OfficeRegionCrossRef] ORCR WITH (NOLOCK) ON O.OfficeID=ORCR.OfficeID
     
    AND (O.[OfficeName] LIKE @OfficeName OR @OfficeName IS NULL) 
    AND (O.[OfficeType] LIKE @OfficeType OR @OfficeType IS NULL) 
    AND (O.[Address1] LIKE @Address1 OR @Address1 IS NULL) 
    AND (O.[Address2] LIKE @Address2 OR @Address2 IS NULL) 
    AND (O.[City] LIKE @City OR @City IS NULL) 
    AND (O.[State] LIKE @State OR @State IS NULL) 
     
  ORDER BY O.DateCreated DESC
   
  SET @ResultSetCount = @@ROWCOUNT 
   
  IF (@MaxRecordCountToReturn>0) -- A VALUE OF 0 INDICATES RETURN ALL ROWS 
    IF (@ResultSetCount>@MaxRecordCountToReturn) 
     SET @MessageToUser = 'Attention: Search results exceed the maximum defined threshold. Please refine your search criteria' 
     --RAISERROR ('Error: Search results exceed the maximum defined threshold. Please refine your search criteria', 16, 1 ) 
END

-- Thanks to my collegue.

Friday, August 24, 2012

Anti ForgeryToken in ASP.NET MVC


To prevent Cross-Site Request Forgery (CSRF) in ASP.NET MVC applications we use AntiForgeryToken () helper.
Before that, we’ll have a look on how CSRF works

Imagine you have an ASP.NET MVC’s controller class as follows

public class UserProfileController : Controller
{
    public ViewResult Edit() { return View(); }
       public ViewResult SubmitUpdate()
    {
        // Get the user's existing profile data (implementation omitted)
        ProfileData profile = GetLoggedInUserProfile();
        // Update the user object
        profile.EmailAddress = Request.Form["email"];
        profile.FavoriteHobby = Request.Form["hobby"];
        SaveUserProfile(profile);
        ViewData["message"] = "Your profile was updated.";
        return View();
    }
}

This is all very normal. First, the visitor goes to Edit(), which renders some form to let them change their user profile details. Secondly, they post that form to SubmitUpdate(), which saves the changes to their profile record in the database. There’s no XSS vulnerability here. We implement this sort of thing all the time.

Imagine that an attacker sets up the following HTML page and hosts it on some server of their own:
 
<body onload="document.getElementById('fm1').submit()">
    <form id="fm1" action="http://yoursite/UserProfile/SubmitUpdate" method="post">
        <input name="email" value="hacker@somewhere.evil" />
        <input name="hobby" value="Defacing websites" />
    </form>
</body>

When this HTML page loads, it submits a valid form post to /UserProfile/SubmitUpdate on your server. Assuming you’re using Windows authentication or some kind of cookie-based authentication system such as Forms Authentication, the automated form post will be processed within the victim’s established authentication context, and will successfully update the victim’s email address to something under the attacker’s control. All the attacker has to do now is use your “forgotten password” facility, and they’re taken control of the victim’s account.

Ways to stop CSRF

1.       Check that incoming requests have a Referer header referencing your domain. This will stop requests unwittingly submitted from a third-party domain.

2.       Put a user-specific token as a hidden field in legitimate forms, and check that the right value was submitted. Instead, it’s better to use some random value (such as a GUID) which you’ve stored in the visitor’s Session collection or into a Cookie.

We can implement security while we submit the ASP.NET MVC Page to the server. For this, ASP.NET MVC provides an excellent mechanism to prevent CSRF, i.e., Anti Forgery Token:

  • The server prints tokens to cookie and inside the form
  • When the form is submitted to server, token in cookie and token inside the form (hidden type) are sent in the HTTP request
  • Server validates the tokens

HtmlHelper.AntiForgeryToken()would be used to generate a token inside the form and also writes it to Cookie.


<% using(Html.Form("UserProfile", "SubmitUpdate")) { %>
    <%= Html.AntiForgeryToken() %>
   
<% } %>

HTML source
<form action="/UserProfile/SubmitUpdate" method="post">
    <input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
    <!-- rest of form goes here -->
</form>


At the same time, Html.AntiForgeryToken() will give the visitor a cookie called __RequestVerificationToken, with the same value as the random hidden value shown above

When the form is submitted, cookie and the hidden value are both sent to server.

On the server side, [ValidateAntiForgeryToken] attribute is used to specify the controllers or actions to validate them

[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
    …..
}

Authorization filter that checks that:

·         The incoming request has a cookie called __RequestVerificationToken
·         The incoming request has a Request.Form entry called __RequestVerificationToken
·         These cookie and Request.Form values match

Assuming all is well, the request goes through as normal. But if not there’s an authorization failure with message “A required anti-forgery token was not supplied or was invalid”.

        [ValidateAntiForgeryTokenWrapper(HttpVerbs.Post)]
        [AcceptVerbs(HttpVerbs.Post)]
        public ActionResult FarmingResults(FarmingRequestData data)
        {
            return this.GetFarmingResults(data);
        }
 
One single [ValidateAntiForgeryToken] attribute is expected to declare on controller, but actually a lot of attributes have be to declared on controller's each POST actions. Because POSTactions are usually much more than controllers

 
    [ValidateAntiForgeryTokenWrapper(HttpVerbs.Post)]
    public partial class DivisionAdminController : SecureController
    {
        private const string DIVISION_VIEW = "Division";
        private const string MASTERLIST_VIEW = "MasterProductList";
       . . . .

Usually a controller contains both actions for HTTP GET requests and actions for POST, and, usually validations are expected for only HTTP POST requests. So, if the [ValidateAntiForgeryToken] is declared on the controller, the HTTP GET requests become invalid


To avoid a large number of [ValidateAntiForgeryToken] attributes (one for each POST action), the following ValidateAntiForgeryTokenWrapperAttribute wrapper class can be helpful, where HTTP verbs (GET and POST) can be specified.


File path: Source\PresentationFramework\Security\ValidateAntiForgeryTokenWrapperAttribute.cs

namespace PresentationFramework.Security
{
    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple=false, Inherited=true)]
    public class ValidateAntiForgeryTokenWrapperAttribute : FilterAttribute, IAuthorizationFilter
    {
       private readonly ValidateAntiForgeryTokenAttribute _validator;
       private readonly AcceptVerbsAttribute _verbs;

        public ValidateAntiForgeryTokenWrapperAttribute(HttpVerbs verbs)
            : this(verbs, null)
        {
        }
.. . . . .  . .

Please refer the above file for complete code.
Due to above code, GET actions are not affected. Only HTTP POST requests are validated.

In case you want to protect multiple forms in your application independently of each other, you can use a “salt” value when you call Html.AntiForgeryToken(),
<%= Html.AntiForgeryToken("Some_String_Srinivas") %>


[ValidateAntiForgeryToken(Salt="Some_String_Srinivas")]
public ViewResult SubmitUpdate()
{
    // ... etc
}

Salt is just an random string. A different salt value means a different anti-forgery token will be generated. This means that even if an attacker manages to get hold of a valid token somehow, they can’t reuse it in other parts of the application where a different salt value is required.

By default, the salt should be a compile time constant, so it can be used for the [ValidateAntiForgeryToken] or [ValidateAntiForgeryTokenWrapper] attribute.

Non-constant Salt in Runtime
One Web product might be sold to many clients. If a constant salt is evaluated in compile time, after the product is built and deployed to many clients, they all have the same salt. Of course, clients do not like this. Some clients might even expect a configurable custom salt. In these scenarios, salt is required to be a runtime value.

As mitigation, we pass Salt parameter in ValidateAntiForgeryTokenWrapperAttribute’s constructor

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple=false, Inherited=true)]
    public class ValidateAntiForgeryTokenWrapperAttribute : FilterAttribute, IAuthorizationFilter
    {
        private readonly ValidateAntiForgeryTokenAttribute _validator;
        private readonly AcceptVerbsAttribute _verbs;

        public ValidateAntiForgeryTokenWrapperAttribute(HttpVerbs verbs)
            : this(verbs, null)
        {
        }

        public ValidateAntiForgeryTokenWrapperAttribute(HttpVerbs verbs, string salt)
        {

           this._verbs = new AcceptVerbsAttribute(verbs);
            this._validator = new ValidateAntiForgeryTokenAttribute()
            {
               Salt = salt
            };
        }
. . . .

AJAX calls through jQuery

Basically, the tokens must be printed to browser then sent back to server. So first of all,HtmlHelper.AntiForgeryToken() need to be called somewhere. Now the browser has token in both HTML and cookie.

jQuery must find the printed token in the HTML, and append token to the data before sending:

function DeletePropertyProduct(state, gProductPriceID) {
    $.post(_deletePropertyFees, { State: state, ProductPriceID: gProductPriceID, __RequestVerificationToken: getAntiForgeryToken() },
              function (data) {
                  $("#PropertyFeesContainer").html(data);
              }
       );

To reuse the same, this can be encapsulated into a separate jQuery plugin as below (Reference: http://www.codeproject.com/Articles/267694/Security-in-ASP-NET-MVC-by-using-Anti-Forgery-Toke)

/// 
 
(function ($) {
    $.getAntiForgeryToken = function (tokenWindow, appPath)
    {
    tokenWindow = tokenWindow &&
    typeof tokenWindow === typeof window ? tokenWindow : window;
    appPath = appPath && typeof appPath === "string" ? "_" + appPath.toString() : "";
    var tokenName = "__RequestVerificationToken" + appPath;
    var inputElements = tokenWindow.document.getElementsByTagName("input");
        for (var i = 0; i < inputElements.length; i++) {
         var inputElement = inputElements[i];
           if (inputElement.type === "hidden" && inputElement.name === tokenName) {
               return {
                 name: tokenName,
                    value: inputElement.value
                   };
                }
              }
       };
 
    $.appendAntiForgeryToken = function (data, token) {
    if (data && typeof data !== "string")
      {
           data = $.param(data);
     }
 
     // Gets token from current window by default.
      token = token ? token : $.getAntiForgeryToken();
     // $.getAntiForgeryToken(window).
 
      data = data ? data + "&" : "";
     // If token exists, appends {token.name}={token.value} to data.
     return token ? data + encodeURIComponent(token.name) + 
                 "=" + encodeURIComponent(token.value) : data;    };
 
    // Wraps $.post(url, data, callback, type) for most common scenarios.
    $.postAntiForgery = function (url, data, callback, type) {
    return $.post(url, $.appendAntiForgeryToken(data), callback, type);
  };
 
    // Wraps $.ajax(settings).
  $.ajaxAntiForgery = function (settings) {
     var token = settings.token ? settings.token : 
         $.getAntiForgeryToken(settings.tokenWindow, settings.appPath);
     settings.data = $.appendAntiForgeryToken(settings.data, token);
      return $.ajax(settings);
   };})(jQuery);

In most of the scenarios, it is Ok to just replace $.post() invocation with $.postAntiForgery(), and replace$.ajax() with $.ajaxAntiForgery():

$.postAntiForgery(url, {
  productName: "Tofu",    categoryId: 1}, callback);
 // The same usage as $.post(), but token is posted. 

There might be some scenarios of custom token, where $.appendAntiForgeryToken() is useful:

data = $.appendAntiForgeryToken(data, token);
// Token is already in data. No need to invoke
$.postAntiForgery().$.post(url, data, callback);

And there are special scenarios that the token is not in the current window. For example:

  • An HTTP POST request can be sent from an iframe, while the token is in the parent window or top window;
  • An HTTP POST request can be sent from an popup window or a dialog, while the token is in the opener window;

data = $.appendAntiForgeryToken(data, $.getAntiForgeryToken
         (window.parent));// Token is already in data. 
         // No need to invoke $.postAntiForgery().$.post(url, data, callback);

 

$.ajaxAntiForgery({
    type: "POST",    url: url,    data: {
      productName: "Tofu", categoryId: 1    },   success: callback,
 // The same usage as $.ajax(), supporting more options.
   tokenWindow: window.parent
// Token is in another window.});

Limitations of the Anti-Forgery helpers

1.    All genuine users must accept cookies

2.    It only works with POST requests, not GET requests

http://blog.stevensanderson.com/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
http://www.codeproject.com/Articles/267694/Security-in-ASP-NET-MVC-by-using-Anti-Forgery-Toke