Dev at work: Owin exceptions, HAR logs and SAML2 authentication problems

I haven’t done a ‘Dev at Work’ blog post in a while and for that I’m sorry. The posts seem to be rather popular and I’ve been asked when I’m planning on posting. Here it is! And I’ll try to do this weekly or biweekly as I’m on partial parental leave. Here is my day today (EDIT: yesterday).

At the moment I’m on partial parent leave. Loke is 11 weeks old and I work 40%, one day at the office and the rest from home. Wednesday is my office day- today I’m other words. I woke up this morning and was somewhat tired. Even though my partner Emanuel does the night and early morning feed Tuesday night/Wednesday morning I’m so used to waking up (as I do the feeds all other nights) that I wake up regardless. Today was a beautiful day, so I woke up, grabbed some breakfast and went out for an outdoor run.

Came back, gave Loke a cuddle, and hurried to work at 9:30 AM. I always work out before work, in particular during the winter when daylight is limited and Wednesday is my run-day. Our daily standup is usually at 10, but we had moved it to 11 today. Before lunch I worked on a prioritized issue. One of our services would, under unknown circumstances, throw an exception that would bubble up and include the stacktrace. The stacktrace, for those of you who aren’t programmers, a stacktrace is the methods called in the source code. And an exception stacktrace is therefore the methods that were called as the exception occurred. While useful when trying to identify an error, it’s really bad when it shows up in production. Exposing this information can be a serious security risk, and it also looks horrible. We had a global exception handler in the service- something that would, or at least should, catch all exceptions before they bubble up and out and are surfaced to the client. Why wasn’t this working? I suspected that it was one of our Owin middleware components. These are called in the request pipeline and won’t be caught by the global exception handler. The solution was straightforward, I added an exception middleware that would catch, log and format the exception. And for this particular service we also want to return early. I discussed with my colleagues which return code to use as we didn’t want to expose a 500, and we decided on 401 for now.

Example code

 
   public class OwinExceptionMiddleware : OwinMiddleware
   {
       public OwinExceptionMiddleware(OwinMiddleware next) : base(next) { }

       public override async Task Invoke(IOwinContext context)
       {
           try
           {
               await Next.Invoke(context);
           }
           catch (Exception exception)
           {
               var internalId = Guid.NewGuid();

               var message = ErrorMessage.Format(exception, internalId);

               Logger.Error(message);

               context.Response.StatusCode = 401;
               await context.Response.WriteAsync($"Error in backend call. See InternalId {internalId}");
           }
       }


//And in configuration(IAppBuilder app) in Startup:

app.Use<OwinExceptionMiddleware>();

We moved the issue to test, and as I was deciding on the next task a colleague of mine called from the Stockholm office. He works as an implementation consultant (tenant on boarding and configuration) and QA tester. One of our larger tenants logs in by SAML2 and they have 10 subdivisions that log in with the same provider. The subdivisions are set up as different tenants. I had recently configured the subdivision tenants to log in through the provider instead of an internal database. This tenant(s) have a unique setup so I switched while talking with consultant so he could test immediately. He was unable to log in and we had to figure out why. He recorded the login attempt, and I requested a .HAR log so I could replay the steps.

A HAR log is a log of a user interaction with a website, with detailed requests, cookies and more. If you, in Chrome, open up the developer tools (F12) select a request under network you can copy all the requests as a HAR log. There are tools such as the one by GSuite (free) that lets you view the log in a more readable format and I was able to figure out the problem after looking at the requests.

Turns out, our current setup doesn’t support a many to one setup- one tenant is tied to one SAML2 authentication provider. Therefore the subdivision tenants were redirected to the main tenant. A support ticket and issue was created, and marked as high priority. I’m the one that set up most of our authentication services, including the SAML2 service, and therefore the ticket was assigned to me. I made some notes in regards to the problem and reproduced the problem locally. Jonas, my colleague and skilled front end developer, dragged the team out of the cave and to the eating area for a ‘Fika’ (Swedish tradition where you have a snack and coffee with your colleagues and talks hit for half an hour). Although some might consider a Fika a waste of time it’s actually great!

We usually have it around 3PM when people are getting fed up with work and need a break, and it’s a great opportunity to bond with my colleagues, discuss things and let the brain recover. I spent the rest of the day going through the SAML2 service code- it has been awhile and I had forgotten what I had written. By the time it was time to head home (6PM) I had written down some possible solutions. I always write down everything so I don’t have to rely on my memory, it helps knowing where to start the next day. I packed up my stuff, including my favorite keyboard that I drag with me to work and back home each Wednesday and headed home to cook dinner, call my dad (he had surgery), cuddle with Loke and spend some time with my partner.

And that, my dear friend, was my day as a developer :) How was your day?

Until next time, take care

Dev at work: Owin exceptions, HAR logs and SAML2 authentication problems

Comments