<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18943"></HEAD>
<BODY>
<DIV><SPAN class=044552821-02092010><FONT color=#000080 size=2
face="Lucida Sans">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
RolapCubeDimension.</FONT></SPAN></DIV>
<DIV><SPAN class=044552821-02092010><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=044552821-02092010><FONT color=#000080 size=2
face="Lucida Sans">In other words, the dimension is never a shared dimension,
always a use of a dimension in a cube.</FONT></SPAN></DIV>
<DIV><SPAN class=044552821-02092010><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=044552821-02092010><FONT color=#000080 size=2
face="Lucida Sans">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.</FONT></SPAN></DIV>
<DIV><SPAN class=044552821-02092010><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=044552821-02092010><FONT color=#000080 size=2
face="Lucida Sans">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 RolapCubeMember.</FONT></SPAN></DIV>
<DIV><SPAN class=044552821-02092010><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=044552821-02092010><FONT color=#000080 size=2
face="Lucida Sans">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.</FONT></SPAN></DIV>
<DIV><SPAN class=044552821-02092010><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=044552821-02092010><FONT color=#000080 size=2
face="Lucida Sans">Julian</FONT></SPAN></DIV>
<DIV><SPAN class=044552821-02092010><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV><FONT color=#000080 size=2
face="Lucida Sans"></FONT><BR>
<BLOCKQUOTE
style="BORDER-LEFT: #000080 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> mondrian-bounces@pentaho.org
[mailto:mondrian-bounces@pentaho.org] <B>On Behalf Of </B>Luc
Boudreau<BR><B>Sent:</B> Thursday, September 02, 2010 6:35 AM<BR><B>To:</B>
Mondrian developer mailing list<BR><B>Subject:</B> [Mondrian] Extending Role
interface<BR></FONT><BR></DIV>
<DIV></DIV>Hello everyone,<BR><BR>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). <BR><BR>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. (see <A
href="http://forums.pentaho.com/showthread.php?70624-Mondrian-Measures-dimension-is-equals-any-other-Measures-dimension"
target=_blank>http://forums.pentaho.com/showthread.php?70624-Mondrian-Measures-dimension-is-equals-any-other-Measures-dimension</A>.
)<BR><BR>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...<BR><BR>
<DIV style="MARGIN-LEFT: 40px"><FONT face="courier new,monospace">Access
getAccess(Dimension dimension);</FONT><BR></DIV><FONT
face=arial,helvetica,sans-serif><BR>...would become...<BR><BR></FONT>
<DIV style="MARGIN-LEFT: 40px"><FONT face="courier new,monospace">Access
getAccess(Dimension dimension, Cube cube);</FONT><BR></DIV><FONT
face=arial,helvetica,sans-serif><BR></FONT><FONT
face=arial,helvetica,sans-serif>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. </FONT><FONT
face=arial,helvetica,sans-serif>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
this?<BR><BR>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.<BR><BR>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.<BR><BR>Cheers!<BR></BLOCKQUOTE></FONT><FONT
face=arial,helvetica,sans-serif></FONT></BODY></HTML>