a developer's journey with asp.net core and the web
You’ve heard the buzzword, you’ve seen the job postings. If so many people are hot about this topic, it must be worth learning about, right? What is a full-stack software engineer anyway?
You’re a good developer. You like testing your code. Security is important to you, so you also decide that you’ll use a 3rd party service for authentication and choose Auth0. Out-of-the-box, however, doesn’t quite get you what you need so you add some custom rules and scripts to it. You realize, however, that even though these scripts run in a NodeJS instance on their side, they don’t follow conventional patterns. How do I go about unit testing auth0 scripts, you ask yourself?
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.