Got some great feedback on my first screencast, which is awesome! I mentioned that I usually use typescript in my previous post and one viewer picked up on that and requested a screencast converting the app to use typescript. Excellent idea, so here it is! Once again I underestimated the time it would take though, my est. was ~20 minutes, it ended up taking 35 minutes. Speaking, thinking, motivating decisions and writning code just takes a bit longer than what I'm used to. ;-)
Live demo @ http://meetometer.azurewebsites.net/
Source code @ https://github.com/ajtowf/meetometer/
I'm thinking server side coding for the next sitting. Until then, have a nice day!
Keywords : VS2013, Azure, HTML5, JavaScript, AngularJS, jQuery Mobile, AmplifyJS
Got some alone time and decided to spend an hour on coding. I recorded my coding session, making this my first official screencast! The idea is to share my thoughts when I write code and perhaps get some constructive criticism / feedback. The task was to create an app to keep track of how much meetings cost for companies. I started from scratch and managed to get a prototype up and running in windows azure in ~50 minutes or so.
Live demo @ http://meetometer.azurewebsites.net/
Source code @ https://github.com/ajtowf/meetometer/
The video is unedited and shot in one take. I hadn't approached the task more than giving it a thought the night before. With the result in hand I'm pretty satisfied with how it went. Sure I got some errors due to typos but that's part of the day to day work for a developer. I also encounterd some bugs due to framework incompatibilies which I managed to tackle as well.
If I do a second sitting the roadmap is to implement a server side solution. Perhaps make it a multi-tenant site and store all meetings to get an overall cost per month for instance. Sounds like a plan? ;-)
Happy holidays!
Keywords : VS2013, Azure, HTML5, JavaScript, AngularJS, jQuery Mobile, AmplifyJS
Shouldn't be any problem right? Facebook apps allows you to specify localhost for the callback/redirect url. Sweet! But microsoft doesn't! So this is what I did.
I created a new application https://account.live.com/developers/applications/create and specified kingen.se as redirect domain.
I added a DNS record to C:\windows\system32\drivers\etc\hosts that routes 127.0.0.1 to kingen.se.
I changed the site binding in %Documents%\IISExpress\config\applicationHost.config :
<site name="<site name>" id="24">
<application path="/" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory path="/" physicalPath="<your-path>" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:80:kingen.se" />
</bindings>
</site>
I changed the "Default Web Site" binding to port 8080 (or whatever) for IIS.
I turned off SQL Reporting Services because the agent used port 80. Use netsh to list port usage if you run into other problems.
netsh http show urlacl | Select-String :80
Finally in my asp.net mvc project I changed the properties for the project to
- Use Local IIS Web server
- Check Use IIS Express, Project Url: http://localhost
- Check override application root URL: http://kingen.se
- Set Start URL to: http://kingen.se/
Voilá, press F5 and IIS Express will fire up on http://kingen.se with a working Microsoft OAuth Identity provider.
Cheers!
I really think these two frameworks don't mesh together too well and this blog post is me trying to explain why.
If you're used to traditional MVC with full page refreshes, views, server side partials etc. and you've decided that you want to use a bit of angular inside your pages you are going to be very frustrated. Angular is really best for single page applications (SPA seems to be a buzz word for the moment). If you just want some javascript goodness just use knockoutjs.
I'd suggest using WebApi instead. This is what I've found out works best.
- The server side actions on the ApiController should only return JSON data to the client and be consumed by ajax calls from angular.
- Stop thinking in terms of razor and writing C# code in your views and working with the @model passed from the controller.
- Only have one razor page for your app (Index.cshtml), no views, no partials. Load everything on the index page.
- Do not use the MVC routing, let angular perform the dynamic page updates.
You might ask yourself; why use razor at all? Well the Web.Optimization bundle is quite neat and I've grown quite attached to it :-)
For SPAs sure go ahead and use angular it's awesome. But stick with angular/javascript for front-end and use WebApi for back-end if you've decided that you want to try out angular on top of asp.net.
Also imo SPAs should be fairly small, if you know your project will be fairly big SPA really isn't the way to go. It could be me just having a hard time to adapt since I'm used to hooking everything up in a spaghetti of document.ready-functions :-P I've always been a "back-end / do it on the server / use as much static typing as possible" kind of guy but perhaps that's changing, especially with tools like
TypeScript which is a must in all my web projects nowadays.
I might add that I also have experience using angular together with jQuery mobile when developing a scorecard app for golf (
golf-caddie.se) which wasn't too pleasant but that's another blog post (two frameworks manipulating the DOM don't play nice together).
Just my thoughts, it's not written in stone :D
Lab days once again at work, this time I focused on security. Can't share the code this time since it contains some company confidential stuff but the diagram below basically summarizes my architecture idea.

Securing WCF service with WIF
There are plenty of blogs out there descibing how to do this so I'm not going to explain this i depth, if you however only have experience with using WIF 3.5 as me I found an excellent migration guidelines page on msdn (http://msdn.microsoft.com/en-us/library/jj157089.aspx). We use a custom binding for tcp transport support with reliable sessions which makes you wanna kill yourself when you see the binding configuration. Due to this I can't share the code since it is considrered "intellectual property" of Saab (me?).
Important WIF 3.5 to 4.5 change!
You could previously access the calling users claims in the WCF service by casting ServiceSecurityContext.Current.PrimaryIdentity to ClaimsIdentity. This is no longer true, you'll get the claims by casting Thread.CurrentPrincipal to ClaimsPrincipal or Thread.CurrentPrincipal.Identity directly to ClaimsIdentity. For this to work you'll also need to set <serviceAuthorization principalPermissionMode="Always" /> on the service behavior declaration. See also Dominick Baiers post for more details.
JWT, Identity Server v2 and WebApi
I've updated our development STS in our product at work from startersts to identityserver v2, which I thought was a great platform to continue exploring, especially since it supported to issue JWT (json web tokens). At least I thought it did until I discovered that it doesn't! They do however have a branch that supports it and uses Microsoft JWT (https://github.com/thinktecture/Thinktecture.IdentityServer.v2/tree/Microsoft-JWT).
I found a nice message handler that validates JWTs which uses JSON Web Token Handler For the Microsoft .Net Framework 4.5 written by the security guru Vittorio Bertocci (http://code.msdn.microsoft.com/AAL-Native-Application-to-fd648dcf/sourcecode?fileId=62849&pathId=697488104). And as always I encountered major problems when trying to validate the JWT issued by identity server on the server-side (webapi). Victor uses windows azure ad together with Windows Azure Authentication Library which of course validates the token correctly.
I think there is a may release coming up for identity server, perhaps I'll give it another shot then, but for now I had to use Azure AD.
The outcome wasn't actually what I expected when I began but the road there was educative, I suggest following Victor on http://www.cloudidentity.com/blog to keep up with the updates on the json web token handler which currently only is in the developer preview stage. It hurts to keep up and always use bleeding edge technology but hey, they don't call it lab days for nothing. ;-)
Peace!