Fact check: market thermal label systems are freaking expensive. Maybe I could build my own label WYSIWYG designer? Should be simple, right?

To spice things up, I decided to try building this as a web solution. Thus, I started playing with html5 canvas to draw text, barcodes, rectangles and images. Once the design was created I could save the configuration for the items drawn and create actual printer specific commands.

A quick research showed that someone had already done something similar to what I wanted: Teynon’s Label Designer. However, the UI could use some improvement and it needed some features like content rotation, more control over layout properties and a document outline. Then I thought “go big or go home!” and decided to also convert the solution to typescript. Let the fun begin!

Check out the code on github

Or maybe just a demo

The cool stuff (context = canvas.getContext(“2d”)):

  • In order to add interactivity to the canvas, make it redraw itself after each user interaction. Although that can cause the canvas to refresh hundreds of times during a drag operation, it doesn’t really cause a noticeable performance impact.
  • Use context.fillText() to draw text
  • Use context.fillRect() to draw a rectangle
  • Use context.drawImage() to draw an image
  • Use JsBarcode to draw a barcode image into a canvas and transfer it to the main canvas by using context.drawImage(canvasWithBarcode[0], x, y)
  • To draw something rotated, first rotate the context itself context.rotate((angle * Math.pi) / 180) then draw the component desired and finally context.restore()

The not so cool stuff:

  • Scenario: you want to print a 3” x 4” label in a thermal printer that is 200DPI. The desired label should have a single text block of 1” in height or 200 dots. Your canvas measure a proportional size in pixels. Say 300px x 400px. Therefore it is rather easy to guess the text block should measure 100px (300px / 3”). Sounds easy? Unfortunately you won’t be able to translate everything, for instance, text blocks will require the actual printer fonts otherwise the final output won’t be loyal to the design.
  • The conversion of the canvas components metadata to printer command can be troublesome. There are multiple printer languages and each printer model has slight differences.

To make this work correctly it is essential that you have access to the printer fonts. Also, there might be some customization for each printer model you want to support.

That’s all for now. Have fun!



In the previous post, I proposed a “better” way to handle authentication and authorization in web applications for Enterprise.

What I’m going to demonstrate in this post is something rather common in corporate intranets: How to integrate Windows Authentication for intranet web applications using MVC, Windows Identity Foundation 4.5 (WIF) and Claims based auth.

WIF 4.5

From MSDN:

Windows Identity Foundation 4.5 is a set of .NET Framework classes for implementing claims-based identity in your applications.

What the doco above doesn’t mention is that it is very painful to use WIF and there is little material out there on how to do it. I’m no specialist by any means, but I’ve used WIF to some extent and hope to shed some light with this post.

Windows Authentication

In enterprise environments it is rather common to have a ERP like SAP or Microsoft Dynamics and a collection (sometimes large collection) of smaller applications to achieve all the digital processing your business needs. Top this with a restrictive firewall and proxy, and Windows Authentication suddenly becomes very attractive.


If there is one security concept that is widely misused is the concept of roles. I’ve seen so many applications that were designed to ask “Is user jdoe in role Admin?”. The problem with this question is the fact that over time applications change, simple as that. When a role change, you will have to change the software to support it.

Roles are not a bad thing, on contraire my friend, they are a great way to organize and drive security using business terms and business roles. In fact I would go as far as to say they are essential to a good security setup. What should change is how LOB applications use them. Instead of asking “Is user jdoe in role Admin?”, we should ask “Does user jdoe have access to resource App.Page?”. As far as the application is concerned, there is no role Admin, it doesn’t matter which role grants or revokes the access all that matter is whether the user have access to the resource or not.


Disclaimer: below is an extract of MSDN

A claim is a piece of information used to identity something. It can be a name, e-mail, resource access or anything describing such thing. It is issued and signed by an issuer and you should only trust the claim as much as you trust the issuer itself. WIF represents claims with a Claim type, which has an Issuer property that allows you to find out who issued the claim.

Normally, a claim is issued by a Security Token Service (STS), in this example I will merge the STS functionality with the application in order to make my life easier (yes, I am lazy!).

Enabling Windows Authentication

Start with creating yourself a brand new ASP.Net 4.5.2 web application, ensure to use the MVC template and select Windows Authentication for Authentication.

New ASP.Net Web App Creating a new asp.net 4.5.2 project

If you already have a web application, change the following in the web.config:

Also, if you a running the website on IIS, don’t forget to enable Windows Authentication and disable all other authentication methods.

The Authentication Manager

After authentication a ClaimsPrincipal object is created with Claims from AD with user name and group membership information out of the box. Most likely these Claims won’t be enough for your application authorization. This is where we create ourselves an implementation in order to transform our claims (remove claims or add custom claims). Given we are already relying on the Windows Authentication, we can derive an implementation of ClaimsAuthenticationManager and do the Claim processing.

Prevent continuous re-authentication

In above code, there is nothing checking for a session token and preventing re-authentication. Also, we need something to set the MVC Context with the new user. In order to achieve this we will need a HttpHandler:

Wire everything together

So we have a custom authentication manager and a HttpModule, all we need to enable them is to change our web.config

Checking for permissions Server Side

The default ResourceAttribute uses Role to authorize an action, let’s improve upon that and create a custom ClaimAuthorizeAttribute. This will allow us to decorate a controller action and assert the user has a specific claim before proceeding.


Checking for permissions

In a razor view, the easiest way to give the user a visual indication of access is to hide the resources they don’t have access to or disable it:

What about “smart” users?, Couldn’t they post the data using another tool?

Nope. Even if the user circumvents the UI limitations, the server is also protected and will return a 403 error. Isn’t that a sweet perk?

Hope this was helpful. Thoughts?