Model binding for HTTP GET requests

We are going to learn how to pass data in ASP.NET Core using Model binding for HTTP GET request. The GET method is generally used for less complex and non-sensitive data transfer.

The model binding refers to converting the HTTP request data (from the query string or form collection) to an action methods parameter. These parameters can be of primitive type or complex type.

We will be using Visual Studio 2022 for this test. We are going to use following modal in this exercise;

    public class Project
    {
        public int Id { get; set; }

        public ProjectIdentity? ProjectIdentity { get; set; }
    }

    public class ProjectIdentity
    {
        public int Id { get; set; }

        public int ModificationId { get; set; }
    }

First test case – Primitive Type

The HTTP GET request embeds data into a query string. MVC framework automatically converts a query string to the action method parameters provided their names are matching.

For example;

Create a new project using MVC template in Visual Studio. Don’t make any changes to the default; Make sure jQuery works. Add following to index.cshtml page;

@section scripts {
    <script type="text/javascript">
    var sample;

    $(function () {
        console.log("ready!");
    });
    }
    </script>
}

Run the project. You should be seeing “ready!” in browser console window. We are ready to do our Get Tests now using jQuery Ajax.

Add an HTML button with onclick event;

<div><button type="button" class="btn btn-primary" onclick="sample.OnButtonClick();">Get Request</button></div>

Create Sample class with onclick event and an instance of Sample class in jQuery ready function;

class Sample
 {
     constructor() { }

     OnButtonClick()
     {
             $.ajax({
                 type: 'GET',
                 url: "@Url.Action("GetInfoPrimitive", "Home")",
                 dataType: 'json',
                 contentType: 'application/json',
                 data: {"ProjectId":"1"},

                 success: function (result) {
                     alert('Data submitted.');
                     console.log(result);
                 },
                 failure: function (result) {
                     alert("Something went wrong. Plese contact System Administrator.");
                     console.log(result);
                 }
             });
     }
 }

Our complete jQuery function would look like this;

@section scripts {
    <script type="text/javascript">
    var sample;

    $(function () {
        console.log("ready!");
        sample = new Sample();
    });

    class Sample
    {
        constructor() { }

        OnButtonClick()
        {
                $.ajax({
                    type: 'GET',
                    url: "@Url.Action("GetInfoPrimitive", "Home")",
                    dataType: 'json',
                    contentType: 'application/json',
                    data: {"ProjectId":"1"},

                    success: function (result) {
                        alert('Data submitted.');
                        console.log(result);
                    },
                    failure: function (result) {
                        alert("Something went wrong. Plese contact System Administrator.");
                        console.log(result);
                    }
                });
        }
    }
    </script>
}

We need to create a method on server side that will be called by Ajax method;

[HttpGet]
        public int GetInfoPrimitive(int projectId)
        {
            Console.WriteLine($"Incoming parameter value: {JsonSerializer.Serialize(projectId)}");
            return projectId;
        }

Put a breakpoint on “return projectId” line. Run the app and click on Get Request button.

The debugger should stop on “return projectId” statement and console results would be like this;

Click continue to resume the application. There is no problem with this method.

Second test case – Binding to Complex Type

Model binding also works on complex types. It will automatically convert the input fields data on the view to the properties of a complex type parameter of an action method in HttpGet request if the properties’ names match with the fields on the view.

For example;

The only change in earlier example code is that we are going to pass an object to the view and would use that object to submit Get request;

        public IActionResult Index()
        {
            var request = new ProjectIdentity();
            return View(request);
        }
       [HttpGet]
       public ProjectIdentity GetInfoComplex(ProjectIdentity request)
       {
           Console.WriteLine($"Incoming parameter value: {JsonSerializer.Serialize(request)}");
           return request;
       }

This is the change on Javascript side;

OnButtonClick()
 {
         $.ajax({
             type: 'GET',
             url: "@Url.Action("GetInfoComplex", "Home")",
             dataType: 'json',
             contentType: 'application/json',
             data: {"Id":"1", "ModificationId": "100"},

             success: function (result) {
                 alert('Data submitted.');
                 console.log(result);
             },
             failure: function (result) {
                 alert("Something went wrong. Plese contact System Administrator.");
                 console.log(result);
             }
         });
 }

Put a breakpoint on “return request;” and run the app. Here is the output;

Third test case – Binding to nested Complex Type

Let’s add a nested class inside parent class and run the same method;

//here is the problem. GET request will ignore nested object mapping
        [HttpGet]
        public Project GetInfo(Project request)
        {
            Console.WriteLine($"Incoming parameter value: {JsonSerializer.Serialize(request)}");
            return request;
        }
   

Change on client side;

OnButtonClick()
       {
               $.ajax({
                   type: 'GET',
                   url: "@Url.Action("GetInfo", "Home")",
                   dataType: 'json',
                   contentType: 'application/json',
                   data: { "Id": "1", "ProjectIdentity": { "Id": "11", "ModificationId": "100" } },

                   success: function (result) {
                       alert('Data submitted.');
                       console.log(result);
                   },
                   failure: function (result) {
                       alert("Something went wrong. Plese contact System Administrator.");
                       console.log(result);
                   }
               });
       }

The output would be;

So how we can fix this problem in GET request? Auto mapping will not work and in this case we need to be implicit to map the properties. Here is how;

       //this is how to solve for GET request
       [HttpGet]
       public Project GetInfoFixed(
               [FromQuery(Name = "Id")] int ProjectId,
               [FromQuery(Name = "ProjectIdentity[Id]")] int ProjectIdentityId,
               [FromQuery(Name = "ProjectIdentity[ModificationId]")] int? ProjectModificationId)
       {
           var response = new Project() { Id = ProjectId, ProjectIdentity = new ProjectIdentity() { Id = ProjectIdentityId, ModificationId = ProjectModificationId.Value } };
           Console.WriteLine($"Incoming parameter value: {JsonSerializer.Serialize(response)}");
           return response;
       }
        

Client side change;

OnButtonClick()
        {
                $.ajax({
                    type: 'GET',
                    url: "@Url.Action("GetInfoFixed", "Home")",
                    dataType: 'json',
                    contentType: 'application/json',
                    data: { "Id": "1", "ProjectIdentity": { "Id": "11", "ModificationId": "100" } },

                    success: function (result) {
                        alert('Data submitted.');
                        console.log(result);
                    },
                    failure: function (result) {
                        alert("Something went wrong. Plese contact System Administrator.");
                        console.log(result);
                    }
                });
        }

Here is the result;

We are able to create full object graph this time.

Conclusion

As you have seen, that the ASP.NET MVC framework automatically converts request values into a primitive or complex type object. Model binding is a two-step process. First, it collects values from the incoming HTTP request, and second, it populates primitive type or a complex type with these values.

Value providers are responsible for collecting values from requests, and Model Binders are responsible for populating values.

By default, the HTTP methods GETHEADOPTIONS, and DELETE do not bind data implicitly from the request body. To bind data explicitly from the request body, marked as JSON, for these methods, we can use the [FromBody] attribute. Also, we can use the [FromQuery] attribute.

Use POST for destructive actions such as creation (I’m aware of the irony), editing, and deletion, because you can’t hit a POST action in the address bar of your browser. Use GET when it’s safe to allow a person to call an action. So a URL like:

http://myblog.org/admin/posts/delete/357

Should bring you to a confirmation page, rather than simply deleting the item. It’s far easier to avoid accidents this way.

Resources

https://learn.microsoft.com/en-us/aspnet/core/mvc/models/model-binding?view=aspnetcore-7.0#simp7

Web Application Authentication

Launch browser. Enter username password. Log in. Done. How hard could it be? This is a challenge I run into when I talk about security and identity. My demos are so boring, because after all that jazz, you see “Hello username” written in Times New Roman. It really punctures the demo, doesn’t it?

As it turns out, authentication can be quite involved. And it’s still evolving every day because this boundary to your application is under duress, constantly, and our enemies are getting smarter. That’s what this article is about. And although I’ll talk generically and stick to general concepts, I’ll use Azure AD as an example.

A Long Time Ago

A long time ago when the internet was nascent, we used a text-based browser called Lynx. There were other mechanisms to access information on the internet too. There was this protocol called SMTP, which is still widely used today. Did you know that SMTP existed basically as an unauthenticated protocol for almost three decades? All it took was understanding the protocol and Telnetting to the SMTP server, and you could send email as anyone. Boy, did I have some fun with that.

I used to wonder, how could this be so simple? I could set up three email addresses, A, B, and C. A forwards to B and C. B forwards to A and C, and C being the email address. Now, I could just initiate an unauthenticated email to A, and C will get overwhelmed by email messages causing old-style DDOS (distributed denial of service), and you know what? It worked. This is how insecure the internet used to be not too long ago. Frankly, with a slight modification, you could defeat inboxes even today.

This is what keeps me up at night. The internet, still, feels very flimsy, and thanks to my unimpressive demos, almost nobody cares about security in a project. It’s all about deadlines and features, and security is just an inconvenience to get past.

A very long time ago, we invented an authentication protocol called basic authentication. This was just sending the username password over the wire in a header. We tried to secure it using HTTPS, but plenty of governments and organizations can sniff HTTPS traffic as a man-in-the-middle. So we came up with NT Lan Manager version 1 (NTLMv1), which was easily defeatable. Followed by NTLMv2, which was better and is still in wide usage today but has plenty of shortcomings. And perhaps the most common legacy protocol in widespread use today is Kerberos. Kerberos relies on a central authority and plenty of network chit chat, so it didn’t scale to the internet.

As these dinosaur protocols roamed the earth, a meteorite called the internet came by to spoil their party. Organizations tried to solve the puzzle by using VPNs and trust relationships between active directories, but you can’t survive a direct hit from a meteorite like the internet. Well, to be precise, some dinosaurs survived. I mean we still have crocs and gators around us, right? Kerberos still has a place on your intranet. But we needed something different, something that focused on the internet.

WS-Fed and SAML

In the early 2000s, the WS-* standards started taking shape. One of these was WS-Fed, and with it came SAML, security assertion markup language. SAML is an XML packet format. In the early 2000s, accessing the internet was either through a website, i.e., a browser on your desktop, or via protocols such as FTP, Telnet, etc. It became clear that websites could offer value if we found a secure way for users to log in.

A post and redirect-based standard emerged, called WS-Fed. At a very high level, it separated the responsibility of the IdP (or identity provider), the entity that performs authentication, and the RP (or relying party), also known as service provider, which is the application you’re trying to access. The RP trusted the IdP and this trust was established using certificates. The idea was that the user lands on the RP, and the RP says, “hey, you aren’t authenticated, so please go here to prove who you are.” The user could optionally be given more than one choice of an IdP. The user goes to the IdP, proves who they are (via credentials such as username password or more), and the IdP sends back a SAML packet with enough information about the user that the RP can use to establish identity and proceed.

This “enough information” is the attributes about the user, also known as claims.

WS-Fed served us well for many years. One of the products that used it was SharePoint. As time progressed, the demands of applications increased. For instance, they expanded who could initiate an authentication. If the RP initiates an authentication…

… this article is continued online. Click here to continue.

document.getElementById vs jQuery $()

are they equal?

Not exactly!!

document.getElementById('contents'); //returns a HTML DOM Object

var contents = $('#contents');  //returns a jQuery Object

In jQuery, to get the same result as document.getElementById, you can access the jQuery Object and get the first element in the object (Remember JavaScript objects act similar to associative arrays).

var contents = $('#contents')[0]; //returns a HTML DOM Object

Reference

https://stackoverflow.com/questions/4069982/document-getelementbyid-vs-jquery

Hide default search in DataTables

To hide default search box, simply pass ‘dom’:’lrtip’. This will hide default search box but searching feature still working so we can add any other custom searching.

$(‘#myTable’).DataTable({
   “dom”:”lrtip”
});

If you want to hide default search box and disable searching you can pass searching: false. In this we can not add any custom searching.

$(‘#myTable’).DataTable({
    searching: false
});

Reference

https://datatables.net/reference/api/search()