While still working on Path and Form component I decided to write a bit about user authorization and especially about permissions part. So what about it? Very often in smaller projects (that don’t use any framework mechanisms for this purpose) at database level I saw user’s permissions designed like this:


There is an user and a permission table connected in an user_permission relation. To check if user has given permission simple query is required:

It could be wrapped up in some handy function like this (I use Scala and ScalikeJDBC here):

So what’s wrong with it?. Firstly it can slow down other parts of the application. If your logic requires checking permission many times (in loop for example to do something with each order line) delay can be noticeable. Of course it can be cached in some kind of user permission dictionary but that leads to code complexity increasing. Secondly and that’s more important (at least from my point of view) is adding new permission. In the code one could have permission names defined like this:

and use it in a clean and readable way like that (of course it can be simplified more):

But when new permission will be required two steps are needed to take:

  1. Adding new permission in the database
  2. Adding new variable in the Permission object

And the biggest pain here is keeping permission variables in sync with values in the database. If you used serial id (auto generated id) in the permission table and regenerated its data then you cannot be sure about consistency anymore. And developer that wants to add new permission must have database access or he has to bother database administrator.

Is there better solution? I wouldn’t be writing all this if there weren’t 🙂 Instead of having permission and user_permission table let’s just add binary “permission” field in the user table. I usually make it 32 bytes long so it’s capable to store 256 permissions. Each byte keeps permissions – one per bit. In PostgreSql it’s defined as bytea type:

To set a proper bit in the permission array byte slot (n in setFlag function) must be calculated and then bit number of this slot determined (offset in example below). Byte slot is simply a permission value divided by 8 (or shifted right by 3 bits) and offset is 1 moved left by number of bits taken from the rest of permission dividing. To check if permission is set exactly the same operations are needed except the last one where and is used to check if bit is on or off.

packPermissions function converts array of permission numbers into array of permission bits that can be stored in the database. Below is an example of loading user and its permissions (and notifications which are handled in the same way). User class also has simplified version of hasPermission where only permission number is passed.

I hope the code above is clear to you and you’re able to figure everything out. The advantages of this approach are:

  1. Space needed to keep permissions both in the database and the code (only 32 bytes per user instead of 2048 (user_id + permission_id) * 4 bytes).
  2. Speed of loading (it’s a no cost actually).
  3. Speed of access – all permissions are loaded on user authentication, no caching required.
  4. Permissions are defined only on the code side. There is no need to synchronize with database values. If anyone wants to add new permission he simply adds a new variable in Permission object.
  5. Every coder can add new permission. There is no need to have access to the database.

And that’s it. I used this solution in my two last projects and it worked very well.

When I was creating my first application in spray framework I used spray’s directive to serve static content:

As you can see the main actor combines routes from apiRoute (handles all rest requests) and staticRoute (handles static content that is located in src/main/resources/web). Static route returns index.html if no path is provided in the url and any other resource from web directory otherwise). That works pretty well but has three disadvantages:

  • If any file from web directory will change hitting F5 in the browser will return previous content until spray server is restarted. That is very annoying during developing app’s frontend when one wants to see changes immediately.
  • Restarting spray server takes time. Sure it’s relatively not that long (on my machine around 3-4 sec) but still too slow for convenient development process.
  • Returning file content to the user requires JVM involving. Whatever they told you it’s not the best way to do it. And it’s better to save CPU cycles for more important tasks.

I decided to use nginx for that task (it’s small and fast with low memory footprint http server). Here’s my configuration (it’s based on one of the gists but unfortunately I don’t remember the author):

To run nginx I created following script start_nginx.sh:

Notice the -p parameter. Without it nginx looks for provided configuration file (in my example called nginx.conf) in its default configuration directory. What’s interesting on Windows this parameter is not required. I was really surprised with this platform inconsistency.

To stop nginx you must run following command (nginx process it’s not “killable” (at least on windows)):

If everything is ok nginx will start listening on localhost:9000 and from now on it will be responsible for serving files from the web directory. I forgot to mention that I moved web folder outside resources folder to avoid including it in the final jar file.

Spray application is listening on localhost:8080 and all requests coming from localhost:9000/api/* are forwarded there. In my case I use ssl on port 9000 so I had to add following line:

This line transforms https prefix into http one. Of course you can use ssl on spray side as well but it’s unnecessary protection doubling.

And that’s all. Hope that will help someone 🙂