Mayank's Blog

Managing credentials is hard. Developers try to keep development credentials separate from Production ones by using weird pre-processor directives or convoluted  if...else  statements. If you have ever worked with a development team, you know these quickly go out of hand. You might also have used environment variables to define configuration such as a database connection string. These work great but still cause some issue when moving between Windows and Linux OSes. For example, Bash does not like the : based hierarchical structure defined by .NET Core. So you have to replace the : with __ (double underscores). Environment variables are also harder to manage unless you are using a third party tool. Fortunately, .NET Core 3.0 onward now ships with a built-in Secret Manager. These are called User Secrets and are stored on a per-user ( duh! ) basis typically at this path %APPDATA%\Microsoft\UserSecrets\<user_secrets_id>\secrets.json . We need not worry about the location of thi

"The Data Access layer should be in its own project", was one of the points that I came across during a discussion with another architect from my team. The reasoning was that if it is separate, it wouldn't impact the service using it. While on the surface the logic seems sound, do we ever stop and think, hmm do we really need to introduce this complexity? How many times do we see us switching from SQL Server to Mongo DB? Is the additional complexity and work really worth it? Software Developers, especially those from object oriented language background (C#, Java, etc.) tend to love complexity. I too have been guilty of the same. But recently I came across a tweet which made me pause and take notice. .NET folks take a look. Remember that not everything has to be 150 projects and many layers. Imagine a complexity slider bar and sync it to YOUR business needs. Make it as simple or as sophisticated as you need. https://t.co/UujO05oWEb — Scott Hanselman (@shanselman) F

" error=“invalid_token”, error_description=“The signature is invalid” " is the error which stared me in the face. I was trying to use an Azure AD access token to authenticate with a .NET Core Web API protected by Azure AD. I inspected the token in JWT tool and immediately it became apparent that Issuing Authority name was wrong.  " iss":" https://sts.windows.net/<tenantId> " , even though the token was requested from an Azure AD v2 endpoint . So what gives! To understand what is happening, let's understand the history of Azure AD. AAD has undergone life cycle changes where it has moved from a v1 to v2 and re-branded itself as Microsoft Identity platform. As part of that the issuing authoring has changed from sts.windows.net to login.microsoftonline.com . As there were already many applications relying on AAD when this change was made, Microsoft decided to support both the versions. Now this is where AAD tries to be extra clever which