Today I tried to get DotNetOpenAuth 3.4.7 working on Mono without any success. My hope was that now that I had already got ASP.NET MVC with Razor working on Mono this should be a piece of cake. I was wrong.
Short conclusion: Try to avoid DotNetOpenAuth at all cost!
The DotNetOpenAuth project has a mono2 branch on Github, which you can find here:
https://github.com/AArnott/dotnetopenid/tree/mono2
I managed to get it to build and run on Microsoft .NET, but not on Mono. If you are running ASP.NET MVC you also need the following (because of the helpers in DotNetOpenAuth that are targeted towards MVC 1). I really hate configurations like this one... why did they include this helper in exchange for a configuration change? It is really not very helpful code.
You need to build this on Windows and this is not as easy as it sounds. I started running into a bunch of problems with strong name signing, which I managed to resolve by disabling verification with the instructions given here:
http://www.dotnetopenauth.net/developers/contributing/quickstart-environment/
But after struggling with trying to get a build with my own key running for a some hours I finally gave up. It is not worth it - I may get it to run once and then later some provider will change their implementation and I will have to recompile and would run into this nightmare again. I also tried getting the official binaries (for Windows) running on Mono but wasn't able to do so.
Here are my final conclusions:
- DotNetOpenAuth tries to do many things at one time, instead of just getting one thing right (preferably without too much configuration!).
- Outside my "core business domain" I do not want to depend on a library that do not officially support my platform (Mono).
- I do not wish to maintain code for a OpenID library myself.
- I do not want to depend on a project with so weird configuration settings and poor "setting it up" documentation as I saw on DotNetOpenAuth. I noticed that the library was used by some big names like StackOverflow and MySpace, but I am not convinced that this is production quality code.
- OpenID and OAuth seems to be very complicated to "get right". Especially since different providers seem to have very different implementations.
- I would rather support a small number of project that having to test and support all OpenID providers available.
I will consider the following alternatives:
- Not using OpenID at all and instead sticking with my custom Forms authentication.
- Running just the login on a cheap shared Windows host. Even though I do not like to run authentication on other peoples server.
- Trying out http://www.janrain.com/products/engage
- Choosing a library for another language (for example Python) or simply settle with a single login provider such as Facebook Connect or Google's. Implementing just a login page in another language should be fairly simple and could be deployed on its own domain/webserver. For example "http://login.mydomain.com" sets a cookie for ".mydomain.com" and redirects to "http://www.mydomain.com/autologin.aspx" which sets the authentication cookie for ASP.NETs form authentication.
- Putting a Python application on GAE and letting it perform the authentication. Access to GAE would then go through a reverse-proxy to allow it to set cookies on my domain. GAE could put a signature on the logged in user + date using a private key, and store it in a cookie for ".mydomain.com". My ASP.NET server could then easily verify it.
Short conclusion: Try to avoid DotNetOpenAuth at all cost!
The DotNetOpenAuth project has a mono2 branch on Github, which you can find here:
https://github.com/AArnott/dotnetopenid/tree/mono2
I managed to get it to build and run on Microsoft .NET, but not on Mono. If you are running ASP.NET MVC you also need the following (because of the helpers in DotNetOpenAuth that are targeted towards MVC 1). I really hate configurations like this one... why did they include this helper in exchange for a configuration change? It is really not very helpful code.
<!-- When targeting ASP.NET MVC 2, this assemblyBinding makes MVC 1 references relink to MVC 2 so libraries such as DotNetOpenAuth that compile against MVC 1 will work with it. --> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0" newVersion="3.0.0.0" /> </dependentAssembly> </assemblyBinding>
You need to build this on Windows and this is not as easy as it sounds. I started running into a bunch of problems with strong name signing, which I managed to resolve by disabling verification with the instructions given here:
http://www.dotnetopenauth.net/developers/contributing/quickstart-environment/
But after struggling with trying to get a build with my own key running for a some hours I finally gave up. It is not worth it - I may get it to run once and then later some provider will change their implementation and I will have to recompile and would run into this nightmare again. I also tried getting the official binaries (for Windows) running on Mono but wasn't able to do so.
Here are my final conclusions:
- DotNetOpenAuth tries to do many things at one time, instead of just getting one thing right (preferably without too much configuration!).
- Outside my "core business domain" I do not want to depend on a library that do not officially support my platform (Mono).
- I do not wish to maintain code for a OpenID library myself.
- I do not want to depend on a project with so weird configuration settings and poor "setting it up" documentation as I saw on DotNetOpenAuth. I noticed that the library was used by some big names like StackOverflow and MySpace, but I am not convinced that this is production quality code.
- OpenID and OAuth seems to be very complicated to "get right". Especially since different providers seem to have very different implementations.
- I would rather support a small number of project that having to test and support all OpenID providers available.
I will consider the following alternatives:
- Not using OpenID at all and instead sticking with my custom Forms authentication.
- Running just the login on a cheap shared Windows host. Even though I do not like to run authentication on other peoples server.
- Trying out http://www.janrain.com/products/engage
- Choosing a library for another language (for example Python) or simply settle with a single login provider such as Facebook Connect or Google's. Implementing just a login page in another language should be fairly simple and could be deployed on its own domain/webserver. For example "http://login.mydomain.com" sets a cookie for ".mydomain.com" and redirects to "http://www.mydomain.com/autologin.aspx" which sets the authentication cookie for ASP.NETs form authentication.
- Putting a Python application on GAE and letting it perform the authentication. Access to GAE would then go through a reverse-proxy to allow it to set cookies on my domain. GAE could put a signature on the logged in user + date using a private key, and store it in a cookie for ".mydomain.com". My ASP.NET server could then easily verify it.
Comments
Post a Comment