Virtual Private Database and how to integrate it with a Java application

Virtual Private Database (VPD) allows you to implement row and column level security in your database by "hiding" data in tables, so that only a subset of all table data is accessible. The cool things is that the "hiding" can be done based on your application user's identity or roles, so that privileged users can access more data than normal users - and it is all managed at database level!


How to draw a tree using window functions and recursive query in PostgreSQL

In this post I would like to show you how to draw a nice looking tree (similar to output of unix tree command) using select statement in PostgreSQL.

Suppose we have a view v_deps, which contains information about dependencies between views, materialized views and tables (the definition of this view is at the end of the post). Every row in this view means that dependent object dep_obj depends on referenced object ref_obj:


PostgreSQL: How to handle table and view dependencies

PostgreSQL is very restrictive when it comes to modyfing existing objects. Very often when you try to ALTER TABLE or REPLACE VIEW it tells you that you cannot do it, because there's another object (typically a view or materialized view), which depends on the one you want to modify. It seems that the only solution is to DROP dependent objects, make desired changes to the target object and then recreate dropped objects.


DB view dependencies in PostgreSQL


I recently learned a clever trick in PostgreSQL, which allows you to check which DB views and tables are used by any view. It allows you to see view's dependency tree, for example:
public.v_top_department depends on public.v_department_sales_per_employee
  public.v_department_sales_per_employee depends on public.v_department_sales
    public.v_department_sales depends on public.departments
    public.v_department_sales depends on public.sales
  public.v_department_sales_per_employee depends on public.v_department_employees
    public.v_department_employees depends on public.departments
    public.v_department_employees depends on public.employees


Spring Security: authorization on controller methods, part 2

In my previous post I showed a method to apply authorization rules to controller methods using annotations without moving <global-method-security> or @EnableGlobalMethodSecurity to web application context. My solution was something between web security and global method security. It operated on HTTP request level (just like web security), but it was configured by annotations (like global method security).

I improved my code from previous post, so it integrates with Spring Security better, and I packaged it as a library (spring-security-controller-auth). In this post I would like to describe this library.


Spring Security: authorization on controller methods

Spring Security offers three methods of authorization:
  • securing URLs using <intercept-url> or authorizeRequests() in XML/Java config (also called web security or URL security)
  • securing individual method invocations using <global-method-security> or @EnableGlobalMethodSecurity
  • securing domain objects using ACL
The first method is well-suited for securing servlets and controllers.
The second works (with a default configuration) for service layer components, but not for controllers. This is because you usually add Spring Security in root application context and, since controllers live in web application context, Spring Security cannot access them. Still, very often developers try to apply global method security to controller methods. Spring Security FAQ has even an answer to such question. Usually the solution is to move <global-method-security> to web application context.

I think that many of those developers actually don't need global method security on controller methods. For example see these four threads: [1], [2], [3] and [4] - they all require a simple "hasRole(XXX)" check. So I think that what they really need is to configure some authorization mechanism using annotations directly on controller methods (because it is more convenient than configuring it using URL patterns). It doesn't matter, if it's web security or global method security. However, they choose global method security, because it supports annotations.

In this post I would like to show an alternative approach - something that is between web security and global method security. It will use web security expressions, but will be configured by annotations applied to controller methods. Let's see how this can be implemented.


How to create custom form property types in Activiti

Activiti BPM engine provides support for creating forms for user tasks. Out-of-the box the following form property types are supported: string, long, enum, date, boolean. In this post I would like to show you, how you can add custom form property type.