DarksideCookie

For some reason I got the urge to have a look at webhooks when using GitHub. Since it is a feature that is used extensively by build servers and other applications to do things when code is pushed to GitHub etc, I thought it might be cool to have a look at how it works under the hood. And maybe build some interesting integration in the future…

The basic idea behind it is that you tell GitHub that you want to get notified when things happen in your GitHub repo, and GitHub makes sure to do so. It does so using a regular HTTP call to an endpoint of your choice.

More...

As some of you might have noticed, I really like OWIN. I like the simplicity, and the extremely powerful things that you can do with it in a simple way. And the fact that I don’t have to create an IHttpModule implementation, and figure out the ASP.NET event to hook into, like I had to to do the same thing before OWIN.

Katana, Microsoft’s implementation of OWIN, also offers a standardized way to handle authentication. And it is really easy to use, and not too hard to extend to work with your own identity providers. However, being me, I want to know how it works “under the hood”, and not just read a “how to build an authentication middlware” blog post…

Remember, knowing how things work “under the hood”, or “under the bonnet” if you speak the Queens English, makes it possible to do more things than just use it. By knowing how a combustion engine works (under the hood/bonnet of your car), makes it possible to add a turbo or two to it, or a compressor, or at maybe tweak the fuel consumption and horse power you get from it. But let’s leave the car analogies and look at Katana authentication middleware.

More...

Most of you can ignore this post completely! But if you attended SweNug today (September 10th), you know that I promised to publish my code. So here it is!

Code: SweNug.Owin.zip (2.30 mb)

I’m sorry for the ridiculous size of the download, but all the solutions have NuGet package restore enabled, which places an exe to restore NuGet packages in the project. This exe is quite sizable, so the download gets a bit large. On the other hand, including all the NuGet packages would make it even larger…

If you have any questions, don’t hesitate to drop me a line!

In my previous post, I showed how to do a simple configuration of WS-Federation using WIF, or whatever it is called now that it is part of the framework, to enable federated authentication in ASP.NET. Something that was previously done using a tool, but now either has to be done at the start of the application, or manually.

But what about OWIN? As all new security stuff is moving to OWIN, how do we get it to work there? Well, by default, it is ridiculously simple. And that has been the whole goal with this new model.

More...

In my last couple of posts, I have talked about OWIN. What it is, how it works, why it is interesting and so on. I have talked mostly about the hosting side of it, and a bit about how we can plug into the OWIN pipeline using what is called middleware… However, so far, the middleware has been ridiculously simple, and done very little, which isn’t really helpful I guess. And besides not doing very much interesting work, they have also not interacted very much with the request pipeline. Most of them, or maybe even all of them, have just terminated the pipeline and returned a simple response…

In this post, I want to take a look at how OWIN abstracts the server, and the request and response, and also how we can use this abstraction to extend the functionality of our pipeline.

More...

My last post about OWIN covered a little bit about the different hosting options, and then quite a bit about OWIN middleware. However, I found the hosting coverage to be a little weak, so I thought I would do one more, much shorter post, on just the different hosts available.

As mentioned before, there are 4 different OWIN hosts available from Microsoft. 3 from project Katana and one from project Helios.

Actually, there are 5. There is also a test host that can be used to test OWIN middleware in Unit tests etc in-memory, instead of having to open a port and listen for incoming requests…

The first, and simplest to get started with is the Katana self-host. But since we saw that being used in the last post, I will skip that one…

More...

In my previous post about OWIN, I talked a bit about what OWIN is, and why it is important. This time, I want to take a little more of a dive into how we can use it, and how we code things using it.

var http = require('http');
var server = http.createServer(function(req,res) {
    res.end('Hello World');
});
server.listen(8080);
console.log('Server running...listening on port 8080');

The above code snippet has nothing at all to do with OWIN. It is actually Node.js code for creating a web server and responding to HTTP requests. However, the above code is the main reason I like Node. The simplicity and tiny amount of code needed to get going is awesome!

It doesn’t do much, but it gives as a very crude, but powerful starting point in just a couple of lines of code. It is then up to us to take it from there and do what we want. Something we often do by turning to our package manager and asking for some cool functionality that someone else has already built.

More...

Ok, so straying a bit away from the AngularJS posts I have been doing lately, I want to talk a bit about OWIN. Why? Well, I recently took a look at it, after putting it off WAY too long, and found it to be awesome! And the goal with this post is to explain what it is, why it is cool, and why Microsoft is putting it into ASP.NET MVC projects by default…

But let’s start with “what is OWIN”… Well, OWIN stands for “Open Web Interface for .NET” and you can find more about OWIN as such at http://owin.org/. And now that you are back from that site, you are probably not a whole lot more in tune with what OWIN is, and the reason for that is probably that the site contains very little information. And it contains that little information because OWIN _is_ really that small. It is just a definition of an interface used to decouple the web applications we build, from the servers that are hosting it…

More...