If you haven't seen the beginning of the series I recommand you check the first post about Consul & RabbitMQ and the second post about .NET code to access services with Consul, along with the base course from Les Jackson.

This post is part of a whole:

• .NET Microservices: Service Discovery (Part 1: Consul & RabbitMQ Deployment)
• .NET Microservices: Service Discovery (Part 2: Reaching RabbitMQ through Consul)
• .NET Microservices: Service Discovery (Part 3: Configuring Commands HTTP Service to Consul and consuming it)
• .NET Microservices: Service Discovery (Part 4: Configuring Platform gRPC Service to Consul and consuming it)

We successfully deployed Consul to register our Microservices, we set up RabbitMQ to register automatically to Consul, and we updated our Microservices to call Consul in order to get the RabbitMQ configuration dynamically.

Several services such as RabbitMQ offer some elements or plugins to configure automatically to Consul, I strongly recommand to check out before doing anything complicated because as you've seen, RabbitMQ was quite easy to set up.

So what do we want to do now? Well the whole point was to remove the dependency between our microservices, so we are going to register one of the services to Consul and ask Consul to deliver the configuration to whomever needs it at runtime.

I used some parts of another of TechyMaki's video about Consul, find out more here:

We are going to register the CommandService HTTP Service first, simply because it's the most trivial to configure and to call.

Registering our Commands Service to Consul

Configuring our appsettings

Let's focus on CommandService project.
First things first, we are going to need to configure a few things for our appsettings files. The logic here will be reversed, instead of configuring the addresses and ports of the other services, we're going to configure our own address, port and consul info (id & name).

When we wanted to call CommandService from PlatformService, we configured the following address locally like that: "CommandsService": "http://localhost:6000" in the PlatformService project.

Now, we want to configure the two appsettings of CommandService this way:

{
  (…)
  "CommandsHttp": {
    "Id": "commandshttp",
    "Name": "commandshttp",
    "Address": "localhost",
    "Port": "6000"
  }
}

{
  (…)
  "CommandsHttp": {
    "Id": "commandshttp",
    "Name": "commandshttp",
    "Address": "commands-clusterip-srv",
    "Port": "80"
  }
}

Locally, our server is running in localhost on port 6000, which is what we configured.
In our kubernetes cluster, we configured our service to run on the commands-clusterip-srv address, with a classic port of 80.

I chose commandshttp as Id & Name for Consul and we're going to use it now.

Hosted Service

We are going to use a HostedService. The principle is pretty simple, you implement an interface (IHostedService) that has two methods, StartAsync() and StopAsync(), and we will register this class to our AspNet startup system.

The Hosted Service will trigger the StartAsync() method just before starting the application, and will trigger StopAsync() right before the application stops. Remember this is sequentially triggered at startup so if you need a hosted service, you should keep these two implementation minimal not to overload your overall system.

This is actually perfect because it's the exact lifecycle we want for our Consul Registration: register the service at startup, deregister it at shutdown. Life is good.

ConsulRegisterHostedService

We are going to create a new class, ConsulRegisterHostedService that we will place in the same folder as the rest of our Consul Services (DiscoveryServices). It will implement the IHostedService interface. We will need the IConsulClient we injected before and the IConfiguration to get our configuration. It should look like that at first:

using Consul;

namespace CommandsService.DiscoveryServices;

public class ConsulRegisterHostedService : IHostedService
{
    public ConsulRegisterHostedService(IConsulClient consulClient, 
                                       IConfiguration configuration)
    {
        _consulClient = consulClient;
        _configuration = configuration;
    }

    public Task StartAsync(CancellationToken cancellationToken)
    {
        Console.WriteLine("Registering service to Consul");
		return Task.CompletedTask;
    }

    public Task StopAsync(CancellationToken cancellationToken)
    {
        Console.WriteLine("Deregistering service to Consul");
        return Task.CompletedTask;
    }
}

Registering our Hosted Service

Now we're going to register our Hosted Service. It's pretty standard, just go to your Program.cs (or Startup.cs) and use the services.AddHostedService<T>() method:

var services = builder.Services;

(…)

services.AddHostedService<ConsulRegisterHostedService>();

(…)

Just start your application with dotnet run to check you have the register log in the console, then kill it with CTRL+C and check you have the deregister log like that:

StartAsync() and StopAsync() implementations

The implementation is quite simple, Consul has everything ready for us for registration and deregistration with the AgentServiceRegistration class. We're going to register in StartAsync() and deregister on StopAsync(). Side-note, just as a security we're going to deregister the existing id before registering it.

We're going to use everything we put in our appsettings, just like that in StartAsync():

public async Task StartAsync(CancellationToken cancellationToken)
{
    Console.WriteLine("Registering service to Consul");

    var serviceRegistration = new AgentServiceRegistration()
    {
        Address = _configuration["CommandsHttp:Address"],
        Port = int.Parse(_configuration["CommandsHttp:Port"]),
        Name = _configuration["CommandsHttp:Name"],
        ID = _configuration["CommandsHttp:Id"]
    };

    try {
        await _consulClient.Agent.ServiceDeregister(serviceRegistration.ID, cancellationToken);
        await _consulClient.Agent.ServiceRegister(serviceRegistration, cancellationToken);
    }
    catch (Exception ex) {
        Console.WriteLine($"Unable to register to Consul: {ex.Message}");
    }
}

And for the StopAsync() implementation:

public async Task StopAsync(CancellationToken cancellationToken)
{
    Console.WriteLine("Deregistering service to Consul");
    try {
        await _consulClient.Agent.ServiceDeregister(_configuration["CommandsHttp:Id"], cancellationToken);
    }
    catch (Exception ex) {
        Console.WriteLine($"Unable to deregister to Consul: {ex.Message}");
    }
}

Pretty straightforward, just put a try-catch block (especially on startup) because something could go wrong and we don't want a HostedService to fail ungracefully. For instance, if Consul server was not available.

One improvement could be a retry-mechanism in case Consul is not available; we're not going to bother here but this might be a good idea in production to avoid orphaned services.

Now check that you correctly register your service in your Consul management page (http://localhost:8500):

Now kill you app and check you no longer have the service; it should be good!
If you stay on the page you should have an error message:

Congratulations!

Kubernetes build

Last step for our CommandService configuration, rebuild, push and restart your deployment:
docker build -t xxx/commandservice .
docker push xxx/commandservice
kubectl rollout restart deployment commands-depl

Now check that your service is correctly registered with the production address:

All set regarding CommandService HTTP configuration to Consul! Not that difficult right?

Getting CommandsHttp configuration from Consul

Okay now let's get back to our PlatformService, trust me this will go very smoothly from now on due to our configuration on the previous post.

First, you can remove the "CommandsService" parameter from all the appsettings (dev & prod): we won't need it anymore!

Get back to ConsulService.cs, we're going to configure our new id (commandshttp):

namespace PlatformService.DiscoveryServices;

public static class ConsulServices 
{
    public const string RabbitMQ = "rabbitmq";
    public const string CommandsHttp = "commandshttp";
}

Now get back to our HttpCommandDataClient, we're going to replace what is no longer needed with our Consul service call. What we currently have:

using System.Text;
using System.Text.Json;
using PlatformService.Dto;

namespace PlatformService.SyncDataServices.Http;

public class HttpCommandDataClient : ICommandDataClient
{
    private readonly HttpClient _httpClient;
    private readonly IConfiguration _configuration;

    public HttpCommandDataClient(HttpClient httpClient, IConfiguration configuration)
    {
        _httpClient = httpClient;
        _configuration = configuration;
        Console.WriteLine($"Configuration is on {_configuration["CommandsService"]}");
    }

    public async Task SendPlatformToCommandAsync(PlatformReadDto platform)
    {
        var httpContent = new StringContent(
            JsonSerializer.Serialize(platform),
            Encoding.UTF8,
            "application/json"
        );
        var response = await _httpClient.PostAsync($"{ _configuration["CommandsService"] }/api/c/platforms", httpContent);

        if (response.IsSuccessStatusCode)
        {
            Console.WriteLine("Success !");
        }
        else
        {
            Console.WriteLine("Error during Sending Platform to command service");
        }
    }
}

So the two steps are

• Remove IConfiguration and add IConsulRegistryService, just like we did for RabbitMQ previously
• Replace our configuration hard-coded values with a consul service call

I'll skip the constructor and private fields to focus on the SendPlatformToCommandAsync which should look something like this:

public async Task SendPlatformToCommandAsync(PlatformReadDto platform)
{
    try
    {
        var service = _consulRegistryService.GetService(ConsulServices.CommandsHttp);
        if (service == null)
            throw new ArgumentNullException(nameof(service));

        var httpContent = new StringContent(
            JsonSerializer.Serialize(platform),
            Encoding.UTF8,
            "application/json"
        );
        var response = await _httpClient.PostAsync($"http://{service.Address}:{service.Port}/api/c/platforms", httpContent);

        if (response.IsSuccessStatusCode)
        {
            Console.WriteLine("Success !");
        }
        else
        {
            Console.WriteLine("Error during Sending Platform to command service");
        }
    }
    catch (Exception ex)
    {
        Console.WriteLine($"Error during Sending Platform to command service: {ex.Message}");

    }
}

Now start your CommandService locally with dotnet run, check it is correctly registered, start your PlatformService with dotnet run and check that the CommandHttp is correctly found and called; you're all set!

All that is left is to just build/push/rollout your image for platformservice and check that everything runs correctly.

And that's it!

Additional side-notes

First of all, we implemented our IConsulRegistryService.GetService() to be synchronous with a « dirty » var serviceQueryResult = _consulClient.Health.Service(serviceName).Result;. It was necessary considering we were using it in a constructor, but that is quite a waste when we're using it in an asynchronous method such as SendPlatformToCommandAsync(). If you want to go to production, I would refactor this a bit.

Secondly, we could wonder why we're calling our _consulRegistryService each time. It seems quite a waste of time: we could just load it in the constructor and keep it safe in a field.
…BUT…
That would defeat the whole purpose of the operation! In that ecosystem, the services come and go, live and die, and we want to have the most accurate configuration possible, so we NEED to call the service each time actually to be sure to have a service that is alive and healthy at this precise moment, not during initialization.

An additional implementation could be to listen to the updates from Consul in the ConsulRegistryService to keep a track of the services, it could save a few calls to Consul. I think it might be overkill but I'd like your opinion on this !

Thank you for reaching the end of the part 3 of that tutorial and I hope that you enjoyed it!
Right now you should have nearly all the keys to switch to a fully functional Service Discovery system in your Microservices!

Next up we're going to do something similar with gRPC, with just a little configuration twist that deserves its own post in my opinion.

See you!

This post is part of a whole:

• .NET Microservices: Service Discovery (Part 1: Consul & RabbitMQ Deployment)
• .NET Microservices: Service Discovery (Part 2: Reaching RabbitMQ through Consul)
• .NET Microservices: Service Discovery (Part 3: Configuring Commands HTTP Service to Consul and consuming it)
• .NET Microservices: Service Discovery (Part 4: Configuring Platform gRPC Service to Consul and consuming it)

If you haven't seen the beginning of the series I recommand you check the first post, along with the base course from Les Jackson.

This post is part of a whole:

• .NET Microservices: Service Discovery (Part 1: Consul & RabbitMQ Deployment)
• .NET Microservices: Service Discovery (Part 2: Reaching RabbitMQ through Consul)
• .NET Microservices: Service Discovery (Part 3: Configuring Commands HTTP Service to Consul and consuming it)
• .NET Microservices: Service Discovery (Part 4: Configuring Platform gRPC Service to Consul and consuming it)

So — where were we? We deployed our Consul Server and we configured RabbitMQ to register to Consul.

What's left to to? Simply call the Consul Server from our .NET projects to get the required data to call.

I used some parts of TechyMaki's video about Consul, find out more here:

I will start with PlatformService because it was the first project we started working on. In the end I'll recap quickly how to do it for CommandService but it's very similar and probably a good excercise to try to do it without any help for the second one.

Installing Consul & Inject the Client

Nuget Package & appsettings.json

The very beginning is to download and install the Consul framework from the NuGet feed. I like to use the NuGet Gallery extension but you can also add it simply with the command line dotnet add package Consul from your PlatformService folder.

We will require two parameters for Consul: ConsulAddress and ConsulPort. Open your appsettings.Development.json and add the following parameters to your existing configuration:

{
  (…),  
  "ConsulAddress": "localhost",
  "ConsulPort": "8500"
}

Locally, we are using the LoadBalancer with localhost and the default port of Consul, 8500

You can already configure the appsettings.Production.json as we already have the necessary data to do so:

{
  (…),
  "ConsulAddress": "consul-clusterip-srv",
  "ConsulPort": "8500"
}

We are simply using the consul-clusterip-srv wich is the routing we have configured inside our Kubernetes cluster.

While you're at it: you can remove the RabbitMQHost and the RabbitMQPort from both configuration files. We won't need it anymore, as Consul will give us the information.

Injecting our IConsulClient

We are going to use dependency injection to inject the IConsulClient, which is the client provided by our Consul NuGet package to interact with the server.

There is a few possibilities here, I chose to use a Singleton and to configure the Consul parameters from the Configuration on the go. For that, get to your Program.cs (or Startup.cs on .NET5.0) and add the service injection:

(…)

services.AddSingleton<IConsulClient, ConsulClient>(serviceProvider =>
{
    var conf = serviceProvider.GetService<IConfiguration>();
    var address = conf?["ConsulAddress"];
    var port = conf?["ConsulPort"];
    
    Console.WriteLine($"Configuring Consul at http://{address}:{port}");
    
    return new ConsulClient(config =>
    {
        config.Address = new Uri($"http://{address}:{port}");
    });
});

(…)

We're using the singleton constructor that provides us the ServiceProvider in order to get the parameters we defined in our appsettings (ConsulAddress and ConsulPort). The ? are null-check operators as .NET6.0 is sensitive on this topic.

At this point, don't hesitate to dotnet run your project to check you are correctly injecting your parameters and that your ConsulClient is correctly initialized.

Creating the IConsulRegistryService and its lifecycle

We're now ready to create the (.net) service that will help us find the other (consul) services through our Consul Server. We could use the client directly, but it will be clearly cleaner to create this RegistryService.

Create a new folder at the root of the PlatformService project, that we will name DiscoveryServices

Inside, we'll first create an interface we will name IConsulRegistryService.cs with the following code :

using Consul;

namespace PlatformService.DiscoveryServices;

public interface IConsulRegistryService
{
    AgentService? GetService(string serviceName);
}

This will be a simple service that will return the configuration for a serviceName provided.

In the same folder, we will also create a class to store the keys we can use, with a file named ConsulServices.cs:

namespace PlatformService.DiscoveryServices;

public static class ConsulServices 
{
    public const string RabbitMQ = "rabbitmq";
}

And finally, our ConsulRegistryService.cs. This class will implement IConsulRegistryService and we'll inject two parameters in the constructor: our IConsulClient and the IWebHostEnvironment. I'll explain later why we need it.

Your file should look like this:

using Consul;

namespace PlatformService.DiscoveryServices;

public class ConsulRegistryService : IConsulRegistryService
{
    private readonly IConsulClient _consulClient;
    private readonly IWebHostEnvironment _webHostEnvironment;

    public ConsulRegistryService(IConsulClient consulClient, 
                                 IWebHostEnvironment webHostEnvironment)
    {
        _consulClient = consulClient;
        _webHostEnvironment = webHostEnvironment;
    }

    public AgentService? GetService(string serviceName) {
		throw new NotImplementedException();
    }
}

We're going to implement this method a little bit later; right now let's focus on injecting and using this.

As always, let's get back to Program.cs (or Startup.cs) to create our Singleton. It's a basic init like we always did. As a measure of security, I always put it after its dependencies (so here after IConsulClient singleton definition):

(…)

services.AddSingleton<IConsulRegistryService, ConsulRegistryService>();

(…)

And as simple as that, we have injected our service. Now let's use it!

Getting the RabbitMQ configuration

Now that we created our service, let's get back to the MessageBusClient where we did our RabbitMQConfiguration. Let's focus on the constructor, that's the only thing we'll need to change.

Right now your client should look something like this:

public class MessageBusClient : IMessageBusClient
{
    private readonly IConfiguration _configuration;
    private readonly IConnection _connection;
    private readonly IModel _channel;

    public MessageBusClient(IConfiguration configuration)
    {
        _configuration = configuration;
        var factory = new ConnectionFactory()
        {
            HostName = _configuration["RabbitMQHost"],
            Port = int.Parse(_configuration["RabbitMQPort"])
        };
        try
        {
            _connection = factory.CreateConnection();
            _channel = _connection.CreateModel();

            _channel.ExchangeDeclare(exchange: "trigger", type: ExchangeType.Fanout);

            _connection.ConnectionShutdown += RabbitMQ_ConnectionShutdown;

            Console.WriteLine("--> Connected to MessageBus");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"--> Could not connect to the Message Bus: {ex.Message}");
        }
    }
(…)

}

First of all we will need to inject our IConsulRegistryService to the constructor. You can also drop the IConfiguration: we won't need it anymore.

We are going to get the service informations from our RegistryService (Address & Port) and inject it instead of IConfiguration["RabbitMQHost"] (and port). Considering our service CAN be null (if there is none available), you should move your code inside the try-catch block and null-check your data, just like this:

public class MessageBusClient : IMessageBusClient
{
    private readonly IConsulRegistryService _consulRegistryService;
    private readonly IConnection _connection;
    private readonly IModel _channel;

    public MessageBusClient(IConsulRegistryService consulRegistryService)
    {
        try
        {
            var service = _consulRegistryService.GetService(ConsulServices.RabbitMQ);
            if (service == null)
                throw new ArgumentNullException(nameof(service));
                
            var factory = new ConnectionFactory()
            {
                HostName = service.Address,
                Port = service.Port
            };
            
            (…)
        }
        catch (Exception ex)
        {
            Console.WriteLine($"--> Could not connect to the Message Bus: {ex.Message}");
        }
    }
(…)

}

We are simply calling the newly created service to find the RabbitMQ configuration.

At this point you can dotnet run your project, but you should get a NotImplementException from our new service.

Implementing the GetService method

Let's talk implementation. What we will need is to ask our Consul client for a healthy service. I won't get into details about service lifecycle, here we are only focusing on getting things done; this could be improved with more finesse.

To keep it simple, I also did not take into consideration any async method. Indeed, we are using our GetService(…) in a constructor so I used the .Result method to keep it synchronous. Not that clean, if we wanted to do something clean we would have to go further, but our mind is set on getting things done here so there will be room for improvement if you want to go to production.

Now the implementation looks like that:

public AgentService? GetService(string serviceName) {
    Console.WriteLine($"Looking for service {serviceName}");

    var serviceQueryResult = _consulClient.Health.Service(serviceName).Result;
    var nbServices = serviceQueryResult?.Response?.Length;
    if (nbServices > 0)
    {
        Console.WriteLine($"{nbServices} service(s) found");
        var service = serviceQueryResult?.Response[0]!;
        return service.Service;
    }
    else
    {
        Console.WriteLine($"Service not found");
        return null;
    }
}

Simply put: we call Consul for a Healthy Service matching the name, we return the first result. Again, a lot could be done to improve it but it's a decent implementation to start.

Now in theory we could test it all the way locally, but if we do we're going to hit a rock.

Remember when we defined our RabbitMQ configuration for Kubernetes? We did something that will actually be a problem for a local test:

apiVersion: v1
kind: ConfigMap
metadata:
  name: rabbitmq-config
data:
  enabled_plugins: |
      [rabbitmq_management,rabbitmq_management_agent,rabbitmq_mqtt,rabbitmq_stomp,rabbitmq_peer_discovery_consul].
  rabbitmq.conf: |
      log.console = true 
      loopback_users.guest = false
      cluster_formation.peer_discovery_backend = consul
      cluster_formation.consul.host = consul-clusterip-srv
      cluster_formation.consul.svc = rabbitmq
      cluster_formation.consul.svc_addr = rabbitmq-clusterip-srv

Can you see it?

…

…

That's right, we registered RabbitMQ with the rabbitmq-clusterip-srv service address. Now this won't be a problem in production, but it won't work locally because it's an internal address.

My solution here was to add a small snippet of code to rewrite addresses during development. It's not the best and we usually try to avoid this kind of workaround, but all the « proper » methods were furiously more complicated in my opinion than two lines of codes.
That's where our IWebHostEnvironment comes to light, with a final implementation looking like that:

public AgentService? GetService(string serviceName) {
    Console.WriteLine($"Looking for service {serviceName}");

    var serviceQueryResult = _consulClient.Health.Service(serviceName).Result;
    var nbServices = serviceQueryResult?.Response?.Length;
    if (nbServices > 0)
    {
        Console.WriteLine($"{nbServices} service(s) found");
        var service = serviceQueryResult?.Response[0]!;
        if (_webHostEnvironment.IsDevelopment())
            service.Service.Address = "localhost";
            
        return service.Service;
    }
    else
    {
        Console.WriteLine($"Service not found");
        return null;
    }
}

PHEW! Finally!

Now let's start our project with dotnet run, you should see something like this in your logs when you call for any method in the PlatformController (the reason is the singleton is initialized when injected, so you won't see it at startup):

Now all you have to do is rebuild your image: docker build -t xxx/platformservice .

Push it: docker push xxx/platformservice

And restart your deployment: kubectl rollout restart deployment platforms-depl

And you should see the same results with your Kubernetes API:

Now do it again with CommandService

Ready for a challenge? Let's do it again with CommandService: it's exactly the same.

• Add Consul to .net project
• Update your appsettings (dev+prod, remove RabbitMQ parameters and add Consul parameters)
• Create the IConsulClient dependency injection and use the appsettings values
• Create and implement the IConsulRegistryService + ConsulRegistryService (and ConsulServices)
• Update the MessageBusSuscriber to replace the IConfiguration hardcoded values of RabbitMQ by the call to IConsulRegistryService
• Test locally
• Test with Kubernetes

Now that we have consumed our first service with Consul, it's time to get hard: we will now register our own services and consume them.

See you in the next post!

This post is part of a whole:

• .NET Microservices: Service Discovery (Part 1: Consul & RabbitMQ Deployment)
• .NET Microservices: Service Discovery (Part 2: Reaching RabbitMQ through Consul)
• .NET Microservices: Service Discovery (Part 3: Configuring Commands HTTP Service to Consul and consuming it)
• .NET Microservices: Service Discovery (Part 4: Configuring Platform gRPC Service to Consul and consuming it)

I have discovered a few monthes ago the AMAZING course by Les Jackson about microservices with .Net Core.
I cannot recommand it enough, it's a freaking gold mine and a pleasure to watch and to develop alongside this incredible teacher. And it's entirely free. For such a good material to be free is just an opportunity no-one should miss.

You can find it here and I strongly recommand to follow it:

Les Jackson finishes his course on final thoughts with what could be improved. Today I want to get into details with « Service Discovery » which is in my opinion the most relevant feature to add after the course. We're going to improve this course by including an Open-Source Service Discovery.

Amongst the choices, I found both Eureka (by Netflix) and Consul to be the best options. I chose the latter - Consul - for various reasons and we're going to implement it together.

This post is part of a whole:

• .NET Microservices: Service Discovery (Part 1: Consul & RabbitMQ Deployment)
• .NET Microservices: Service Discovery (Part 2: Reaching RabbitMQ through Consul)
• .NET Microservices: Service Discovery (Part 3: Configuring Commands HTTP Service to Consul and consuming it)
• .NET Microservices: Service Discovery (Part 4: Configuring Platform gRPC Service to Consul and consuming it)

These posts are starting right at the end of his course. I strongly advise you to do all the course before getting into my posts, but you can also find the whole content on GitHub. You can start from the repo but I will assume you have all the basics to continue this.

I should warn you that I did the whole course in .NET 6.0. There is not a lot of differences, but you might find a few new syntax code lines such as namespace xx; or = default! for non-nullable parameters. None of my code relies on .NET 6.0 so you should be fine if you're still on .NET 5.0 but you might have to update a few lines. Feel free to contact me if you have any issue.

Setting up Consul

I won't get into details of what Consul exactly is, I think you can find a lot on the internet explaining it better than me.
What you'll have to know is that it's basically a server that can register services with keys and routes which can be called by other services.
The main goal is to avoid configuring services with remote addresses of other services but rather configure services with their own informations for others to ask Consul for it.

First things first, we'll create a new deployment file in K8S : consul-depl.yaml. You should now be familiar with the yaml syntax but I'll explain a few things at the best of my ability.

There is 3 blocks, Deployment, Service (ClusterIp) and Service (Load Balancer). It's actually quite straightforward and very similar to what we did with RabbitMQ.

Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: consul-depl
spec:
  replicas: 1
  selector:
    matchLabels:
      app: consul
  template:
    metadata:
      labels:
        app: consul
    spec:
      containers:
        - name: consul
          image: consul:latest
          ports:
            - containerPort: 8500
              name: consul-tcp-port
            - containerPort: 8600
              name: consul-udp-port

Again, It's pretty similar to RabbitMQ, the only difference is the port configuration. Consul uses 8500 for TCP and 8600 for UDP. I found other ports for other purposes, but we'll be fine with these two.
Here are the services (ClusterIp and LoadBalancer), I won't get into details because it's pretty straightforward: we're configuring a ClusterIp to route within Kubernetes and a LoadBalancer to access it.

---
apiVersion: v1
kind: Service
metadata:
  name: consul-clusterip-srv
spec:
  selector:
    app: consul
  type: ClusterIP
  ports:
    - name: consul-tcp-port
      protocol: TCP
      port: 8500
      targetPort: 8500
    - name: consul-udp-port
      protocol: UDP
      port: 8600
      targetPort: 8600
---
apiVersion: v1
kind: Service
metadata:
  name: consul-loadbalancer
spec:
  selector:
    app: consul
  type: LoadBalancer
  ports:
    - name: consul-tcp-port
      protocol: TCP
      port: 8500
      targetPort: 8500
    - name: consul-udp-port
      protocol: UDP
      port: 8600
      targetPort: 8600

All we have to do is apply it with the classic kubectl command: kubectl apply -f consul-depl.yaml.

You should now be able to browse http://localhost:8500/ and get something like that:

If that's the case, Congratulations! You have configured the Service Discovery Server we'll be using for the rest of the posts.

Next up, we'll be setting up RabbitMQ to register to Consul.

Configure RabbitMQ to prepare for Consul

Now this part is a bit tricky, because we're going to update our RabbitMQ deployment to set it up to connect automatically to Consul.

The good news is, RabbitMQ supports Peer Discovery Using Consul with a plugin! All we have to do is set up the configuration files to automatically register. The bad news is, we're going to have to configure a bit more as we're not going to use the default settings anymore. Nothing too tricky but it was a bit daunting to do.

This will be done with a new configuration element of Kubernetes: ConfigMap. Let's open rabbitmq-depl.yaml to add the following config map:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: rabbitmq-config
data:
  enabled_plugins: |
      [rabbitmq_management,rabbitmq_management_agent,rabbitmq_mqtt,rabbitmq_stomp].
  rabbitmq.conf: |
      log.console = true 
      loopback_users.guest = false

What you're seing here is the default configuration I found for RabbitMQ. It already embeds a few plugins, and it is configured to log to console and to allow the guest user to go through loopback.
If you fail to configure the guest user, you won't be able to connect to the management page and you'll get the following message: users can only log in via localhost.

WARNING: The dot (« . ») at the end of enabled_plugins is mandatory. Failing to add it will prevent you from starting RabbitMQ.

Next up we're going to configure the Deployment to access to these elements of configuration, like that:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rabbitmq-depl
spec:
  replicas: 1
  selector:
    matchLabels:
      app: rabbitmq
  template:
    metadata:
      labels:
        app: rabbitmq
    spec:
      containers:
        - name: rabbitmq
          image: rabbitmq:3-management
          ports:
            - containerPort: 15672
              name: rbmq-mgmt-port
            - containerPort: 5672
              name: rbmq-msg-port
          volumeMounts:
            - name: config-volume
              mountPath: /etc/rabbitmq
      volumes:
        - name: config-volume
          configMap:
            name: rabbitmq-config
            items:
              - key: rabbitmq.conf
                path: rabbitmq.conf
              - key: enabled_plugins
                path: enabled_plugins

We added the volumes property, which maps the rabbitmq-config to two files, rabbitmq.conf and enabled_plugins. These are the informations we put earlier in the file with the ConfigMap.
Then we added the volumeMounts property to the container, which maps the config volume to /etc/rabbitmq, which is the folder where RabbitMQ will find its config.

Just reapply and restart with kubectl apply -f rabbitmq-depl.yaml and kubectl rollout restart deployment rabbitmq-depl

Everything should be the same as before. If you have an error at this point, fix it first by checking the logs of the RabbitMQ container through Docker Desktop (or with the console):

Configure RabbitMQ with Consul

Now that you have the few elements required to configure RabbitMQ, we're going to add the rabbitmq_peer_discovery_consul plugin and its configuration to the ConfigMap of rabbitmq-depl.yaml (update it, do not create a new one):

apiVersion: v1
kind: ConfigMap
metadata:
  name: rabbitmq-config
data:
  enabled_plugins: |
      [rabbitmq_management,rabbitmq_management_agent,rabbitmq_mqtt,rabbitmq_stomp,rabbitmq_peer_discovery_consul].
  rabbitmq.conf: |
      log.console = true 
      loopback_users.guest = false
      cluster_formation.peer_discovery_backend = consul
      cluster_formation.consul.host = consul-clusterip-srv
      cluster_formation.consul.svc = rabbitmq
      cluster_formation.consul.svc_addr = rabbitmq-clusterip-srv

The configuration should be:

• cluster_formation.peer_discovery_backend set to consul
• cluster_formation.consul.host should be the ClusterIp you set for Consul, here consul-clusterip-srv
• cluster_formation.consul.svc is the name we'll use to find our service, here rabbitmq
• cluster_formation.consul.svc_addr is the address we want to share for RabbitMQ so rabbitmq-clusterip-srv if you followed the course

Again, just reapply and restart with kubectl apply -f rabbitmq-depl.yaml and kubectl rollout restart deployment rabbitmq-depl

Now if you browse your Consul Management page, you should now be able to see RabbitMQ in the services (alongside with consul, you should have two):

Alright! Be reassured, this was by far the most complicated part of the tutorial in my opinion. You have now configured RabbitMQ to register to Consul, all we have to do now is to update our PlatformService and our CommandService to ask Consul for an address (as opposed to setting it up ourselves).

I was planning on doing it on the same blog post, but let's be honest I think this one is already compact enough.

See you in the next post!

This post is part of a whole:

• .NET Microservices: Service Discovery (Part 1: Consul & RabbitMQ Deployment)
• .NET Microservices: Service Discovery (Part 2: Reaching RabbitMQ through Consul)
• .NET Microservices: Service Discovery (Part 3: Configuring Commands HTTP Service to Consul and consuming it)
• .NET Microservices: Service Discovery (Part 4: Configuring Platform gRPC Service to Consul and consuming it)

Hi everyone!
It has been too long since I posted on this blog.

Here is a small article about a workaround I had to do using ASP.Net Core and its Entity Framework Core (EFCore).

A very useful method on Entity Framework is the raw sql query with a custom type, which goes pretty much like this:

var myCustomList = await context.Database.SqlQuery<CustomType>("SELECT col1, col2, … FROM MyTable").ToListAsync();

This allow you to use custom types to define quick out-of-the-box entities / query mapping, and unfortunately EFCore does not support this (at least right now).

I could not go without this super-useful method, so I made an extension to support it.

Basics

I chose to use AutoMapper for the mapping and AutoMapper.Data which supports implicit IDataReader mapping. (Edit: Note that Jeremy Sinclair wrote a custom method to map the entities that I did no see before, the link is down below).

We need a generic class for the logic (CustomTypeSqlQuery<T>) and an extension to mimic the behavior we like (DatabaseExtensions).

Please beware that only classes are supported, not basic types like string or int.

DatabaseExtensions

First the extension, in a file named DatabaseExtensions.cs :

public static class DatabaseExtensions
{
    public static CustomTypeSqlQuery<T> SqlQuery<T>(
    		this DatabaseFacade database, 
    		string sqlQuery) where T : class
    {
        return new CustomTypeSqlQuery<T>() 
        { 
        	DatabaseFacade = database, 
        	SQLQuery = sqlQuery 
        };
    }
}

This is an extension to DatabaseFacade which will allow us to to something like:

context.Database.SqlQuery<CustomType>("SELECT … FROM …")

and returns a CustomTypeSqlQuery<T>, which holds the logic.

CustomTypeSqlQuery

The full class goes like this:

public class CustomTypeSqlQuery<T> where T : class
{
  private IMapper _mapper;
  
  public DatabaseFacade DatabaseFacade { get; set; }
  public string SQLQuery { get; set; }

  public CustomTypeSqlQuery()
  {
    _mapper = new MapperConfiguration(cfg => {
        cfg.AddDataReaderMapping();
        cfg.CreateMap<IDataRecord, T>();
    }).CreateMapper();
  }

  public async Task<IList<T>> ToListAsync()
  {
    IList<T> results = new List<T>();
    var conn = DatabaseFacade.GetDbConnection();
    try
    {
      await conn.OpenAsync();
      using (var command = conn.CreateCommand())
      {
        command.CommandText = SQLQuery;
        DbDataReader reader = await command.ExecuteReaderAsync();

        if (reader.HasRows)
          results = _mapper.Map<IDataReader, IEnumerable<T>>(reader)
                           .ToList();
        reader.Dispose();
      }
    }
    finally
    {
        conn.Close();
    }
    return results;
  }

  public async Task<T> FirstOrDefaultAsync()
  {
    T result = null;
    var conn = DatabaseFacade.GetDbConnection();
    try
    {
      await conn.OpenAsync();
      using (var command = conn.CreateCommand())
      {
        command.CommandText = SQLQuery;
        DbDataReader reader = await command.ExecuteReaderAsync();

        if (reader.HasRows)
        {
          var results = _mapper.Map<IDataReader, IEnumerable<T>>(reader)
          					 .ToList();
          result = results.FirstOrDefault();
        }
        reader.Dispose();
      }
    }
    finally
    {
        conn.Close();
    }
    return result;
  }
}

As you can see, I create the mapping configuration on the go, which allows me not to declare the mapping. cfg.AddDataReaderMapping() is the method that allows me to map IDataReader directly.

Then I added two methods : ToListAsync() and FirstOrDefaultAsync(). It basically uses a connection and a DbDataReader, which is what Microsoft recommends for raw SQL Queries.

Please note that FirstOrDefaultAsync() is absolutely barbaric inefficient. A better solution would be to parse the results one by one (await reader.ReadAsync()) and return as soon as we have one result. I did this is just for the example.

This allows us to use the extension and the class like this:

var myList = await context.Database.SqlQuery<CustomType>("SELECT … FROM …")
								   .ToListAsync();

« Et voilà ! »

Almost as easy to use as in Entity Framework 6. I am missing support for basic types, it should not be really difficult to do but I do not need it right now. Feel free to contact me if you want your own appendix.

If you want it on github I can do that too.

See you soon!

PS: Jeremy Sinclair did a pretty nice job writing a method to parse from DbDataReader to a class without AutoMapper here

Hi there!

Wanna map a set of keys to a set of values?

You do not want to create a specific converter for each use-case?

I find that normal. Do not let anyone tell you otherwise.

Introducing the brand new DictionaryToValueConverter:

public class DictionaryToValueConverter<T, U> : IValueConverter
{
    public IDictionary<T, U> ValuesMapping { get; set; }

    public object Convert(object value, Type targetType, 
    					  object parameter, CultureInfo culture)
    {
        if (ValuesMapping != null)
        {
            var keyT = (T)key;
            if (ValuesMapping.ContainsKey(keyT))
                return ValuesMapping[keyT];
            else
                return default(U);
        }
        else
            return default(U);
    }

    public object ConvertBack(object value, Type targetType, 
    						  object parameter, CultureInfo culture)
    {
        throw new NotImplementedException(); // not relevant
    }
}

That converter will map a key to a value. For instance it could be a color for each enum value (we will get to that).

I did not implement the convert back as you could map several keys to the same value. It would not be relevant as you could find several keys for the same value. If you still want to you can use something like that:

public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
{
	if (ValuesMapping != null)
	{
	    var valueU = (U)value;
	    var kvps = ValuesMapping.Where(kvp => kvp.Value.Equals(valueU));

	    if (kvps.Any())
	        return kvps.First().Key;
	    else
	        return default(T);
	}
	else
	    return default(T);
}

But I would not approve that.

To declare this awesome converter you can follow the example right here:

var myEnumToColorConverter = new DictionaryToValueConverter<MyEnum, Color>()
{
	ValuesMapping = new Dictionary<MyEnum, Color>
		{
			{ MyEnum.Enum1, Color.Red },
			{ MyEnum.Enum2, Color.Green },
			{ MyEnum.Enum3, Color.Blue },
			{ MyEnum.Enum4, Color.Yellow }
		}
};

And to use it:

myObject.SetBinding<ObservableObject>(MyObject.ColorProperty, 
								      o => o.EnumValue, 
                                      converter: myEnumToColorConverter);

All done.

Of course you can also use:

SetBinding(MyObject.ColorProperty, new Binding("EnumValue", converter: myEnumToColorConverter))

I am not a monster. Do whatever you want. Use XAML if you prefer.

Last-minute tips:

Do not declare a converter per view. Create a converter and use it for all your views.

Do not create too complex things. The simpler the better, if you are re-creating the earth each time you might want to create a specific converter.

In short words: be smart.

Paul, out!

Hi there!

Ever had the issue to convert a more or less complex lambda expression into a boolean in a Xamarin Forms view?

Like « I want to show something only for a property that matches my condition »?

Ever had the error: System.ArgumentException: Invalid expression type?

/!\ Warning: this article could cause severe bleeding for the eyes of the purist. This is kind of a hack. I know that. Defining a lambda in the view, etc. /!\

Well seek no more my friend, here is the LambdaToBooleanConverter:

public class LambdaToBooleanConverter<T> : IValueConverter
{
    public Func<T, bool> Lambda { get; set; }

    public object Convert(object value, Type targetType, 
    					  object parameter, CultureInfo culture)
    {
        var valueT = (T)value;
        return Lambda(valueT);
    }

    public object ConvertBack(object value, Type targetType, 
    						  object parameter, CultureInfo culture)
    {
        throw new NotSupportedException(); // not relevant.
    }
}

You can use this in your view like that:

var isVisibleConverter = new LambdaToBooleanConverter<User>() 
	{ 
    	Lambda = u => u.Status == Status.Admin 
    };

myControl.SetBinding<MyObservableObject>(MyControl.IsVisibleProperty, 
										 o => o.User, 
                                         converter: isVisibleConverter);

Remember to bind on the element that implements the INotifyPropertyChanged.

XAML-side: you might need to declare it in code-behind (not a big fan of the solution).

This is probably not efficient in terms of performance but it does the job.

Do not use and abuse complex lambdas: if it is too complex you are probably doing something wrong.

Do not uselessly declare more than once your converters.

This only solves a minor use-case I had that I did not want to refactor. I my case it was an ObservableObject that added commands to a DTO.
I did not wanted to re-create every property of the DTO but still wanted to bind an expression of the DTO.

Paul, out!

Hi there!

How have you been? Happy new year to all of you!

It is time to get to the third (already!) part of these blog posts about Azure App Services Custom Authentication.
We will now be talking about the client-side authentication.

Again, this post is part of a whole:

• Azure App Services Custom Auth (Part 1: user management)
• Azure App Services Custom Auth (Part 2: server authentication)
• Azure App Services Custom Auth (Part 3: client authentication)
• Azure App Services Custom Auth (Part 4: cross-provider users) — soon

We have thanks to the first two parts a system that is able to:

• Create and manage users
• Generate tokens from user informations
• Request and validate queries by authentication

Which is already pretty great in my opinion! However you probably want to use the azure app services framework on the client-side with our custom auth and I am here to deliver.

Azure App Services Client

The very first thing we will need is to introduce the client framework of Azure App Services. I did not do this properly before.

I will use the .NET managed version of it in a PCL project (Xamarin Forms).
There might be some slight differences for other platforms but nothing that you should not be able to handle.

We will need to define the MobileServiceClient which is the object we can use later for all our requests. Microsoft made it quite simple for us:

var client = new MobileServiceClient(@"https://mywebsite.azurewebsites.net/");

Remember to use the HTTPS protocol.

I also strongly advice you to use ModernHttpClient which handles a bit better the http requests. To use it with Azure App Services we only need to pass on their handler in the constructor:

var client = new MobileServiceClient(@"https://mywebsite.azurewebsites.net/", 
					new NativeMessageHandler());

Both these nuget packages (Azure App Services Client and ModernHttpClient) have to be embedded on your projects using it and on your specific project (iOS, Android, …) if I am correct.

I advise you to declare your mobile client only once and access it with a container by dependency injection.
For instance, I have defined a ServerManager class and a IServerManager interface in charge of creating, controlling and accessing the instances of MobileServiceClient (I have several client services).
This container is in charge of login and logout my users too.

You can also pass on directly the client with the IMobileServiceClient interface if you do not need a container.

I will consider you have access to a declared mobile services client named _client for the rest of the article.

Authenticate the user

If you followed the previous blog post on custom auth, this step should be pretty straightforward.
You will need a registered user as seen on the first part of this topic (call controller from client).
Just to remind you quickly how it works here are the required steps for the auth:

• Get the token from user informations
• Use the token for requests
• Store the token for future use

All of this will be pretty simple.

Get the token

For this step, you will need to ask the user for his / her informations. You can simply create a screen with email / password fields and a login button.

It is not really relevant here to blog about UI, so I will just give you a method to get the token with this signature:

Task<AuthenticationToken> GetAuthenticationToken(string email, 
												 string hash);

The response we will receive is a classic JSON so we will need the following class to parse it. This is the response we got from the /oauth/token endpoint in the previous post:

public class AuthenticationToken
{
    public string Guid { get; set; }
    public string Access_Token { get; set; }
    public string Token_Type { get; set; }

    [JsonProperty(".expires")]
    public DateTime Expires { get; set; }
}

The implementation is then pretty straightforward, we only need to send the data like we did testing our server:

public async Task<AuthenticationToken> 
		GetAuthenticationToken(string email, string password)
{
	// define request content
    HttpContent content = new StringContent(
    string.Format("username={0}&password={1}&grant_type=password", 
                  email.ToLower(), 
                  password));
                                    
    // set header
	content.Headers.ContentType 
    = new MediaTypeHeaderValue("application/x-www-form-urlencoded");

	// invoke Api
	HttpResponseMessage response 
    	= await _client.InvokeApiAsync("/oauth/token", 
            						   content, 
            						   HttpMethod.Post, 
            						   null, 
            						   null);

	// read and parse token
    string flatToken = await response.Content.ReadAsStringAync();
    return JsonConvert
    		.DeserializeObject<AuthenticationToken>(flatToken);
}

As you can see we use the magic of the framework to do it all!
We are simply using a POST request with the informations (url encoded) to /oauth/token (the endpoint we defined earlier).
Then we get the flat token and deserialize it as an AuthenticationTicket.

Note that emails are not case-sensitive, which is why I registered and authenticated the users with an email.ToLower().

I strongly advise you to use custom exceptions for invalid grant like this:

public async Task<AuthenticationToken> 
		GetAuthenticationToken(string email, string password)
{
	try
    {
    	// all we did before
    }
    catch (MobileServiceInvalidOperationException exception)
    {
    	if (string.Equals(exception.Message, "invalid_grant"))
            throw new InvalidGrantException("Wrong credentails", 
            								exception);
        else
        	throw;
	}
}

Use the token

The underlying idea on the previous article was to fit as best as we could to the existing mechanism to simplify this very step.

The AuthenticationToken we got from the server has all the informations needed for the MobileServiceClient to handle authentication.

We now simply need to pass them as a MobileServiceUser to the client like this:

public async Task Authenticate(string email, string password)
{
	// get the token
	var token = await GetAuthenticationToken(email, password);

	// authenticate: create and use a mobile service user
	MobileServiceUser user = new MobileServiceUser(token.Guid);
	user.MobileServiceAuthenticationToken = token.Access_Token;
    _client.CurrentUser = user;
}

And… that's it.

Yes.

That's it.

Now every query that the client will make will pass on a X-ZUMO-AUTH header, granting access to all methods flagged as [Authorize].
That also include the whole synchronization mechanism and the SQLiteStorage mechanism.

As long as the token is valid everything will work fine.

Store the token

We do not want the user to log in each time (s)he opens the application, which is why we will need to store and re-use the token.

If you followed the explanations on the previous post you will not be surprised when I tell you that the token only has some basic informations, and that its signature is strongly signed. This means we can store the token unsecurely without compromising our security.

However, a fraud could steal the token on the phone and make requests pretending to be the user. While it is very unlikely I advise you to securely store the token as well as the user id (better safe than sorry).

I will post in a next article an implementation for a cross-platform vault, meanwhile we will consider the next interface:

public interface ISecureStorage
{
	void Store(string key, string value);
	string Retrieve(string key);
	void Delete(string key);
    bool Contains(string key);
} 

If you absolutely need it right now I believe an implementation can be found in the XLabs project. Meanwhile you can also store the token and user id in the settings even if it is not the best option.

You can then store the informations easily:

public async Task Authenticate(string email, string password)
{
	// get token
    var token = await GetAuthenticationToken(email, password);

    // authenticate
    // …

    // store settings
    _secureStorage.Store("UserId", token.Guid);
    _secureStorage.Store("Token", token.Access_Token);
}

And you can handle the invalid grant to clean user informations:

public async Task Authenticate(string email, string password)
{
	try
    {
    	// previous code
    }
    catch (InvalidGrantException)
    {
    	_secureStorage.Delete("UserId");
    	_secureStorage.Delete("Token");
        
        // alert user!
    }
}

The last step is to use these informations on the opening of the application to log-in right away.
For instance, it can be done when you create you MobileServiceClient.

It is exactly like before but with the stored informations:

public async Task AutoAuthenticate()
{
    if (_secureStorage.Contains("UserId") 
    	&& _secureStorage.Contains("Token"))
    {
        var id = _secureStorage.Retrieve("UserId");
        var token = _secureStorage.Retrieve("Token");

        var user = new MobileServiceUser(id);
        user.MobileServiceAuthenticationToken = token;
        _client.CurrentUser = user;
    }
}

You can use this method on the start of the application or anywhere you want to log the user automatically.

Now as long as the authentication token is valid this will be enough. But the real issue is when it expires…

Reauthenticate the user after token expiration

There would be two ways to implement it: use a refresh token mechanism or store their credentials.

I used the latter which means that for this part you will absolutely need a secure storage for this mechanism.

Email and password should NEVER be stored without encryption even on the client.

The code is pretty simple: if a user logs successfully we register his / her credentials and the token expiration like this

public async Task Authenticate(string email, string password)
{
    // previous authentication code

    // store settings
    _secureStorage.Store("UserId", token.Guid);
    _secureStorage.Store("Token", token.Access_Token);
    _secureStorage.Store("TokenExpirationDate", 
    					 token.Expires.Ticks.ToString());
    _secureStorage.Store("UserEmail", email);
    _secureStorage.Store("UserPassword", password);
}

I chose to store the expiration date as a string with the date's ticks. If you have a better option you can comment below to offer me better solutions :)

Remember to clean every information we added here when the user enters invalid credentials.

The last step is to check on start if the token is expired and re-authenticate the user if it is.

public async Task AutoAuthenticate()
{
	if (_secureStorage.Contains("UserId") 
	      && _secureStorage.Contains("Token") 
    	  && _secureStorage.Contains("TokenExpirationDate"))
	{
		var expirationDateTicks 
        	= _secureStorage.Retrieve("TokenExpirationDate");
	    DateTime expirationDate 
        	= new DateTime(long.Parse(expirationDateTicks));
    
		if (expirationDate < DateTime.Now)
	    {
        	// you can also check first if email and password exists
	    	var email = _secureStorage.Retrieve("UserEmail");
    		var password = _secureStorage.Retrieve("UserPassword");
            
            await Authenticate(email, password);
    	}
	    else
	    {
	      var id = _secureStorage.Retrieve("UserId");
    	  var token = _secureStorage.Retrieve("Token");

	      var user = new MobileServiceUser(id);
    	  user.MobileServiceAuthenticationToken = token;
	      _client.CurrentUser = user;
    	}
	}
}

And we are done!

We have a system for the client that can authenticate, auto-authenticate on start and re-authenticate when the token is expired.

Finally

Apart from the ISecureStorage implementation, you should have everything you need to use our brand new custom authentication!

As you can see, a single article for both client and server authentication would have been HUGE which is why I splitted it.

If you have any remark, question, suggestion, please use the comment section below! I am always glad to hear from you, even with a comment saying hi.

But wait… you said there would be a forth article? Why? Have we not everything we need like you said?
Well I feel there is still some work to be done. On the next article, we will see how we can integrate our custom auth with the existing auth (Facebook, Twitter, G+, Microsoft, AAD, …) in order to make our server fully transparent regarding the origin of the auth. We will create cross-platform users.

See you soon!

Paul, out!

This post is part of a whole:

• Azure App Services Custom Auth (Part 1: user management)
• Azure App Services Custom Auth (Part 2: server authentication)
• Azure App Services Custom Auth (Part 3: client authentication)
• Azure App Services Custom Auth (Part 4: cross-provider users) — soon

Hello again everyone!

I hope the first part was interesting enough, on this second part we are going to introduce the authentication by token part.

Once again, this post is part of a whole:

• Azure App Services Custom Auth (Part 1: user management)
• Azure App Services Custom Auth (Part 2: server authentication)
• Azure App Services Custom Auth (Part 3: client authentication)
• Azure App Services Custom Auth (Part 4: cross-provider users) — soon

On the first part we only saw the user management and now we currently have a system that can add users from the client and access them quite simply from the server.

How token-authentication works

We are doing authentication, so it is best if we understand how it works.
I will quickly sum up how token based authentication works.
You can skip this whole part if you are familiar with the concepts and go straight to « Azure App Services Implementation ».

Three-party mechanism

The very first step is to understand that we have three parties involved here.

• A user: well, that makes sense
• A grant provider: this server is in charge of verifying and guaranteeing the user is who he says he is
• An application server: this server trusts the provider that the user is verified by him and uses the informations the provider passes on as trusted

To ensure that trust the grant provider and the application server share a common signing key. In the case of social network providers (Facebook, Twitter, Google, …) these are represented by your app id / app secret.

The two servers will share a token that the user will pass on each request allowing the application server to verify the authentication.

In our case the provider and the application server will be the same server. On an ideal situation we could separate these and avoid stocking the user informations on the application server (such as authentication by social providers).

Signing Key & Token

In case of JWT (JSON Web Tokens) we have a header, a body and a signature. While the header and the body can easily be decrypted (and thus cannot be considered safe) the signature is a hash of the informations with the signing key.
For testing purposes you can decrypt and check signatures of JWT tokens on http://jwt.io/.

That means that only somebody that has the signing key can generate tokens that will be validated by our server. This is a strong symetric signing and a great way to share secured informations.

That also mean that the signing key is the most precious security information. It must never be stored on the client and it must remain hidden and securely stored at anytime by both parties.

/!\ Do not transfer a key by mail, by chat, by SMS, by USB Key, anything, never, ever, ever /!\

also,

/!\ No signing keys in the code, no secrets under version control or stored in a possibly insecure location /!\

A leak of the signing key will compromise your whole security allowing intruders to pretend they are anyone they want to be.

Almost all security hacks are not done by cracking overly complicated security systems.
On this article you will see it would take billions of years to crack even a simple encryption.

Most hacks are done using weak security leaks (password security questions, shared passwords between apps, weak passwords, weak security elsewhere, …) and you must remember that your whole security system is as weak as your weakest point.

Store your secrets and password securely with tools such as KeePass and keep them unique whenever you can.

First authentication by email / password

Back to the good part!
Users authenticate for the first time using their email and their password. This step is necessary to ensure the user is whoever he claims he is.

To do this we are passing the email and password securely (HTTPS, HTTP over SSL) and the provider is checking everything is correct.

In case of success a token is generated. This token encrypts claims such as the nameidentifier, the audience, the issuer, etc.

Token transmission

Each request a user make will include a token in the form of a HTTP Header (X-ZUMO-AUTH for Azure App Services — aZUre MObile).

The server will check the validity of the token (expiration date, issuer, audience, signature) and use the informations stored in the token locally (user id, user name, …).

Refresh token

A token has an expiration date and to keep a token alive there is a mechanism of token refreshment. I will not cover this here.

Azure App Services Implementation

We are going to use JWT Tokens, OAuth mechanisms from Identity and the existing mechanisms of Azure App Services to keep it as simple as possible.

Strategy

What we need to do to achieve our goal is pretty simple:

• Expose a /oauth/token endpoint on which users can send their email / password
• Generate claims and an authentication ticket from their informations (or reject him if the infos are wrong)
• Generate and send a token to the user

The existing mechanisms will take care of the rest (validating, interpreting and storing the token). The solution I offer uses consumption mechanisms of Azure App Services.

ApplicationUser.GenerateUserIdentityAsync, generating claims

The first thing we want to do is to generate Claims from a user. For this we will use the existing mechanisms of Identity and go to our ApplicationUser class to add a method named GenerateUserIdentityAsync.

The implementation is right here:

public async Task<ClaimsIdentity> GenerateUserIdentityAsync(
		UserManager<ApplicationUser> manager, 
		string authenticationType)
{
	var userIdentity = await manager.CreateIdentityAsync(this, 
									authenticationType);
    userIdentity.AddClaim(new Claim(JwtRegisteredClaimNames.Sub, 
    								this.UserName));
    return userIdentity;
}

This allows us to generate the ClaimsIdentity from a user which we will use on our authentication mechanism.
We need to add a claim for Azure App Services (which is the Sub claim) on which we will put the username of the user.

CustomAuthProvider, validating the user

We will need a provider that can grant users their credentials. In a folder « Providers » we will create the CustomAuthProvider, deriving from OAuthAuthorizationServerProvider. Once again, the existing mechanisms will avoid us to reimplement everything. This class comes from the Microsoft.Owin.Security.OAuth nuget package.

Here is the implementation of this class:

public class CustomAuthProvider : OAuthAuthorizationServerProvider
{
    public override Task ValidateClientAuthentication(
    				OAuthValidateClientAuthenticationContext context)
    {
        context.Validated();
        return Task.FromResult<object>(null);
    }

    public override Task TokenEndpoint(OAuthTokenEndpointContext context)
    {
        foreach (KeyValuePair<string, string> property in 
        			context.Properties.Dictionary)
        {
            context.AdditionalResponseParameters.Add(property.Key,
            										 property.Value);
        }

        return Task.FromResult<object>(null);
    }

    public override async Task GrantResourceOwnerCredentials(
    					OAuthGrantResourceOwnerCredentialsContext context)
    {
        var allowedOrigin = "*";

        context.OwinContext.Response.Headers.Add(
        			"Access-Control-Allow-Origin", 
                    new[] { allowedOrigin });

        var userManager = context.OwinContext
        						 .GetUserManager<ApplicationUserManager>();

        ApplicationUser user = await userManager.FindAsync(context.UserName,
        												  context.Password);

        if (user == null)
        {
            context.SetError("invalid_grant", 
            				 "The user name or password is incorrect.");
            return;
        }
        
        ClaimsIdentity oAuthIdentity = 
        	await user.GenerateUserIdentityAsync(userManager, "JWT");
            
        var props = new AuthenticationProperties(
        	new Dictionary<string, string> { { "guid", user.Id } });
        var ticket = new AuthenticationTicket(oAuthIdentity, props);
            
        context.Validated(ticket);
    }
}

On this class we are granting the users credentials from a OAuthGrantResourceOwnerCredentialsContext generated from the request.

We are fetching the user from the username sent by the context with the user manager and we are creating an AuthenticationTicket from the JWT claims we generated. Note that I also add the user.Id in the response, which will be useful later on the client-side.

This AuthenticationTicket will be encrypted into a token by our next class:

CustomZumoTokenFormat, encrypting claims

In the same folder we will create this class responsible for creating a token from the claims we generated.
The tricky thing here is to fit to the implementation of Azure App Services so we will not have to implement the consumption mechanism again.

public class CustomZumoTokenFormat : ISecureDataFormat<AuthenticationTicket>
{
    private string _host = string.Format("https://{0}.azurewebsites.net/", 
    		Environment.ExpandEnvironmentVariables("%WEBSITE_SITE_NAME%")
            .ToLower());

    public string Protect(AuthenticationTicket data)
    {
        if (data == null)
            throw new ArgumentNullException("data");

        // Get Signing Key and send x-zumo-auth token from claims
        string signingKey = GetSigningKey();
        var tokenInfo = AppServiceLoginHandler.CreateToken(
        		data.Identity.Claims, 
                signingKey, 
                _host, 
                _host, 
                TimeSpan.FromHours(24));
            
        return tokenInfo.RawData;
    }

    public AuthenticationTicket Unprotect(string protectedText)
    {
        throw new NotImplementedException();
    }

    private static string GetSigningKey()
    {
        string key = 
        	Environment.GetEnvironmentVariable("WEBSITE_AUTH_SIGNING_KEY");

        if (string.IsNullOrWhiteSpace(key))
            key = ConfigurationManager.AppSettings["SigningKey"];

        return key;
    }
}

While on the first versions I had to decompile their code to get the signing key (which had a different name), Azure App Services open sourced their code and included this GetSigningKey() method that I find pretty elegant.

The AppServiceLoginHandler.CreateToken(…) is also a very helpful class and beautifully exposed. I used to hack my way to get access to this class, decompiling the code to see how they exposed and used it (that was a different name).

What we are doing here is simply taking the AuthenticationTicket and creating the associated signed token with their handler.

I generated the host with the environment variable because I had trouble getting a correct issuer / audience for this token. If anyone has a better way to get or create the correct issuer I am opened to suggestions in the comments!

OAuthAuthorizationServerOptions, exposing the endpoint

Almost done! What we have left to do is to expose our endpoint and assemble the bricks we created.

For this, just go to your OWIN Startup class. We will create a new method ConfigureCustomAuth with this implementation:

public static void ConfigureCustomAuth(IAppBuilder appBuilder)
{
	OAuthAuthorizationServerOptions oAuthServerOptions = 
    	new OAuthAuthorizationServerOptions()
    	{
    		TokenEndpointPath = new PathString("/oauth/token"),
        	Provider = new CustomAuthProvider(),
        	AccessTokenExpireTimeSpan = TimeSpan.FromDays(1),
        	AccessTokenFormat = new CustomZumoTokenFormat(),
    	};

	// OAuth Configuration
    appBuilder.UseOAuthAuthorizationServer(oAuthServerOptions);
}

Our endpoint will be exposed on /oauth/token, with the provider and the token format we created before.

Calling the /oauth/token endpoint with the user email and password will validate them and create a signed token.

And this is were the magic happens: this token is correctly formatted for Azure App Services which means we do not have to re-implement the consumption!

Finally, we only have to use our method on the Configure method to expose everything correctly:

public void Configuration(IAppBuilder appBuilder)  
{
    // … (part 1 code)

    ConfigureCustomAuth(appBuilder);
}

Protecting our methods

Now that we have implemented this authentication we can simply use the [Authorize] keyword on a controller or a method to restrict the acces only to authenticated users.

Here is my implementation of GetUser to show you:

public class AccountsController : BaseAuthApiController
{
	[Route("user/{id:guid}", Name = "GetUserById")]
    [Authorize]
    public async Task<IHttpActionResult> GetUser(string Id)
    {
    	var userId = User.Identity.GetUserId();
        var user = await this.AppUserManager.FindByIdAsync(Id);

		if (user != null)
        {
        	if (user.Id != userId)
            	throw new HttpException(401, 
                	"You cannot get other users informations");
            else
            	return Ok(this.TheModelFactory.Create(user));
        }

        return NotFound();
    }
    
    …
}

This User.Identity.GetUserId() comes from an extension (IdentityExtensions from Microsoft.AspNet.Identity.Core).

Testing the authentication

First do not forget to set locally a signing key (SigningKey in app settings), this can be any 128 bits key with hexadecimal values, you can find implementations on the internet.

Then we need to add to the code if we want to test locally is to disable the HTTPS, so add this line on the authentication declaration:

 OAuthAuthorizationServerOptions oAuthServerOptions = 
 	new OAuthAuthorizationServerOptions()
    	{
#if DEBUG
        	AllowInsecureHttp = true, // NEVER IN PRODUCTION!
#endif
    		TokenEndpointPath = new PathString("/oauth/token"),
        	Provider = new CustomAuthProvider(),
        	AccessTokenExpireTimeSpan = TimeSpan.FromDays(1),
        	AccessTokenFormat = new CustomZumoTokenFormat(),
    	};

Remember we are dealing with passwords which means we absolutely need the HTTPS protocol. If we forget this anyone listening could get the informations of the user.

Now I will assume you have a user created here. You just have to take a REST client such as the awesome chrome extension Advanced REST Client.

Use http://localhost:port/oauth/token with a POST method.
We will send a form (application/x-www-form-urlencoded type) with the values

• username : myusername
• password : mypassword
• grant_type : password

The server will answer with a guid and a access_token (among other things). The first one is the additional property we passed on, and the second is the encrypted token with your claims.

You can partially decrypt the token at http://jwt.io. You will see the different claims (ver(sion), iss(uer), aud(ience), etc.) and you can check that the signature is right using your signing key.

Now you can test your secure endpoints using this token, simply pass on two headers when you reach them:

• X-ZUMO-AUTH : your_access_token
• ZUMO-API-VERSION : 2.0.0

The first was is responsible of the authentication, the second was introduced in the latest version of Azure App Services to version their back-end.

You can try this for instance on the GetUser method we authorized later.

Finally

To be honest I did not think this post would be this long and that is why I splitted it into a server-side part and a client-side part.

We have set the biggest part of the authentication on this post and I hope it was easy enough to understand. I also hope you are not disappointed by the fact we could not get into the client-side here.

I would like once again to thank Taiseer Joudeh for his amazing posts on Identity, this was really the foundation of all this authentication.

If you have any question or any remark to make please feel free use the comments below, I will be glad to know what you think of all this if some points are unclear or if you have suggestions.

Paul, out!

This post is part of a whole:

• Azure App Services Custom Auth (Part 1: user management)
• Azure App Services Custom Auth (Part 2: server authentication)
• Azure App Services Custom Auth (Part 3: client authentication)
• Azure App Services Custom Auth (Part 4: cross-provider users) — soon

Greatings everyone!

I have spent a lot of time making a custom auth work on Azure App Services with a .NET backend. And it is about time I share this, as many users need it.

I first published a working custom auth around April 2015, on a version of App Services that was clearly not designed to do this simply.

I had to hack my way through a lot of complicated stuff at that time and now that App Services have been improved and simplified (and is getting ready for production), I feel it is time to make a huge post about custom auth.

I have spent so much time trying to figure this out that I truly believe this blog post might help a lot of users.

This post is part of a whole:

• Azure App Services Custom Auth (Part 1: user management)
• Azure App Services Custom Auth (Part 2: server authentication)
• Azure App Services Custom Auth (Part 3: client authentication)
• Azure App Services Custom Auth (Part 4: cross-provider users) — soon

What you need to know

You need basic knowledge on these stuff, not expertise. But I will not be covering them, first because many people did this way better than me and second because I want to focus on other things.

• ASP.Net:
  Needless to precise, but still
• Code first migrations: You will need to know how to do it, and to have done it for your business context
• OWIN: We are going to mess up with it.
• Azure App Services: I will not cover up how to set-up AAS

You also need to know that I use another tutorial as a base, made by a far more advanced developper than I am: Taiseer Joudeh.
His tutorials on AspNet.Identity were the real reason I could achieve this custom auth. Let's take a minute of silence to honor his talent.

…

Now, you can find the part 1 of his tutorials here: http://bitoftech.net/2015/01/21/asp-net-identity-2-with-asp-net-web-api-2-accounts-management/

If you look at them, you will see a lot of code is shared for this particular post, and I truly hope he does not think I am just copying the content as this is for me the base for what is coming next. Adapting his work on Azure App Services is the true value of my blog posts. Think of it as public class PaulBlogPost : TaiseerBlogPost.

Basically, we are going to use AspNet.Identity. Note that you do not necessarly need to use it, but I feel this is the most simple way to achieve our goal.

ApplicationUser

This class will represent a user for us, and will inherit IdentityUser. You will need the nuget package Microsoft.AspNet.Identity.EntityFramework in order to do this.

Here is a basic implementation of ApplicationUser:

public class ApplicationUser : IdentityUser
{
    [Required]
    public string FirstName { get; set; }

    [Required]
    public string LastName { get; set; }

    [Required]
    public DateTime JoinDate { get; set; }
}

Note that these three properties are custom-made, you could very well not use them, or defining other properties.
For instance I have a property ProfilePictureUri for the picture of the user. I also have a Provider property, to know if my user comes from Facebook, my auth, or anything else.
What you put on a user to define him is really up to you!

ApplicationDbContext

You probably already have a Context for you business logic. We are going to create a whole new context for the users.
Even if you do not necessarly need to do this, I think it is the best way to go because you need to decouple as much as possible your user private informations from their application data.
That way if one day you want to create your own authentication server you have no link between the user data and the user informations.

Now this is what this context look like:

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    private const string connectionStringName = "Name=MS_TableConnectionString";
        
    public ApplicationDbContext() : base(connectionStringName, throwIfV1Schema: false)
    {
        Configuration.ProxyCreationEnabled = false;
        Configuration.LazyLoadingEnabled = false;
    }

	protected override void OnModelCreating(DbModelBuilder modelBuilder)
	{
	    base.OnModelCreating(modelBuilder);
	    modelBuilder.HasDefaultSchema("Application");
	}
        
    public static ApplicationDbContext Create()
    {
        return new ApplicationDbContext();
    }
}

I use the MS_TableConnectionString that is defined on App Services to use the same database.
Not that I put the default schema Application to decouple at a schema level the User informations from their data.

ApplicationConfiguration & Initial Migration

As we have two schema / context, it makes sense to create two configurations. You should already have a configuration for your business logic, we will now create another one for the other Context:

internal sealed class ApplicationConfiguration : DbMigrationsConfiguration<ApplicationDbContext>
{
    public ApplicationConfiguration()
    {
        AutomaticMigrationsEnabled = false;
    }
}

Really nothing special here. Regarding your architecture, I recommend to have a folder « Migrations », on which you will have two folders: « Application » and « Business » (or the name of your app instead of Business).

Now create your initial migration with the following line:

Add-Migration InitialApplicationMigration -ConfigurationTypeName ApplicationConfiguration

ApplicationUserManager

This manager will allow us to get the users, and will be used by OWIN. The UserManager class is in the nuget package Microsoft.AspNet.Identity.Core.
It needs basic stuff, such as a factory, and here is the implementation:

public class ApplicationUserManager : UserManager<ApplicationUser>
{
    public ApplicationUserManager(IUserStore<ApplicationUser> store) : base(store)
    {
        UserValidator = new UserValidator<ApplicationUser>(this) { AllowOnlyAlphanumericUserNames = false };
    }

    public static ApplicationUserManager Create(IdentityFactoryOptions<ApplicationUserManager> options, 
    											IOwinContext context)
    {
        var appDbContext = context.Get<ApplicationDbContext>();
        var appUserManager = new ApplicationUserManager(new UserStore<ApplicationUser>(appDbContext));
        return appUserManager;
    }
}

Just to clarify, I used AllowOnlyAlphanumericUserNames to use the email address as the username. You can do as you want on your side.

OwinStartup, OwinContext & DbMigrator

Let's get down to business with OWIN. We have two things to do, define the ApplicationUserManager per OWIN Context and update database on start.

I advise you to update your database on start, because that way you will not need to bother to update your databases on your servers each time. The simple fact that you push in production will set the database up to date regarding your current schema and migrations.

Now we have to create the OWIN Startup class: right click on your project -> Add -> New Item -> OWIN Startup class.

You will end up with an empty class with a Configuration method. We will first add the factory for the context and the user manager:

public void Configuration(IAppBuilder appBuilder)
{
	appBuilder.CreatePerOwinContext(ApplicationDbContext.Create);
	appBuilder.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
    
    // …
}

This will allow us to access the manager and the context from the middleware. This is part of the Microsoft.AspNet.Identity.Owin nuget package.
Then we add our basic mobile code:

public void Configuration(IAppBuilder appBuilder)
{
	// …

    HttpConfiguration config = new HttpConfiguration();
    config.MapHttpAttributeRoutes();

    new MobileAppConfiguration()
        .AddMobileAppHomeController()
        .AddTablesWithEntityFramework()
        .MapApiControllers()
        .ApplyTo(config);

    appBuilder.UseWebApi(config);
    
    // …
}

Note that you may have a different mobile configuration, use what you need.
And finally we add our database migration code:

public void Configuration(IAppBuilder appBuilder)
{
	// …
	
    ConfigureDbMigration();
}

The method ConfigureDbMigration is where we configure our migrations and here is the implementation:

private void ConfigureDbMigration()
{
    // DbMigrator businessMigrator = new DbMigrator(new BusinessConfiguration());
    // businessMigrator.Update();

    DbMigrator applicationMigrator = new DbMigrator(new ApplicationConfiguration());
    applicationMigrator.Update();
}

I have commented the business part, as what I want to show you here is the application migration. But as you can see, I have a migration for both my Configurations.

Accounts Api Controller

Now that we have defined all we need to manipulate users, create them and stuff. But we still need to expose this through a controller.

Here is the definition of my controller:

[RoutePrefix("api/accounts")]
public class AccountsController : BaseAuthApiController
{
	[Route("user/{id:guid}", Name = "GetUserById")]
	[Authorize]
	public async Task<IHttpActionResult> GetUser(string Id);
    
	[Route("user/{username}", Name = "GetUserByName")]
	[Authorize]
	public async Task<IHttpActionResult> GetUserByName(string username);

	[Route("create")]
	[AllowAnonymous]
	[ResponseType(typeof(UserReturnModel))]
	public async Task<IHttpActionResult> CreateUser(AccountBindingModel createUserModel);
}

Once again, Taiseer did this work, so I will let you find the implementation of this controller on his amazing blog post from step 7 to 10: http://bitoftech.net/2015/01/21/asp-net-identity-2-with-asp-net-web-api-2-accounts-management/

Just note the use of [Authorize] and [AllowAnonymous], which will ensure the methods are used correctly.

Call controller from client

You cannot use the [Authorize] controlled methods yet because we did not grant users right, at least for the moment.

But I think we can already introduce the use of the Api from the front-end. I will be doing this with the .NET SDK (I am on Xamarin), but any other SDK would work basically the same way.

As you have seen, the CreateUser method uses two models: AccountBindingModel and UserReturnModel. We will need them both on the client-side. UserReturnModel is really close to ApplicationUser and that is the name I used on the client (it was more explicit):

public class AccountModelBinding
{
    public string Email { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Password { get; set; }
    public string ConfirmPassword { get; set; }
}

public class ApplicationUser
{
    public string Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Email { get; set; }
}

Now with these elements, the beauty of the SDK does it all for us, by using .InvokeApiAsync:

IMobileServiceClient mobileServiceClient = new MobileServiceClient("http://mywebsite.azurewebsites.net/");
AccountModelBinding accountModelBinding = …; // fill with your informations

ApplicationUser createdUser = await mobileServiceClient.InvokeApiAsync<AccountModelBinding, ApplicationUser>("accounts/create", accountModelBinding);

Error handling from the client

If you want to handle the errors, you can simply catch the MobileServiceInvalidOperationException and look at the content like this:

try  
    {
        // …
    }
    catch (MobileServiceInvalidOperationException exception)
    {
        if (exception.Response.StatusCode == HttpStatusCode.BadRequest)
        {
            /* If you don't have the latest framework */
            Task<string> readContentTask = exception.Response.Content.ReadAsStringAsync();
            readContentTask.Wait();

            if (readContentTask.Result.Contains("is already taken."))
                throw new AccountAlreadyTakenException("Account already taken", exception);
            else
                throw;
        }
        else
            throw;
    }

Or even better with the latest version of .NET where you can await on catch:

try  
    {
        // …
    }
    catch (MobileServiceInvalidOperationException exception)
    {
        if (exception.Response.StatusCode == HttpStatusCode.BadRequest)
        {
            /* If you have the latest framework */
            string content = await exception.Response.Content.ReadAsStringAsync();

            if (content.Contains("is already taken."))
                throw new AccountAlreadyTakenException("Account already taken", exception);
            else
                throw;
        }
        else
            throw;
    }

AccountAlreadyTakenException being an exception that I created for this occasion. Check out the HttpStatusCode you need to handle and the message writen with it to filter the exceptions.

I recommend using custom exceptions to handle this like I did.

Finally

You have now made the first step for a custom authentication on Azure App Services, by handling user management.

On the next episode, we will see how to grant users the access to the precious [Authorize] methods (baised on claims).

If you have any question or any remark to make please feel free use the comments below, I will be glad to know what you think of all this if some points are unclear or if you have suggestions.

Paul, out!

This post is part of a whole:

• Azure App Services Custom Auth (Part 1: user management)
• Azure App Services Custom Auth (Part 2: server authentication)
• Azure App Services Custom Auth (Part 3: client authentication)
• Azure App Services Custom Auth (Part 4: cross-provider users) — soon

Xamarin Forms is an amazing framework despite a lot of bugs.

It gets better each time it is updated and I am pretty confident it will be mature enough to build any app in a close future, providing you have the time and experience to do so.

But as all framework under development it has its flaws.
Sometimes it is big flaws. Usually, people notice big flaws and developpers fix them for the best. Ironically it is not those flaws that bugs me.

Because sometimes it is these minor things that annoy the end-user developper but that go unnoticed just because it is not a problem enough to need a quick fix.

Device.OnPlatform

And a good example in my opinion is these methods to define platform-specific code:

OnPlatform<T>(T iOS, T Android, T WinPhone)
OnPlatform(Action iOS = null, Action Android = null, Action WinPhone = null, Action Default = null)

It seems cool right ? It is. It allows us to define values and snippets of code for each platform like this :

FontSize = Device.OnPlatform<double>(10, 10, 30);

It is an incredible tool. But one thing bothers me.

Here I have defined a size of 10 for both Android and iOS. It is okay because I do not mind writing twice « 10 ». But when it comes to more complex objects with parameters and all I hate to define it twice / outside. I find it awful for maintainability.

So I end up using something like that (once again I took a very simple example but I only do this for complex situations) :

Device.OnPlatform(
	WinPhone: () => FontSize = 30, 
    Default: () => FontSize = 10);

Which is terribly unsatisfying as I have to use the Action-based method, the only one that support this Default mechanism.

Implementation of generic Default mechanism

Why not define a Default mechanism for the typed-version ? Probably because it is a bit trickier as a generic method cannot use null as default value (because not every object can take the null value, ex: bool).
But I need it so let's figure this out.

There are two workarounds : use default(T) or restrict T to classes (where T : class).
I chose to use default(T) because I want to extend this to any type.

So here is my final implementation of Device.OnPlatform<T>(Default) :)

public static T OnPlatform<T>(T iOS = default(T), 
								T Android = default(T), 
                                T WinPhone = default(T), 
                                T Default = default(T))
{
    return Device.OnPlatform<T>(
    	object.Equals(iOS, default(T)) ? Default : iOS, 
        object.Equals(Android, default(T)) ? Default : Android, 
        object.Equals(WinPhone, default(T)) ? Default : WinPhone);
}

And the usage :

FontSize = DeviceExtensions.OnPlatform<double>(WinPhone: 30, Default: 10);

Which solves my initial problem. And I hope yours too.
Enjoy :)

Paul, out.

I've always wondered what it would like to blog. To be honest, I've always wanted to share thoughts and ideas on the internet.

But I've never had the courage to do it. I always wondered, on which subject could I write? Could I say something interesting enough? Should I write in french or in english?

Then I met Lionel Clément. He is the creator of « l'ivre de lire » (http://www.livredelire.com), and more recently « InWonderland » (http://inwonderland.fr/), a more personal blog.

The guideline on both blogs: he is talking about his passions. And I realized that was the real deal: share thoughts about passions.

About me

I was born in 1988 in Normandy (you'll guess I'm french then). I've started coding at the age of 14. I have studied mathematics and informatics in an engineering school (Ensimag) after studying maths / physics / chemistry.

I am a developper, I have been working on critical industrial systems for a few years. I've lead a mobile tech group in my previous company and I've also teached algorithmic at Ensimag.

With Nicolas Saubin (http://www.nicolas-saubin.com), I am the co-founder and CTO of Collibris: http://www.collibris-app.com, a french mobile and web app about sharing and discovering books. This is the biggest project of my life and it's highly probable most posts of this blog will be somehow related to Collibris.

I have a LOT of passions. Some only last for a time, but I'm always willing to try something new. Among those:

• Music (bass / guitar / singing — I'm the bassist of a group)
• Œnology (wine tasting — I've met Nicolas thanks to this)
• Beerology (beer tasting)
• Magic (cardistry)
• Lockpicking
• Martial arts
• etc.

But my main passion is informatics. I just love being a developper, building apps and software, and everything related to it (agile, testing, user experience, etc.).

About this blog

As I've said, I'm a techie. On this blog, I'll be posting my share of code. I will also talk about anything revolving around code and technical skills.

This is just the beginning, so I'm not quite sure exactly how it will look like. I really hope I'll be able to connect with people, providing quality content, as I've seen on many blogs.

With this blog, I'll try to express my opinions about coding. This world has evolved a lot (quicker than any other in my opinion) and is still evolving at an incredible speed. It's easy to get lost in only a few years.

I also hope that I'll be able to help other people out with my posts. Coding always has been about sharing, and many have helped me with their blogs, I feel this is the opportunity fore me to put another brick in the wall.

See you soon !
Paul, out.