What’s the use for the
internal access modifier in C#? It’s not as common to use as
private. It wasn’t until I started some serious stand alone library work that I fully started to appreciate and use
All was fine and I was happy with my use of
internal. Until I saw this tweet yesterday.
That tweet by Mark sparked an interesting discussion, but as great as Twitter is for new ideas, I can’t fit my thoughts on this subject into the 160 chars limit. Actually that last sentence alone is too big for a tweet.
In one of my replies to Mark, I mentioned that I think that there’s a huge difference between using
internal on an entire type and using it on specific members.
Nullable<T> types and code coverage can give some unexpected, but logical results. Earlier this week I posted a small Puzzle showing the problem.
The light blue shade of the return statements indicate that they have been executed. So both branches of the if statement have been covered. But the light pink shade of the comparison indicates that the comparison has not been completely covered.
That code was deliberately somewhat obfuscated.
MyNumericType is defined by
using MyNumericType = System.Nullable<IntStruct> and
IntStruct SingleDigitLimit = new IntStruct(10);.
A simple comparison is marked as not completely covered, although both branches of the if statement have been covered!?! How is that possible?
This is a small function I’ve created, which is also covered by unit tests. The light blue shade of the
return statements indicate that they have been executed. So both branches of the if statement have been covered. But the light pink shade of the comparison indicates that the comparison has not been completely covered.
Having a logical expression marked as not completely covered is common if it includes any
&& or || operators that are short circuited. But there are no such operators here. So what is the reason for the partial coverage?
I’ll post the answer and explanation later this week.
Cookies set through the Owin API sometimes mysteriously disappear. The problem is that deep within
System.Web, there has been a cookie monster sleeping since the dawn of time (well, at least since .NET and
System.Web was released). The monster has been sleeping for all this time, but now, with the new times arriving with Owin, the monster is awake. Being starved from the long sleep, it eats cookies set through the Owin API for breakfast. Even if the cookies are properly set, they are eaten by the monster before the
Set-Cookie headers are sent out to the client browser. This typically results in heisenbugs affecting sign in and sign out functionality.
The problem is that
System.Web has its own master source of cookie information and that isn’t the
Set-Cookie header. Owin only knows about the
Set-Cookie header. A workaround is to make sure that any cookies set by Owin are also set in the
This is exactly what my Kentor.OwinCookieSaver middleware does. It should be added in to the Owin pipeline (typically in
Startup.Auth.cs), before any middleware that handles cookies.
The cookie saver middleware preserves cookies set by other middleware. Unfortunately it is not reliable for cookies set by the application code (such as in MVC Actions). The reason is that the
System.Web cookie handling code might be run after the application code, but before the middleware. For cookies set by the application code, the workaround by storing a dummy value in the sessions is more safe.
ASP.NET MVC5 has excellent support for external social login providers (Google, Facebook, Twitter) integrating with the ASP.NET Identity system. But what if we want to use external logins directly without going through ASP.NET Identity? Using external logins together with ASP.NET Identity is very simple to get started with, but it requires all users to register with the application. External logins are just another authentication method against the internal ASP.NET Identity user. In some cases there is no need for that internal database, it would be better to get rid of it and use the external login providers without ASP.NET Identity. That’s possible, but requires a bit of manual coding.
For public facing web applications I think that it is often a good idea to use ASP.NET Identity as it doesn’t tie the user to a specific login provider. But if we are fine with using one and only one specific login provider for each user it’s possible to skip ASP.NET Identity. It could be an organization that heavily relies on Google Apps already so that all users are known to have Google accounts. It could be an application that uses SAML2 based federative login through Kentor.AuthServices.
In this post I’ll start with a freshly created ASP.NET MVC Application without any authentication at all and make it use Google authentication, without ASP.NET Identity being involved at all. The complete code is available on my GitHub account.