a developer's journey with asp.net core and the web
Authentication in ASP.NET Core is both powerful and dynamic. It provides you the power to incorporate many different schemes and augment the logged-in security principal. Authentication schemes are how we apply authentication in ASP.NET Core. What if you want to skip authentication schemes in favor of another?
Application security is a vital piece of our overall success as developers. Many of us have learned and applied role-based or claim-based authorization. Overall, this has been “good enough”. Unfortunately, there are still many use-cases it can’t handle gracefully. We call one approach that solves these use-cases policy-based authorization.
While powerful, default model binding in ASP.NET Core handles the basic use-cases. Anything you want to do beyond that — such as mixed model binding — requires a little work to get there.
Over the years we’ve seen .NET mature and change since v1. We’ve seen server technologies mature in many ways. Things we did yesterday don’t necessarily work the same way today. One of those things that recently struck me was how request timeouts work in IIS. If like me, you just assumed they worked the same in .NET Core then I invite you to join me on this journey. Let’s explore how to make ASP.NET Core request timeouts work properly with IIS in-process hosting mode.
Recently I ran into an issue I’d never had before. I wanted to access more than one GitHub account from the same machine using SSH. I needed to figure out how to use multiple SSH keys on GitHub from one computer.
As developers, we literally have the power and knowledge to change the world. Software runs everything. Good software is the gateway to the world. However, one major thing developers should concern ourselves with is frequently left to the side. Web accessibility.
I’ve been using Microsoft .NET for a long time. I started my programming journey learning C# on .NET 1.0 right after it’s initial release. In that time I have only experienced a breaking change twice. Once with WCF configuration in my app.config, and recently with the JSON serialization (or deserialization, as it were). For those upgrading a .NET Core 2.x application to .NET Core 3.x, you’ll want to be aware of some changes in the defaults. Today let’s talk about .NET Core and how it handles JSON serialization (and deserialization).
According to OpenAPI 3.0 it isn’t possible. But what if you really want it to be? Do you have to just settle and allow your Swagger documentation to be wrong? I’m here to show you how to make optional route parameters with Swagger and ASP.NET Core.
Software development has been around for a while. As technology advances so does the need to establish patterns and principles for healthy application development. We know one of those patterns as SOLID. The “D” represents Dependency Inversion Principle (DIP) which is our topic for today.
Software engineering, like other trades, is something that can be done in many ways. Throughout the years people have established patterns and practices to help craft good software. One set of design principles we’ve been discussing is SOLID. Robert C. Martin coded the Interface Segregation Principle (ISP) which “I” represents.