Angular OIDC - Avoid token sharing

To integrate OIDC in our Angular applications we are using the great angular-oauth2-oidc library from Manfred Steyer.

Once we receive a valid token back from our IdentityServer instance it is stored inside the session storage using the OAuthStorage class. This all seemed to work fine. However we got into trouble when we started to switch between applications. Different Angular apps were receiving a token from another app which resulted into errors.

The problem had nothing to do with the angular-oauth2-oidc library but with the way we had setup our applications. All our applications where sharing the same root url and were hosted as virtual directories inside IIS;

• apps.example.com/app1
• apps.example.com/app2
• apps.example.com/app3

Session storage is scoped per domain but as all applications were using the same domain, they accidently accessed each other tokens.

To fix it we had to create our own OAuthStorage class that used an application prefix to isolate the tokens:

All credits to Jens who investigated the issue and created a fix.

Modular Monolith with DDD

Modular monoliths are hot! It combines the modularity of a microservices architecture with the ease of deployment of a monolith.

For a good introduction, have a look at the following video:

If you want to get started in .NET take a look at the following repository on Github: https://github.com/kgrzybek/modular-monolith-with-ddd

It contains a full modular monolith .NET (Core) application created using DDD and CQRS.

GraphQL.NET– Error when upgrading to .NET Core 3.1

After upgrading a .NET Core application to .NET Core 3.1, my GraphQL endpoint started to fail with the following error message:

System.InvalidOperationException: Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.

   at Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream.Read(Byte[] buffer, Int32 offset, Int32 count)

   at Microsoft.AspNetCore.Server.IIS.Core.WrappingStream.Read(Byte[] buffer, Int32 offset, Int32 count)

   at System.IO.StreamReader.ReadBuffer(Span`1 userBuffer, Boolean& readToUserBuffer)

   at System.IO.StreamReader.ReadSpan(Span`1 buffer)

   at System.IO.StreamReader.Read(Char[] buffer, Int32 index, Int32 count)

   at Newtonsoft.Json.JsonTextReader.ReadData(Boolean append, Int32 charsRequired)

   at Newtonsoft.Json.JsonTextReader.ParseValue()

   at Newtonsoft.Json.JsonReader.ReadAndMoveToContent()

   at Newtonsoft.Json.JsonReader.ReadForType(JsonContract contract, Boolean hasConverter)

   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)

   at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)

   at Newtonsoft.Json.JsonSerializer.Deserialize(JsonReader reader, Type objectType)

   at Newtonsoft.Json.JsonSerializer.Deserialize[T](JsonReader reader)

   at GraphQL.Server.Transports.AspNetCore.GraphQLHttpMiddleware`1.Deserialize[T](Stream s)

   at GraphQL.Server.Transports.AspNetCore.GraphQLHttpMiddleware`1.InvokeAsync(HttpContext context)

   at GraphQL.Server.Transports.WebSockets.GraphQLWebSocketsMiddleware`1.InvokeAsync(HttpContext context)

   at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)

   at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)

   at Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware.Invoke(HttpContext context)

   at Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware.Invoke(HttpContext httpContext)

   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

To fix it you can apply the suggestion as described in the error message:

But there is a good reason why Microsoft changed the default behavior in .NET Core 3.0 and disabled synchronous IO. It can be a source of thread starvation and application hangs.

The GraphQL.NET team is working on a new 3.0 release specifically created for .NET Core 3.0 but this is still in preview.

You can get the latest pre-release packages from the MyGet feed, where you may want to explicitly pull a certain version using -v.

dotnet add package GraphQL.SystemTextJson -v 3.0.0-preview-1448

Azure DevOps - Assigning work items to a group

In the AssignedTo field inside Azure DevOps you can only select a specific user. This means that you are not able to assign work items to a group(TFS or AD group) out-of-the-box. There is no way to change the existing AssignedTo field but you can add your own extra field:

• Go to Organization Settings.

• Click on Process

• We need to create an inherited process. Click on the … next to one of the built-in processes and choose Create inherited process.

• Specify a name for the inherited process and click on Create process.

• Now we can add a new field that allows group identities to be assigned. Choose the work item type where you want to add the extra field e.g. Task

• Click on New field.

• On the Add a field screen, specify a name and set the field type to Identity.

• Go to the options tab and check the Allow assigning to groups checkbox

That’s it! The new process can be applied to an existing project that used the same parent process.

Azure DevOps - Expanded members

Inside Azure DevOps you can see the members of your Team in the Team settings:

On the right side you have a dropdown where you can switch between Direct Members and Expanded Members. But what does this do? I couldn’t find any extra input in the documentation.

This feature is relevant when you add not only users to your team but also TFS groups. In that case when you change to the Expanded Members view, the members in the group are shown as well.

Good to know!

Orleans - Observers step by step

One of the features inside Microsoft Orleans is the support for ‘Observers’. Through observers it becomes possible to send asynchronous notifications to one or more clients. It allows you to create a ‘simple’ distributed pub/sub mechanism.

I didn’t find the documentation very clear on this part, so here is a step by step guide on how to implement an Orleans observer:

Step 1  - Create the observer client

An observer is a one-way asynchronous interface that inherits from IGrainObserver, and all its methods must be void. So let’s create this interface first:

Inside our client we need to create a class that implements this interface:

Step 2 – Handling registrations

To handle the registrations we need a grain that can store the list of registered clients. Let’s create a grain interface that can handle the registrations. Let us also add a Publish() method that can be called to publish a message to all registered clients:

Next it’s time to implement the corresponding grain. Inside this grain we use another class to handle the registrations. In previous versions of Orleans you could use the built-in ObserverSubscriptionManager class, but in Orleans 2 and 3 you’ll have to create this class yourself.

Let’s do that first:

Now we can finally create our grain implementation which is rather simple as most of the work is done by the ObserverSubscriptionManager:

The work on the server side is done!

Step 3 -  Link the client to the server

As a last step we need to link the observer client to our SubscriptionManagerGrain. Therefore the client needs to call a static method on the observer factory, CreateObjectReference(), to turn the class into a grain reference, which can then be passed to the subscription method on the notifying grain.

Let’s add an Init() method to do this:

We also add the possibility to unsubscribe and publish a message through the client:

Don’t be the hero in your team

You are the problem solver in your team. The moment someone starts a sentence with “I’m wondering how…” or “I don’t understand why…” you are there to help. With a few keystrokes on their keyboard you are solving the hardest problems in your team. For every complex problem you are the ‘go-to’ guy. You are really indispensable. Without you the team is lost and they are all fearing the day you’ll leave…

You are truly the hero in your team. You are feeling great about the value you add to the team and the way you can help everyone. You rock!!!!

Do you recognize this?

Unfortunately I have bad news for you. This is not good at all. By taking on all the hard challenges and solving the problems for your team, you take away their opportunities to grow. You are creating a mindset where nobody even tries to tackle a problem. Instead they immediately face towards you… This is not a healthy situation, your team gets more and more dependent on you. No one will step up as long as you keep showing the same behavior.

It’s time for change. Become a mentor for your team, give help when asked for but don’t offer solutions on a silver plate. Give them all the opportunities to learn and grow.

Make yourself dispensable. Don’t be the hero in your team…