[Mondrian] Extending Role interface

Julian Hyde jhyde at pentaho.com
Thu Sep 2 17:36:21 EDT 2010

Since Role is an SPI (not an API), the Mondrian server is the only client
that will call the Role.getAccess(Dimension) method. Therefore, we should be
able to ensure that any Dimension passed to that method is a
In other words, the dimension is never a shared dimension, always a use of a
dimension in a cube.
By the way, your proposed method would have problems in the case that a
single shared dimension (e.g. Time) is used twice in the same cube (e.g.
Order Time and Ship Time) with different access control profile.
Add an 'assert dimension instanceof RolapCubeDimension', run the test suite,
and see if anything breaks. By the way, getAccess(Hierarchy) should be
called with a RolapCubeHierarchy, getAccess(Level) shouuld be called with a
RolapCubeLevel, and getAccess(Member) should be called with a
You might need to use an IdentityHashMap (or some similar trick) to make
sure that RolapCubeDimensions based on the same shared dimension to not
compare equal.


From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org] On
Behalf Of Luc Boudreau
Sent: Thursday, September 02, 2010 6:35 AM
To: Mondrian developer mailing list
Subject: [Mondrian] Extending Role interface

Hello everyone,

I'm working on a case about Mondrian's Role implementation. The problem is
this. If you grant access to a SharedDimension in a CubeA, but not in CubeB,
the Role gets to access the Dimension even in CubeB because the Role
interface does not take into account the context into which the Dimension is
accessed. As a matter of fact, this impacts all children of a
SharedDimension (hierarchies, levels and members). 

A discussion a while back on this list had concluded that the root of the
problem was due to Dimension.equals() implementation taking into account
only the name of the object. After evaluating the proposed fix, I concluded
that the performance impact is too great and will lead to many more problems
than it actually solves. The proposed fix would make the cache sizes
explode, because it would create a new cache for each DimensionUsage.
Actually, it won't solve the problem at all, because the dimension Java
object is indeed equal and thus leads the code to make faulty assumptions.
s-equals-any-other-Measures-dimension. )

But good news! There is a proper way to fix this. I propose to extend the
Role interface so that it takes into account the cube context into which the
access rights are evaluated. For example, the method...

Access getAccess(Dimension dimension);

...would become...

Access getAccess(Dimension dimension, Cube cube);

My first thought was to create new signatures alongside the existing ones,
but that would lead to security holes in the code. I would very much like to
fix this once and for all. Now, because this is part of the public API, I
would like to have some feedback on this. Do Mondrian developers use the
Role interface directly? Is there any foreseeable bad consequences to doing

Also, I expect some serious code refactoring would occur. The context Cube
is not always readily available to all parts of the code which calls the
Role's access checkers. I will need to make sure that the context is
available for these checks. When Grants are created, we will need to specify
the context into which they are effective. etc.

There might be other solutions possible. I'd like to hear some ideas. IMO,
extending the Role interface is the "kosher" way of fixing this, because it
is at fault, but hey, I might be wrong.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20100902/e50e4d8d/attachment.html 

More information about the Mondrian mailing list