PDA

View Full Version : [Mondrian] XMLA Security



Pedro Casals
03-16-2007, 07:40 AM
Hello:

I'm working on mondrian XMLA security and I have some doubts: The scenario is that you have a role that restricts the access to the two upper levels of an hierarchy (this hierarchy has four levels).

1st. I belive that the XMLA client should not be aware that this hierarchy has 4 levels. Do yo agree? This is the way JPivot is working.

2nd. Provided you agree with the previous point, what do you think would be the best strategy?: On one hand, upon cube defition load we could arrange the cube definition to match the role restriction. On the other hand, we could go on all XMLA request and filter it.
Doing it with the first strategy, it looks like its easier to manage. However, I see pooled cubes and I do not know if these pooled cubes are shared among several XMLA clients. Should this be the case, we should have to go through the second way.
Doing it the second strategy, we have to deal with all different XMLA requests, which should take more work, but looks safe, since no one could workaround security writing direct MDX.

3rd. Is there a way to restrict a measure to a role?

Pedro



______________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y m

Julian Hyde
03-16-2007, 08:11 PM
_____

From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org]
On Behalf Of Pedro Casals
Sent: Friday, March 16, 2007 4:34 AM
To: mondrian (AT) pentaho (DOT) org
Subject: [Mondrian] XMLA Security


Hello:

I'm working on mondrian XMLA security and I have some doubts: The
scenario is that you have a role that restricts the access to the two
upper levels of an hierarchy (this hierarchy has four levels).

1st. I belive that the XMLA client should not be aware that this
hierarchy has 4 levels. Do yo agree? This is the way JPivot is working.



Seems reasonable. How can a restricted client tell that there are 4
levels right now? I'm guessing (a) the Hierarchy.getLevels() method and
(b) the Level.getDepth() method. We could add versions of those methods
to SchemaReader, and make jpivot/xmla call them.


2nd. Provided you agree with the previous point, what do you think would
be the best strategy?: On one hand, upon cube defition load we could
arrange the cube definition to match the role restriction. On the other
hand, we could go on all XMLA request and filter it.
Doing it with the first strategy, it looks like its easier to manage.
However, I see pooled cubes and I do not know if these pooled cubes are
shared among several XMLA clients. Should this be the case, we should
have to go through the second way.
Doing it the second strategy, we have to deal with all different XMLA
requests, which should take more work, but looks safe, since no one
could workaround security writing direct MDX.


It's laudable to create an entire metadata API which includes
access-control. But it's a lot of work. We took the simpler route, which
is the SchemaReader interface.

So, the client (XMLA or JPivot) is an 'insider'. It is allowed full
access to the catalog, but for things it is displaying to the user, it
uses the SchemaReader facade.



3rd. Is there a way to restrict a measure to a role?


You can restrict access to any given set of members in a hierarchy. That
includes the Measures hierarchy.

Take a look at the AccessControlTest. That is the spec. Anything you
need but which isn't tested, please add and contribute. If anything
doesn't work, contribute the test and log a bug.

Julian

_______________________________________________
Mondrian mailing list
Mondrian (AT) pentaho (DOT) org
http://lists.pentaho.org/mailman/listinfo/mondrian

Pedro Casals
03-20-2007, 03:30 PM
I agree, it's easier to manage things through SchemaReader. However, there are some methods missing: I've seen schemaReader.getHierarchyLevels(hierarchy) (for Hierarchy.getLevels()) but not getLevelDepth, getDimensions, etc.

How would you feel if I added these methods to the SchemaReader interface? I kown changing interfaces is hard for all those that have implemented functionalities based on the interface, but extending the interface to a new interface like SecuritySchemaReader would make thing quite confusing, wouldn't it?

Tell me the way you prefer

Pedro


----- Mensaje original ----
De: Julian Hyde <julianhyde (AT) speakeasy (DOT) net>
Para: Mondrian developer mailing list <mondrian (AT) pentaho (DOT) org>
Enviado: s

Julian Hyde
03-21-2007, 05:51 AM
Pedro,

You should extend SchemaReader. It shouldn't be that painful for
existing code - implementations generally extend DelegatingSchemaReader
or RolapSchemaReader, so they wouldn't have to do any extra work.

Note that if you grant access to a member of a hierarchy, you implicitly
see all of its ancestors. E.g. if you give access to San Francsisco, you
see California and USA. Unless, that is, you set top-level to City or
lower.

When you've done the code changes, send me a zip file and I'll check
them in. As part of your code change, please document the rules you are
implementing in schema.html, and add tests in AccessControlTest.

Julian


_____

From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org]
On Behalf Of Pedro Casals
Sent: Tuesday, March 20, 2007 12:20 PM
To: Mondrian developer mailing list
Subject: Re: [Mondrian] XMLA Security


I agree, it's easier to manage things through SchemaReader. However,
there are some methods missing: I've seen
schemaReader.getHierarchyLevels(hierarchy) (for Hierarchy.getLevels())
but not getLevelDepth, getDimensions, etc.

How would you feel if I added these methods to the SchemaReader
interface? I kown changing interfaces is hard for all those that have
implemented functionalities based on the interface, but extending the
interface to a new interface like SecuritySchemaReader would make thing
quite confusing, wouldn't it?

Tell me the way you prefer

Pedro


----- Mensaje original ----
De: Julian Hyde <julianhyde (AT) speakeasy (DOT) net>
Para: Mondrian developer mailing list <mondrian (AT) pentaho (DOT) org>
Enviado: s

Pedro Casals
04-03-2007, 02:20 PM
Julian,

after a closer analysis, I did not have to extend SchemaReader, and most of the issues are solved. However I have one last problem that is difficult to solve. But, perhaps, the problem may be related to a wrong security definition.

This is the dimension:
<Dimension name="Estructura Comercial" foreignKey="LPCCLI" caption="Estructura Comercial">
<Hierarchy hasAll="true" allMemberName="Toda la Estructura" primaryKey="MCCCLI" allMemberCaption="Toda la estructura">
<Table name="Clientes" />
<Level name="Zona venta" column="MCDELV" captionColumn="NOMDEL" uniqueMembers="true" caption="Todas las zonas"/>
<Level name="Vendedor" column="MCVEN1" captionColumn="NOMVEN" uniqueMembers="true" caption="Todas los vendedores"/>
<Level name="Cliente" column="MCCCLI" captionColumn="MCNOMB" uniqueMembers="true" caption="Todas los clientes"/>
</Hierarchy>
</Dimension>

And this is the security role:
<Role name="V102">
<SchemaGrant access="none">
<CubeGrant cube="Ventas" access="all">
<HierarchyGrant hierarchy="[Estructura Comercial]" access="custom"
topLevel="[Estructura Comercial].[Zona venta]"
bottomLevel="[Estructura Comercial].[Cliente]">
<MemberGrant member="[Estructura Comercial].[Toda la Estructura].[01]" access="all"/>
</HierarchyGrant>
</CubeGrant>
</SchemaGrant>
</Role>

The problem with this security role is that when I try to retrieve all the children from [Estructura Comercial].[Toda la Estructura].[01] I get none, because the code navigates tries to solve the name one part at a time, but we do not have access to [Estructura Comercial].[Toda la Estructura].

Is it that the role definition is wrong or should I adjust the code (which is really complicated!!!!)

After this issue is solved, I will mail the code changes, incluiding a mondrian.xmla.impl.DefaultXmlaRequestCallback implementation (and its web.xml definition)

Pedro

----- Mensaje original ----
De: Julian Hyde <julianhyde (AT) speakeasy (DOT) net>
Para: Mondrian developer mailing list <mondrian (AT) pentaho (DOT) org>
Enviado: mi

Julian Hyde
04-03-2007, 02:20 PM
The problem with this security role is that when I try to retrieve all
the children from [Estructura Comercial].[Toda la Estructura].[01] I get
none, because the code navigates tries to solve the name one part at a
time, but we do not have access to [Estructura Comercial].[Toda la
Estructura].

Is it that the role definition is wrong or should I adjust the code
(which is really complicated!!!!)


The code which looks up the member being granted should definitely do so
in a non-access-controlled context. By all means adjust the code (and be
sure to add a unit test for the bug). Maybe use the global schema
reader?

Julian

_______________________________________________
Mondrian mailing list
Mondrian (AT) pentaho (DOT) org
http://lists.pentaho.org/mailman/listinfo/mondrian

Pedro Casals
04-04-2007, 07:10 AM
Thanks to your hint I realized that code changes were small. Since I have no access to CVS, I post here the changed classes. All changes are marked with this comment: //PCF : role
Besides, I attach a default callback implementation and the needed modification in web.xml.
I also attach the security role definition, that covers most of the situations:
- Grant only some measures
- Deny a hole dimension.
- Deny part of an hierarchy, both in levels and members

Pending:
JPivot is not placing the role in the HTTP header. I will ask to Andreas which is his preferred approach, and my proposed solution.

Known bug at this moment:
- Security role definition is order dependant, more than specified in doc. For example: in my role definition, if the definition of [Estructura Comercial] is placed before Dimension definition, the latter is not taken into account!
- look at XMLA Security bug.xls attached file. If a member of a level of an hierarchy is denied, the member is computed for the totals of the ancestors (wich is wrong), but is not computed on its own level (wich is correct).

Pedro

----- Mensaje original ----
De: Julian Hyde <julianhyde (AT) speakeasy (DOT) net>
Para: Mondrian developer mailing list <mondrian (AT) pentaho (DOT) org>
Enviado: martes, 3 de abril, 2007 18:53:55
Asunto: RE: [Mondrian] XMLA Security






The problem with this security role is that when I try to retrieve all the children from [Estructura Comercial].[Toda la Estructura].[01] I get none, because the code navigates tries to solve the name one part at a time, but we do not have access to [Estructura Comercial].[Toda la Estructura].

Is it that the role definition is wrong or should I adjust the code (which is really complicated!!!!)

The code which looks up the member being granted should definitely do so in a non-access-controlled context. By all means adjust the code (and be sure to add a unit test for the bug). Maybe use the global schema reader?

Julian
_______________________________________________
Mondrian mailing list
Mondrian (AT) pentaho (DOT) org
http://lists.pentaho.org/mailman/listinfo/mondrian



______________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y m

Julian Hyde
04-05-2007, 02:40 AM
Can you also contribute a unit test, against the foodmart schema? Code
without a unit test is like a really cool Xmas present with no batteries
included! See mondrian.test.AccessControlTest and
mondrian.test.SchemaTest for some examples.

I don't agree that members should be the total of only their visible
children. For example, if Fred has access to only [USA].[CA].[San
Francisco] and [USA].[CA].[Oakland], I think the total for [USA].[CA]
should include all cities in California.

I don't deny that there are cases where you would only want to see the
total of the accessible cities. But in my opinion it shouldn't be the
default behavior. I think there is some way to write a calculated member
for that - I would be open to extending the language to make that easier
to achieve. Anyone know what MSAS does here?

Julian


_____

From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org]
On Behalf Of Pedro Casals
Sent: Wednesday, April 04, 2007 4:04 AM
To: Mondrian developer mailing list
Subject: Re: [Mondrian] XMLA Security


Thanks to your hint I realized that code changes were small. Since I
have no access to CVS, I post here the changed classes. All changes are
marked with this comment: //PCF : role
Besides, I attach a default callback implementation and the needed
modification in web.xml.
I also attach the security role definition, that covers most of the
situations:
- Grant only some measures
- Deny a hole dimension.
- Deny part of an hierarchy, both in levels and members

Pending:
JPivot is not placing the role in the HTTP header. I will ask to Andreas
which is his preferred approach, and my proposed solution.

Known bug at this moment:
- Security role definition is order dependant, more than specified in
doc. For example: in my role definition, if the definition of
[Estructura Comercial] is placed before Dimension definition, the latter
is not taken into account!
- look at XMLA Security bug.xls attached file. If a member of a level of
an hierarchy is denied, the member is computed for the totals of the
ancestors (wich is wrong), but is not computed on its own level (wich is
correct).

Pedro

----- Mensaje original ----
De: Julian Hyde <julianhyde (AT) speakeasy (DOT) net>
Para: Mondrian developer mailing list <mondrian (AT) pentaho (DOT) org>
Enviado: martes, 3 de abril, 2007 18:53:55
Asunto: RE: [Mondrian] XMLA Security







The problem with this security role is that when I try to retrieve all
the children from [Estructura Comercial].[Toda la Estructura].[01] I get
none, because the code navigates tries to solve the name one part at a
time, but we do not have access to [Estructura Comercial].[Toda la
Estructura].

Is it that the role definition is wrong or should I adjust the code
(which is really complicated!!!!)


The code which looks up the member being granted should definitely do so
in a non-access-controlled context. By all means adjust the code (and be
sure to add a unit test for the bug). Maybe use the global schema
reader?

Julian
_______________________________________________
Mondrian mailing list
Mondrian (AT) pentaho (DOT) org
http://lists.pentaho.org/mailman/listinfo/mondrian


_____


LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y m

Matt Campbell
04-05-2007, 09:00 AM
In AS2K you can set whether to use visual totals in the Role definition. It
defaults to show the full aggregate total, but you can change that on a
dimension by dimension (and level by level) basis.

On 4/5/07, Julian Hyde <julianhyde (AT) speakeasy (DOT) net> wrote:[color=blue]
>
> Can you also contribute a unit test, against the foodmart schema? Code
> without a unit test is like a really cool Xmas present with no batteries
> included! See mondrian.test.AccessControlTest and mondrian.test.SchemaTestfor some examples.
>
> I don't agree that members should be the total of only their *visible *children.
> For example, if Fred has access to only [USA].[CA].[San Francisco] and
> [USA].[CA].[Oakland], I think the total for [USA].[CA] should include all
> cities in California.
>
> I don't deny that there are cases where you would only want to see the
> total of the accessible cities. But in my opinion it shouldn't be the
> default behavior. I think there is some way to write a calculated member for
> that - I would be open to extending the language to make that easier to
> achieve. Anyone know what MSAS does here?
>
> Julian
>
> ------------------------------
> *From:* mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org]
> *On Behalf Of *Pedro Casals
> *Sent:* Wednesday, April 04, 2007 4:04 AM
> *To:* Mondrian developer mailing list
> *Subject:* Re: [Mondrian] XMLA Security
>
> Thanks to your hint I realized that code changes were small. Since I have
> no access to CVS, I post here the changed classes. All changes are marked
> with this comment: //PCF : role
> Besides, I attach a default callback implementation and the needed
> modification in web.xml.
> I also attach the security role definition, that covers most of the
> situations:
> - Grant only some measures
> - Deny a hole dimension.
> - Deny part of an hierarchy, both in levels and members
>
> Pending:
> JPivot is not placing the role in the HTTP header. I will ask to Andreas
> which is his preferred approach, and my proposed solution.
>
> Known bug at this moment:
> - Security role definition is order dependant, more than specified in doc..
> For example: in my role definition, if the definition of [Estructura
> Comercial] is placed before Dimension definition, the latter is not taken
> into account!
> - look at XMLA Security bug.xls attached file. If a member of a level of
> an hierarchy is denied, the member is computed for the totals of the
> ancestors (wich is wrong), but is not computed on its own level (wich is
> correct).
>
> Pedro
>
> ----- Mensaje original ----
> De: Julian Hyde <julianhyde (AT) speakeasy (DOT) net>
> Para: Mondrian developer mailing list <mondrian (AT) pentaho (DOT) org>
> Enviado: martes, 3 de abril, 2007 18:53:55
> Asunto: RE: [Mondrian] XMLA Security
>
>
>
> **
> The problem with this security role is that when I try to retrieve all the
> children from [Estructura Comercial].[Toda la Estructura].[01] I get none,
> because the code navigates tries to solve the name one part at a time, but
> we do not have access to [Estructura Comercial].[Toda la Estructura].
>
> Is it that the role definition is wrong or should I adjust the code (which
> is really complicated!!!!)
>
>
> The code which looks up the member being granted should definitely do so
> in a non-access-controlled context. By all means adjust the code (and be
> sure to add a unit test for the bug). Maybe use the global schema reader?
>
> Julian
> _______________________________________________
> Mondrian mailing list
> Mondrian (AT) pentaho (DOT) org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>
> ------------------------------
>
> LLama Gratis a cualquier PC del Mundo.
> Llamadas a fijos y m

Richard Emberson
04-05-2007, 09:30 AM
I came upon a OLAP Security survey article (attached),
"Towards OLAP Security Design - Survey and Research Issues"
by Torsten Priebe and Bunther Pernul.
There is no standard. Some systems provide leaf level
data security only (showing full aggregates at non-leaf
levels which is of course a security hole) while others
carry the desired security from leaf level all the
way up to the 'All' level.
If your customers do not care about security, then you've
got lots of options. If they really want data/cell-level
security, choices are more limited.
We've got big customers with sophisticated and
modern OLAP security requirements. The notion that everyone
gets to see everything will not be acceptable.

Richard



Matt Campbell wrote:[color=blue]
> In AS2K you can set whether to use visual totals in the Role
> definition. It defaults to show the full aggregate total, but you can
> change that on a dimension by dimension (and level by level) basis.
>
> On 4/5/07, *Julian Hyde* <julianhyde (AT) speakeasy (DOT) net
> <mailto:julianhyde (AT) speakeasy (DOT) net>> wrote:
>
> Can you also contribute a unit test, against the foodmart schema?
> Code without a unit test is like a really cool Xmas present with no
> batteries included! See mondrian.test.AccessControlTest and
> mondrian.test.SchemaTest for some examples.
>
> I don't agree that members should be the total of only their
> /visible /children. For example, if Fred has access to only
> [USA].[CA].[San Francisco] and [USA].[CA].[Oakland], I think the
> total for [USA].[CA] should include all cities in California.
>
> I don't deny that there are cases where you would only want to see
> the total of the accessible cities. But in my opinion it shouldn't
> be the default behavior. I think there is some way to write a
> calculated member for that - I would be open to extending the
> language to make that easier to achieve. Anyone know what MSAS does
> here?
>
> Julian
>
> ------------------------------------------------------------------------
> *From:* mondrian-bounces (AT) pentaho (DOT) org
> <mailto:mondrian-bounces (AT) pentaho (DOT) org>
> [mailto:mondrian-bounces (AT) pentaho (DOT) org
> <mailto:mondrian-bounces (AT) pentaho (DOT) org>] *On Behalf Of *Pedro Casals
> *Sent:* Wednesday, April 04, 2007 4:04 AM
> *To:* Mondrian developer mailing list
> *Subject:* Re: [Mondrian] XMLA Security
>
> Thanks to your hint I realized that code changes were small.
> Since I have no access to CVS, I post here the changed classes.
> All changes are marked with this comment: //PCF : role
> Besides, I attach a default callback implementation and the
> needed modification in web.xml.
> I also attach the security role definition, that covers most of
> the situations:
> - Grant only some measures
> - Deny a hole dimension.
> - Deny part of an hierarchy, both in levels and members
>
> Pending:
> JPivot is not placing the role in the HTTP header. I will ask to
> Andreas which is his preferred approach, and my proposed solution.
>
> Known bug at this moment:
> - Security role definition is order dependant, more than
> specified in doc. For example: in my role definition, if the
> definition of [Estructura Comercial] is placed before Dimension
> definition, the latter is not taken into account!
> - look at XMLA Security bug.xls attached file. If a member of a
> level of an hierarchy is denied, the member is computed for the
> totals of the ancestors (wich is wrong), but is not computed on
> its own level (wich is correct).
>
> Pedro
>
> ----- Mensaje original ----
> De: Julian Hyde <julianhyde (AT) speakeasy (DOT) net
> <mailto:julianhyde (AT) speakeasy (DOT) net>>
> Para: Mondrian developer mailing list <mondrian (AT) pentaho (DOT) org
> <mailto:mondrian (AT) pentaho (DOT) org>>
> Enviado: martes, 3 de abril, 2007 18:53:55
> Asunto: RE: [Mondrian] XMLA Security
>
>
>
> **
> The problem with this security role is that when I try to
> retrieve all the children from [Estructura Comercial].[Toda
> la Estructura].[01] I get none, because the code navigates
> tries to solve the name one part at a time, but we do not
> have access to [Estructura Comercial].[Toda la Estructura].
>
> Is it that the role definition is wrong or should I adjust
> the code (which is really complicated!!!!)
>
>
> The code which looks up the member being granted should
> definitely do so in a non-access-controlled context. By all
> means adjust the code (and be sure to add a unit test for the
> bug). Maybe use the global schema reader?
>
> Julian
> _______________________________________________
> Mondrian mailing list
> Mondrian (AT) pentaho (DOT) org <mailto:Mondrian (AT) pentaho (DOT) org>
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>
> ------------------------------------------------------------------------
>
> LLama Gratis a cualquier PC del Mundo.
> Llamadas a fijos y m

Julian Hyde
04-20-2007, 02:30 PM
I wrote a unit test and checked in your changes as change 9138:

<http://p4web.eigenbase.org/@md=d&c=6PU@//9138?ac=10>
http://p4web.eigenbase.org/@md=d&c=6PU@//9138?ac=10

See XmlaBasicTest.testMDLevelsAccessControlled. This only checks the
behavior of MDSCHEMA_LEVELS. Similar tests are needed for other XMLA
metadata queries. Please add more tests similar to that to match the
behavior you need.

Julian




_____

From: Pedro Casals [mailto:pcasalsfradera (AT) yahoo (DOT) com]
Sent: Tuesday, April 17, 2007 10:33 AM
To: Julian Hyde
Subject: Re: [Mondrian] XMLA Security


Julian:

You told me to provide a unit test, but the unit test is already done!
It's the access control test, with the only difference that access is
done through XMLA and not with mondrian native access. I do not know how
to define the system so it does twice the access control test, one with
the mondrian native connection and the second with XMLA connection.

What must I do now?

Yours,.

Pedro


----- Mensaje original ----
De: Julian Hyde <julianhyde (AT) speakeasy (DOT) net>
Para: Pedro Casals <pcasalsfradera (AT) yahoo (DOT) com>
Enviado: lunes, 9 de abril, 2007 10:31:09
Asunto: RE: [Mondrian] XMLA Security


Pedro,

Can you contribute a unit test. I will not check in this code until you
do so.

Julian


_____

From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org]
On Behalf Of Julian Hyde
Sent: Wednesday, April 04, 2007 11:33 PM
To: 'Mondrian developer mailing list'
Subject: RE: [Mondrian] XMLA Security


Can you also contribute a unit test, against the foodmart schema? Code
without a unit test is like a really cool Xmas present with no batteries
included! See mondrian.test.AccessControlTest and
mondrian.test.SchemaTest for some examples.

I don't agree that members should be the total of only their visible
children. For example, if Fred has access to only [USA].[CA].[San
Francisco] and [USA].[CA].[Oakland], I think the total for [USA].[CA]
should include all cities in California.

I don't deny that there are cases where you would only want to see the
total of the accessible cities. But in my opinion it shouldn't be the
default behavior. I think there is some way to write a calculated member
for that - I would be open to extending the language to make that easier
to achieve. Anyone know what MSAS does here?

Julian


_____

From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org]
On Behalf Of Pedro Casals
Sent: Wednesday, April 04, 2007 4:04 AM
To: Mondrian developer mailing list
Subject: Re: [Mondrian] XMLA Security


Thanks to your hint I realized that code changes were small. Since I
have no access to CVS, I post here the changed classes. All changes are
marked with this comment: //PCF : role
Besides, I attach a default callback implementation and the needed
modification in web.xml.
I also attach the security role definition, that covers most of the
situations:
- Grant only some measures
- Deny a hole dimension.
- Deny part of an hierarchy, both in levels and members

Pending:
JPivot is not placing the role in the HTTP header. I will ask to Andreas
which is his preferred approach, and my proposed solution.

Known bug at this moment:
- Security role definition is order dependant, more than specified in
doc. For example: in my role definition, if the definition of
[Estructura Comercial] is placed before Dimension definition, the latter
is not taken into account!
- look at XMLA Security bug.xls attached file. If a member of a level of
an hierarchy is denied, the member is computed for the totals of the
ancestors (wich is wrong), but is not computed on its own level (wich is
correct).

Pedro

----- Mensaje original ----
De: Julian Hyde <julianhyde (AT) speakeasy (DOT) net>
Para: Mondrian developer mailing list <mondrian (AT) pentaho (DOT) org>
Enviado: martes, 3 de abril, 2007 18:53:55
Asunto: RE: [Mondrian] XMLA Security







The problem with this security role is that when I try to retrieve all
the children from [Estructura Comercial].[Toda la Estructura].[01] I get
none, because the code navigates tries to solve the name one part at a
time, but we do not have access to [Estructura Comercial].[Toda la
Estructura].

Is it that the role definition is wrong or should I adjust the code
(which is really complicated!!!!)


The code which looks up the member being granted should definitely do so
in a non-access-controlled context. By all means adjust the code (and be
sure to add a unit test for the bug). Maybe use the global schema
reader?

Julian
_______________________________________________
Mondrian mailing list
Mondrian (AT) pentaho (DOT) org
http://lists.pentaho.org/mailman/listinfo/mondrian


_____


LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y m