Derby: Authentication part #1

31st of July, 2012 05:14 PM

Long time no post! A lot has happened since my last blog post about Derby - a completely new query system is in place and not long after, support for access control and thus authentication! Because currently Derby/Racer is too buggy but a lot of people have requested and longed for an authentication example, I decided to release a sneak peak of what is to come when it comes to authentication!

Current status of authentication in Derby

Authentication depends on three different parts of Derby: The new session system/middleware, access control and partly, the new query system. The new query system is up and running and seems to be working pretty okay. "Minor" bugs are there but are also expected, so nothing new under the moon there. Access control seems to work similarly well as the query system - some "minor" bugs but nothing not expected. Sessions however, is working quite sketchy at the moment. Access control was introduced in 0.3.12, but since access control is more or less pointless without sessions, sessions were also sneaked in. However, it worked pretty badly. I only managed to get it to work for regular HTTP calls (i.e. not with websockets). A lot of the fixes Nate and Brian have made since the release of 0.3.12 have been related to fixing sessions and I am glad to say it is now working with websockets as well.

So what is the problem? Minor bugs and sessions are working? With sessions, some work is still left with making the session object available to templates. It is currently available as a variable named 'session' (i.e. use it in a fashion like this: '{session}'). The problem is that it is impossible right now to access any properties of the session object - it seems that because the session object is stored as a normal JSON object straight into the special case {session}, any traveling down the hierarchy of the session object does not work like it does with any Racer-based variable. In other words, it is currently not possible to access or do anything like this: {session.userid}, even if {session} looks like this: { ..., userid: 123, ... }. 

There is at least one workaround. You can put the session object in a hidden element on your page and place it as a private path on your model object and then access the model object on that private path. This works as expected, however, when I have been working on my example app, I stumbled upon a bunch of other bugs with Derby, that made me decide I would rather wait for 0.3.13 than try to circumvent all of the bugs (which also lead me to do a very hacky implementation, which is not good as an example app anyway).

My example app

So, basically all parts of authentication works enough to start testing and playing around with it, despite Derby currently being in such a shape that it does not allow for a good implementation of it. I know there are many that have been waiting on authentication and cannot wait another minute until they would like to start playing around with it. So, in order to help you guys get started, I put up my initial work on an example app on GitHub. It is based upon the derby-example GitHub repository, specifically the directory example app. I put in on my GitHub account (cjblomqvist) under the branch authentication and you can find it here.

Note! It requires the very latest version of Derby and Racer in order to work properly, it is currently very few comments and there is currently very little functionality available. Basically you can login with root/root which will correctly log you in and give you access to the rest. If you try to go to :30004/people straight away (before logging in) you will end up with an error. If you do it after logging in, it will work. This currently works both with normal HTTP-requests (has worked since the release of 0.3.12) and with websockets (with the very latest version of Derby/Racer from GitHub). Be aware though that there are a bunch of issues with the rest of the app as well as all of the templates.

To summarize

So, I will not go into more details as I believe it will be a waste of my time right now. When more bugs are fixed and I finish the example app, I will write a better post about how to use and what to think about when using authentication (although my example app will be very trivial).

The Weblog

Carl-Johan Blomqvist