Tag: ASP.NET

Rate limiting is a way to control the amount of traffic that a web application or API receives, by limiting the number of requests that can be made in a given period of time. This can help to improve the performance of the site or application, and to prevent it from becoming unresponsive. Starting with .NET 7, ASP.NET Core includes a built-in rate limiting middleware, which can be used to rate limit web applications and APIs. In this blog post, we’ll take a look at how to configure and use the rate limiting middleware in ASP.NET Core.

Right now, I’m having fun building a .NET Core client library for JetBrains Space. Part of that client library will be ASP.NET Core authentication, to help in making authentication with your Space organization easy. Think of something like this: This should look very familiar if you are building an ASP.NET Core application that uses something like Microsoft Account, Google, Azure Active Directory/B2C, or anything that uses the Microsoft.AspNetCore.Authentication.OAuth namespace. There are many of those extensions that help register an authentication handler for a specific service.

Usually on my development machine, I run ASP.NET Core applications in Kestrel. It’s easy to do, the project templates .NET Core provide create a nice launchSettings.json to start it from the command line, etc. However, I was asked to help someone out with hosting ASP.NET Core in IIS Express. Great! The default launchSettings.json contain an entry for that as well, so I ran dotnet run --launch-profile "IIS Express".

We all know it’s important to prevent Cross-Site Request Forgery (CSRF) attacks against our application. Unfortunately, our inherited code base has zero measures implemented - not one action methods with a [ValidateAntiForgeryToken] attribute in sight!

As discussed in the previous post, we all know it is important to perform validations to prevent a Cross-Site Request Forgery (CSRF) attack against our application. Imagine inheriting a code base that has zero measures implemented? How would you find which action methods need a [ValidateAntiForgeryToken]? Today, we will look at using ReSharper to find all action methods that need [ValidateAntiForgeryToken] added. In this series:

As ASP.NET MVC developers, whether ASP.NET MVC 5 or ASP.NET MVC Core, we all know it is important to perform certain validations to prevent a Cross-Site Request Forgery (CSRF) attack against the application we are building. The ASP.NET MVC provides the @Html.AntiForgeryToken() helper which we can use to add a hidden field in the form we are posting, and a [ValidateAntiForgeryToken] attribute which we can decorate our action method with and instructs the framework to validate the posted token is valid (or was forged).

While I am a big fan of Autofac to serve as the framework for making Inversion of Control (IoC) and Dependency Injection (DI) work in an application, it is quite convenient in simple projects to use the built-in dependency injection in ASP.NET Core. While simple to replace the default one with Autofac, the default one is often sufficient. Unless it’s not! Consider the following component registration: With the default Microsoft.Extensions.DependencyInjection package in ASP.NET Core, we can now consume an ICustomerService in, for example, our controllers:

How would you validate a new API is compatible with an old API? While upgrading frameworks in a web application we’re building, that was exactly the question we were asking ourselves. Sure, we could write synthetic tests on each endpoint, but is that representative? Users typically find insane better ways to test an API, so why not replay actual requests against the new API?

So you’re building a multi-tenant application. And just like many multi-tenant applications out there, the application will use a single (sub)domain per tenant and the application will use that to select the correct database connection, render the correct stylesheet and so on. Great! But how to do this with ASP.NET MVC 6?

You may remember my ranty post from a couple of months back. If not, read about how building .NET projects is a world of pain and here’s how we should solve it. With Project K ASP.NET vNext ASP.NET 5 around the corner, I thought I had to look into it again and see if things will actually get better… So here goes!