Hitachi Vantara Pentaho Community Forums
Results 1 to 19 of 19

Thread: [Mondrian] Fwd: Re: xmla security header processing

  1. #1
    Michele Rossi Guest

    Default [Mondrian] Fwd: Re: xmla security header processing

    Sent from my iPhone

    Begin forwarded message:

    > From: "Julian Hyde" <jhyde (AT) pentaho (DOT) com>
    > Date: 21 June 2011 19:23:53 CEST
    > To: "'Michele Rossi'" <michele.rossi (AT) gmail (DOT) com>
    > Subject: RE: [Mondrian] Re: xmla security header processing
    > Reply-To: <jhyde (AT) pentaho (DOT) com>
    >


    > again, to devs list please.
    >
    > From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    > Sent: Tuesday, June 21, 2011 8:52 AM
    > To: jhyde (AT) pentaho (DOT) com
    > Subject: Re: [Mondrian] Re: xmla security header processing
    >
    > hi Julian,
    > I've implemented the first easy bit so that we can test whether the packChange process works.
    > You can now optionally specify the return values for "discover datasources" in the web.xml configuration. If you do the DISCOVER_DATASOURCES rowset will not require a new OlapConnection.
    >
    > Could you please let me know if this change is ok and if you can read my packed change?
    >
    > Tomorrow I will start the more complex bit - the use of commons-dbcp to pool the OlapConnections.
    >
    >
    > thanks,
    > Michele
    >
    >
    > On 20 June 2011 21:29, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    > The two should be equivalent. Let's go with the 'unpackChange' approach since it seems to be working.
    >
    > The only problem is with NonEmptyTest.java. It refused to overwrite a writable file -- which is sensible if you think about it.
    >
    > I think you should go with the version of NonEmptyTest.java in the .tar.gz file. If you have made changes to NonEmptyTest.java that you want to keep, you will have to manually apply them.
    >
    > Julian
    >
    > From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    > Sent: Monday, June 20, 2011 8:33 AM
    > To: jhyde (AT) pentaho (DOT) com
    >
    > Subject: Re: [Mondrian] Re: xmla security header processing
    >
    > hi Julian,
    > I've been able to apply the packed change but the patching continues to be elusive.
    > The two approaches are equivalent right?
    >
    > I've included the output of the "unpackChange" and "patch" commands.
    >
    > Thanks!
    > Michele
    >
    > mrossi@PI-mrossi-L-1 /cygdrive/c/Work/thirdparty/mondrian_perforce/open/mondrian
    > $ unpackChange -c 14233 ../../../mondrian_scripts/patches_and_packed_changes/changelist14233.tar.gz
    > File(s) not opened on this client.
    > //open/mondrian/src/main/mondrian/tui/XmlaSupport.java#27 - file(s) up-to-date.
    > Change 14233 belongs to client jhyde.marmite2.
    > //open/mondrian/src/main/mondrian/xmla/RowsetDefinition.java#81 - file(s) up-to-date.
    > Change 14233 belongs to client jhyde.marmite2.
    > //open/mondrian/src/main/mondrian/xmla/XmlaConstants.java#13 - file(s) up-to-date.
    > Change 14233 belongs to client jhyde.marmite2.
    > //open/mondrian/src/main/mondrian/xmla/XmlaHandler.java#76 - file(s) up-to-date.
    > Change 14233 belongs to client jhyde.marmite2.
    > //open/mondrian/src/main/mondrian/xmla/XmlaRequest.java#11 - file(s) up-to-date.
    > Change 14233 belongs to client jhyde.marmite2.
    > //open/mondrian/src/main/mondrian/xmla/XmlaServlet.java#40 - file(s) up-to-date.
    > Change 14233 belongs to client jhyde.marmite2.
    > //open/mondrian/src/main/mondrian/xmla/XmlaUtil.java#31 - file(s) up-to-date.
    > Change 14233 belongs to client jhyde.marmite2.
    > //open/mondrian/src/main/mondrian/xmla/impl/DefaultSaxWriter.java#12 - file(s) up-to-date.
    > Change 14233 belongs to client jhyde.marmite2.
    > //open/mondrian/src/main/mondrian/xmla/impl/DefaultXmlaRequest.java#19 - file(s) up-to-date.
    > Change 14233 belongs to client jhyde.marmite2.
    > //open/mondrian/src/main/mondrian/xmla/impl/DefaultXmlaServlet.java#30 - file(s) up-to-date.
    > Change 14233 belongs to client jhyde.marmite2.
    > //open/mondrian/testsrc/main/mondrian/rolap/NonEmptyTest.java#145 - updating C:\Work\thirdparty\mondrian_perforce\open\mondrian\test
    > src\main\mondrian\rolap\NonEmptyTest.java
    > Can't clobber writable file C:\Work\thirdparty\mondrian_perforce\open\mondrian\testsrc\main\mondrian\rolap\NonEmptyTest.java
    > Change 14233 belongs to client jhyde.marmite2.
    > //open/mondrian/testsrc/main/mondrian/xmla/test/XmlaTest.java#23 - file(s) up-to-date.
    > Change 14233 belongs to client jhyde.marmite2.
    > New change number is 14233
    >
    >
    >
    >
    > mrossi@PI-mrossi-L-1 /cygdrive/c/Work/thirdparty/mondrian_perforce/open/mondrian
    > $ patch -p l < ../../../mondrian_scripts/patches_and_packed_changes/jhyde2..patch
    > patch: **** strip count l is not a number
    >
    > mrossi@PI-mrossi-L-1 /cygdrive/c/Work/thirdparty/mondrian_perforce/open/mondrian
    > $ patch -p 1 < ../../../mondrian_scripts/patches_and_packed_changes/jhyde2..patch
    > patching file src/main/mondrian/tui/XmlaSupport.java
    > Reversed (or previously applied) patch detected! Assume -R? [n] Y
    > Apply anyway? [n] Y
    > Skipping patch.
    > 1 out of 1 hunk ignored -- saving rejects to file src/main/mondrian/tui/XmlaSupport.java.rej
    > patching file src/main/mondrian/xmla/RowsetDefinition.java
    > Reversed (or previously applied) patch detected! Assume -R? [n]
    > Apply anyway? [n] y
    > Hunk #1 FAILED at 1.
    > Hunk #2 FAILED at 41.
    > Hunk #3 succeeded at 6436 with fuzz 2 (offset 12 lines).
    > 2 out of 3 hunks FAILED -- saving rejects to file src/main/mondrian/xmla/RowsetDefinition.java.rej
    > patching file src/main/mondrian/xmla/XmlaConstants.java
    > Reversed (or previously applied) patch detected! Assume -R? [n] Y
    > Apply anyway? [n] y
    > Hunk #1 succeeded at 9 with fuzz 2 (offset -38 lines).
    > Hunk #2 FAILED at 26.
    > 1 out of 2 hunks FAILED -- saving rejects to file src/main/mondrian/xmla/XmlaConstants.java.rej
    > patching file src/main/mondrian/xmla/XmlaHandler.java
    > Reversed (or previously applied) patch detected! Assume -R? [n]
    >
    >
    >
    > On 16 June 2011 23:11, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    > Two options for the patch file:
    >
    > 1. The patch file was the wrong format. I fixed it. See attached. Apply it using 'patch -p 1 < jhyde2.patch'.
    >
    > For this you will need to install cygwin, including the patch command.
    >
    > OR...
    >
    > 2. I have also attached a file generated by packChange. See attached. Apply using 'unpackChange changelist14233.tar.gz'.
    >
    > For this you will need to install cygwin, plus the packChange and unpackChange scripts from http://p4webhost.eigenbase.org:8080/open/util/bin/. Put them somewhere on cygwin's path, e.g. /usr/local/bin, and give them execute access 'chmod 755 ...'.
    >
    > To check out files for edit, use the user 'considerate_guest'. The password is 'consider8'.
    >
    > Julian
    >
    >
    >
    > From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    > Sent: Wednesday, June 15, 2011 6:47 AM
    >
    > To: jhyde (AT) pentaho (DOT) com; Mondrian developer mailing list
    > Subject: Re: [Mondrian] Re: xmla security header processing
    >
    > hi Julian,
    > sorry for the long delay, I've only just started working on this task again.
    >
    > I have been trying to apply your patch but unfortunately I get an error message, "Invalid patch file".
    > I haven't found a way to apply your patch from the "p4" command line tool (I have googled for a considerable amount of time, no luck. I use the p4 eclipse plugin 2010.1/275861, I couldn't do with the March 2011 p4v client either).
    >
    > Could we consider switching to "perforce shelving" instead of patches?
    > Or some other way to allow non-authorised committers to deal with the mondrian perforce in a more efficient way? For example we could create a special branch where everybody can commit too.
    > Then you could decide what things you want to merge back to the main branch.
    > It's just an idea.. I am obviously not too good with patch files.
    >
    > Back to the XMLA servlet:
    >
    > 1. it looks like we need very different connection creation policies: I need to create authenticated connections and I need to associate connections to sessions.
    > If it's something that you don't want could we think about allowing the injection of different OlapConnectionFactory implementations?
    > That way I could make an OlapConnectionFactory that caches connections and associates them with user sessions while the default behaviour would be what it is now.
    >
    > 2. I am happy to use the container-level session to store authentication credentials - that is something that you suggested and that I will implement asap
    >
    > 3. We have a problem with the first request that SimbaO2X sends without authentication.
    > The request is "Discover Datasources".
    > Are you happy if I allow users to provide their own hard-coded response to such request?
    > It could go in the web.xml.
    > When such configuration is not hard coded the system would behave as now and would try to obtain it from a OlapConnection object.
    >
    >
    > many thanks,
    > Michele
    >
    >
    >
    > On 26 May 2011 15:49, Michele Rossi <michele.rossi (AT) gmail (DOT) com> wrote:
    > hi Julian,
    > I've replied to some of your questions inline.
    >
    > thanks,
    > Michele
    >
    > On 25 May 2011 00:43, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    > Michele,
    >
    > As promised, I've reviewed your changes.
    >
    > All in all, the change looks useful. I can see that we need to introduce the notion of 'sessions' due to the way Simba O2X sends its requests. But I am concerned at how many places username & password are now present in the API, and the result is so confusing it's difficult to say that there are not security holes.
    >
    > If you can address my concerns, I will commit your changes. I've changed quite a lot of the code; see the patch attached. Can you use that patch as starting point when fixing the issues I raise below. And when you have made changes, please generate a similar patch using 'p4 diff -du' from the command line.
    >
    > Detailed comments...
    >
    > 0. Would it be simpler if the servlet looked for the <Security> tag and session information and copied these into the HTTP headers? Then we could use HTTP athentication and session lifecycle management. Just an idea.
    >
    > My main problem is to create an authenticated OlapConnection.
    > Hence I need the credentials to be processed in the code that creates the connection and not by the container.
    >
    >
    > 1. MondrianServerImpl.getConnection is not used. Removed it.
    >
    > 2. It is a bad idea to pool connections. If you want to pool connections, use a connection pool. It is an even worse idea to pool connections based on session ID -- that implies that you are trying to make sessions stateful, and it is much better if the XMLA servlet is stateless.
    >
    > So, I removed ConnectionHolder and the "connections" member.
    >
    > The problem is that Simba will create something like 15 connections before you can even start configuring a Pivot in Excel.
    >
    > In general I believe that creating a new connection for each request is an anti-pattern as it leads to a substantial waste of resources.
    >
    > In my case in particular this approach wouldn't work at all as I cache the metadata objects at the connection level.
    > So before displaying a Pivot in Excel I'd have to populate the whole metadata cache N times, once for each connection I create.
    >
    > Connection pooling is the technique normally used by more traditional web apps that require access to a database for this problem and it can be implemented either at the application level (e.g. commons-dbcp) and or at the container level (tomcat can handle pool of connections to databases) .
    >
    > I am aware that my implementation didn't clean up un-used connections.
    > I didn't want to submit too much code at once and risk wasting time if you didn't like all the rest of the work.
    >
    >
    > I see why we need to save username & password so that they can be retrieved by subsequent requests in the same session. But your implementation never removed entries from that table. I added code to remove the entry when we see an 'end of session'. It would be nice if we could hook into HTTP session management (see #0 above).
    >
    > We can definitely save the credentials in the Http Session. The new version of Simba supports Cookies too which means that this approach could work.
    > I will start thinking about this approach.
    >
    >
    > 3. In removing the "connections" member, I may have broken the mechanism by which subsequent requests in the same XMLA session inherit the same password. (Difficult to tell without unit tests.) If so, I apologize.
    >
    > But it is not obvious how session context is conveyed along with the XmlaRequest. Would it make sense to replace 'String XmlaRequest.getSessionId()' (and getUsername() and getPassword()) with a
    > 'SessionInfo XmlaRequest.getSessionInfo()' method that contains all session context?
    >
    > Yes definitely - although the end result is very similar this approach is probably more flexible.
    >
    >
    > 4. Please convince me that you are not opening up a security hole, as follows. The context contains a role name. It also may contain username and password, if the client happens to be using basic authentication. Suppose that a malicious client specified a valid username and password in its HTTP headers, but also specified a role that had greater privileges than the username and password allowed. Would that client be able to gain greater privileges than it deserved?
    >
    > I don't think the Xmla Servlet supports basic authentication - you could enable basic authentication at the container level but I really don't know much about this.
    > The credentials I am interested in are provided in the SOAP payload by SimbaO2X, they don't come from HTTP headers.
    >
    > Also how are clients currently specifying their "role" ?
    > What stops them from choosing anything they like as their role?
    > (I will also start doing my own research on these points)
    >
    >
    > It needs to be clear and foolproof in the code whether the client is trusted. If trusted, it can adopt whichever role it choses. If not, it must take the role assigned by olap4j after authentication.
    >
    > I don't fully understand the significance of the role - it's not something I use in my driver but I know that mondrian uses it. Is it a standard JDBC concept or something mondrian specific?
    > I will find out more about it.
    >
    >
    > 5. What does your comment "we'd need to inject the HttpServletRequest into this method" mean?
    >
    > What I meant was that if we wanted to make the host name that made the request (IP of the client machine) available in the context, we would need to have access to the HttpServletRequest.
    > I need that information for licensing reasons.
    >
    >
    > 6. There is a magic id for un-authenticated session. Is this a security hole?
    >
    > Unfortunately Simba fires off the very first XMLA "DISCOVER" request (Discover Datasources) without providing any authentication credentials.
    > It's as if Simba expected the server side to know about its data sources without opening a database connection.
    > We could approach this problem in other ways, for example by providing the list of data sources in a different way.
    > I will think about it.
    >
    > In any case an un-authenticated connection is not a security hole per-se.
    > The behaviour depends on the particular implementation of Olap4j.
    > Some drivers might refuse to execute queries on OlapConnections created without credentials.
    > Other might not need authenticated connections at all.
    >
    >
    > 7. Would it make sense for the servlet to refuse basic authentication requests if they were not over HTTPS? (And not just the first request, which carries username/password. Subsequent requests carry an authenticated session ID, so they must be protected also.)
    >
    > Again I need to go back and study the relation between the xmla servlet and basic authentication as I don't understand it yet.
    >
    >
    > 8. I fixed XmlaBasicTest. Maybe other tests are broken also. Can you please ensure that the tests run clean before you re-submit.
    >
    > Will do.
    >
    > 9. Add unit test for basic authentication. (It's hard for me to review this code if it is not used in the test suite.)
    >
    > Ok maybe by Basic Authentication you mean the SOAP authentication provided by Excel / Simba.
    > I will look into it as discussed above.
    >
    >
    > 10. Is the security model assuming that session ids are hard to guess?
    >
    > Yes that is always expected by session IDs - you want to prevent an attacker from guessing a valid ID.
    > So I can make the session ID generation algo a bit better.
    >
    >
    >
    >


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

  2. #2
    Julian Hyde Guest

    Default Re: [Mondrian] Fwd: Re: xmla security header processing

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

  3. #3
    Michele Rossi Guest

    Default Re: [Mondrian] Fwd: Re: xmla security header processing

    hi Julian,
    the configuration is in the web.xml, see attached screenshot.

    Michele

    Sent from my iPhone

    On 21 Jun 2011, at 20:41, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:

    > Looks good; but where do you configure that actual XML that DiscoverDatasources will return? Could that XML go in web.xml also?
    >
    > (For the other devs on the list, some context. The problem is with an XMLA servlet that gives access to two or more olap4j sources. It is not appropriate for either of those sources to answeer the DiscoverDatasources request individually. Only the servlet knows the whole story. It needs to answer the request before opening an olap4j connection. Therefore the metadata needs to come from the servlet, not from an olap4j driver.)
    >
    > From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of Michele Rossi
    > Sent: Tuesday, June 21, 2011 10:29 AM
    > To: Mondrian developer mailing list
    > Subject: [Mondrian] Fwd: Re: xmla security header processing
    >
    >
    >
    > Sent from my iPhone
    >
    > Begin forwarded message:
    >
    >> From: "Julian Hyde" <jhyde (AT) pentaho (DOT) com>
    >> Date: 21 June 2011 19:23:53 CEST
    >> To: "'Michele Rossi'" <michele.rossi (AT) gmail (DOT) com>
    >> Subject: RE: [Mondrian] Re: xmla security header processing
    >> Reply-To: <jhyde (AT) pentaho (DOT) com>
    >>

    >
    >> again, to devs list please.
    >>
    >> From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >> Sent: Tuesday, June 21, 2011 8:52 AM
    >> To: jhyde (AT) pentaho (DOT) com
    >> Subject: Re: [Mondrian] Re: xmla security header processing
    >>
    >> hi Julian,
    >> I've implemented the first easy bit so that we can test whether the packChange process works.
    >> You can now optionally specify the return values for "discover datasources" in the web.xml configuration. If you do the DISCOVER_DATASOURCES rowset will not require a new OlapConnection.
    >>
    >> Could you please let me know if this change is ok and if you can read my packed change?
    >>
    >> Tomorrow I will start the more complex bit - the use of commons-dbcp to pool the OlapConnections.
    >>
    >>
    >> thanks,
    >> Michele
    >>
    >> <web_xml_xmla.png>
    >> On 20 June 2011 21:29, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >> The two should be equivalent. Let's go with the 'unpackChange' approach since it seems to be working.
    >>
    >> The only problem is with NonEmptyTest.java. It refused to overwrite a writable file -- which is sensible if you think about it.
    >>
    >> I think you should go with the version of NonEmptyTest.java in the .tar.gz file. If you have made changes to NonEmptyTest.java that you want to keep, you will have to manually apply them.
    >>
    >> Julian
    >>
    >> From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >> Sent: Monday, June 20, 2011 8:33 AM
    >> To: jhyde (AT) pentaho (DOT) com
    >>
    >> Subject: Re: [Mondrian] Re: xmla security header processing
    >>
    >> hi Julian,
    >> I've been able to apply the packed change but the patching continues to be elusive.
    >> The two approaches are equivalent right?
    >>
    >> I've included the output of the "unpackChange" and "patch" commands.
    >>
    >> Thanks!
    >> Michele
    >>
    >> mrossi@PI-mrossi-L-1 /cygdrive/c/Work/thirdparty/mondrian_perforce/open/mondrian
    >> $ unpackChange -c 14233 ../../../mondrian_scripts/patches_and_packed_changes/changelist14233.tar.gz
    >> File(s) not opened on this client.
    >> //open/mondrian/src/main/mondrian/tui/XmlaSupport.java#27 - file(s) up-to-date.
    >> Change 14233 belongs to client jhyde.marmite2.
    >> //open/mondrian/src/main/mondrian/xmla/RowsetDefinition.java#81 - file(s) up-to-date.
    >> Change 14233 belongs to client jhyde.marmite2.
    >> //open/mondrian/src/main/mondrian/xmla/XmlaConstants.java#13 - file(s) up-to-date.
    >> Change 14233 belongs to client jhyde.marmite2.
    >> //open/mondrian/src/main/mondrian/xmla/XmlaHandler.java#76 - file(s) up-to-date.
    >> Change 14233 belongs to client jhyde.marmite2.
    >> //open/mondrian/src/main/mondrian/xmla/XmlaRequest.java#11 - file(s) up-to-date.
    >> Change 14233 belongs to client jhyde.marmite2.
    >> //open/mondrian/src/main/mondrian/xmla/XmlaServlet.java#40 - file(s) up-to-date.
    >> Change 14233 belongs to client jhyde.marmite2.
    >> //open/mondrian/src/main/mondrian/xmla/XmlaUtil.java#31 - file(s) up-to-date.
    >> Change 14233 belongs to client jhyde.marmite2.
    >> //open/mondrian/src/main/mondrian/xmla/impl/DefaultSaxWriter.java#12 - file(s) up-to-date.
    >> Change 14233 belongs to client jhyde.marmite2.
    >> //open/mondrian/src/main/mondrian/xmla/impl/DefaultXmlaRequest.java#19 - file(s) up-to-date.
    >> Change 14233 belongs to client jhyde.marmite2.
    >> //open/mondrian/src/main/mondrian/xmla/impl/DefaultXmlaServlet.java#30 - file(s) up-to-date.
    >> Change 14233 belongs to client jhyde.marmite2.
    >> //open/mondrian/testsrc/main/mondrian/rolap/NonEmptyTest.java#145 - updating C:\Work\thirdparty\mondrian_perforce\open\mondrian\test
    >> src\main\mondrian\rolap\NonEmptyTest.java
    >> Can't clobber writable file C:\Work\thirdparty\mondrian_perforce\open\mondrian\testsrc\main\mondrian\rolap\NonEmptyTest.java
    >> Change 14233 belongs to client jhyde.marmite2.
    >> //open/mondrian/testsrc/main/mondrian/xmla/test/XmlaTest.java#23 - file(s) up-to-date.
    >> Change 14233 belongs to client jhyde.marmite2.
    >> New change number is 14233
    >>
    >>
    >>
    >>
    >> mrossi@PI-mrossi-L-1 /cygdrive/c/Work/thirdparty/mondrian_perforce/open/mondrian
    >> $ patch -p l < ../../../mondrian_scripts/patches_and_packed_changes/jhyde2.patch
    >> patch: **** strip count l is not a number
    >>
    >> mrossi@PI-mrossi-L-1 /cygdrive/c/Work/thirdparty/mondrian_perforce/open/mondrian
    >> $ patch -p 1 < ../../../mondrian_scripts/patches_and_packed_changes/jhyde2.patch
    >> patching file src/main/mondrian/tui/XmlaSupport.java
    >> Reversed (or previously applied) patch detected! Assume -R? [n] Y
    >> Apply anyway? [n] Y
    >> Skipping patch.
    >> 1 out of 1 hunk ignored -- saving rejects to file src/main/mondrian/tui/XmlaSupport.java.rej
    >> patching file src/main/mondrian/xmla/RowsetDefinition.java
    >> Reversed (or previously applied) patch detected! Assume -R? [n]
    >> Apply anyway? [n] y
    >> Hunk #1 FAILED at 1.
    >> Hunk #2 FAILED at 41.
    >> Hunk #3 succeeded at 6436 with fuzz 2 (offset 12 lines).
    >> 2 out of 3 hunks FAILED -- saving rejects to file src/main/mondrian/xmla/RowsetDefinition.java.rej
    >> patching file src/main/mondrian/xmla/XmlaConstants.java
    >> Reversed (or previously applied) patch detected! Assume -R? [n] Y
    >> Apply anyway? [n] y
    >> Hunk #1 succeeded at 9 with fuzz 2 (offset -38 lines).
    >> Hunk #2 FAILED at 26.
    >> 1 out of 2 hunks FAILED -- saving rejects to file src/main/mondrian/xmla/XmlaConstants.java.rej
    >> patching file src/main/mondrian/xmla/XmlaHandler.java
    >> Reversed (or previously applied) patch detected! Assume -R? [n]
    >>
    >>
    >>
    >> On 16 June 2011 23:11, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >> Two options for the patch file:
    >>
    >> 1. The patch file was the wrong format. I fixed it. See attached. Apply it using 'patch -p 1 < jhyde2.patch'.
    >>
    >> For this you will need to install cygwin, including the patch command.
    >>
    >> OR...
    >>
    >> 2. I have also attached a file generated by packChange. See attached. Apply using 'unpackChange changelist14233.tar.gz'.
    >>
    >> For this you will need to install cygwin, plus the packChange and unpackChange scripts from http://p4webhost.eigenbase.org:8080/open/util/bin/. Put them somewhere on cygwin's path, e.g. /usr/local/bin, and give them execute access 'chmod 755 ...'.
    >>
    >> To check out files for edit, use the user 'considerate_guest'. The password is 'consider8'.
    >>
    >> Julian
    >>
    >>
    >>
    >> From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >> Sent: Wednesday, June 15, 2011 6:47 AM
    >>
    >> To: jhyde (AT) pentaho (DOT) com; Mondrian developer mailing list
    >> Subject: Re: [Mondrian] Re: xmla security header processing
    >>
    >> hi Julian,
    >> sorry for the long delay, I've only just started working on this task again.
    >>
    >> I have been trying to apply your patch but unfortunately I get an error message, "Invalid patch file".
    >> I haven't found a way to apply your patch from the "p4" command line tool (I have googled for a considerable amount of time, no luck. I use the p4 eclipse plugin 2010.1/275861, I couldn't do with the March 2011 p4v client either).
    >>
    >> Could we consider switching to "perforce shelving" instead of patches?
    >> Or some other way to allow non-authorised committers to deal with the mondrian perforce in a more efficient way? For example we could create a special branch where everybody can commit too.
    >> Then you could decide what things you want to merge back to the main branch.
    >> It's just an idea.. I am obviously not too good with patch files.
    >>
    >> Back to the XMLA servlet:
    >>
    >> 1. it looks like we need very different connection creation policies: I need to create authenticated connections and I need to associate connections to sessions.
    >> If it's something that you don't want could we think about allowing the injection of different OlapConnectionFactory implementations?
    >> That way I could make an OlapConnectionFactory that caches connections and associates them with user sessions while the default behaviour would be what it is now.
    >>
    >> 2. I am happy to use the container-level session to store authentication credentials - that is something that you suggested and that I will implement asap
    >>
    >> 3. We have a problem with the first request that SimbaO2X sends without authentication.
    >> The request is "Discover Datasources".
    >> Are you happy if I allow users to provide their own hard-coded response to such request?
    >> It could go in the web.xml.
    >> When such configuration is not hard coded the system would behave as now and would try to obtain it from a OlapConnection object.
    >>
    >>
    >> many thanks,
    >> Michele
    >>
    >>
    >>
    >> On 26 May 2011 15:49, Michele Rossi <michele.rossi (AT) gmail (DOT) com> wrote:
    >> hi Julian,
    >> I've replied to some of your questions inline.
    >>
    >> thanks,
    >> Michele
    >>
    >> On 25 May 2011 00:43, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >> Michele,
    >>
    >> As promised, I've reviewed your changes.
    >>
    >> All in all, the change looks useful. I can see that we need to introduce the notion of 'sessions' due to the way Simba O2X sends its requests. But I am concerned at how many places username & password are now present in the API, and the result is so confusing it's difficult to say that there are not security holes.
    >>
    >> If you can address my concerns, I will commit your changes. I've changed quite a lot of the code; see the patch attached. Can you use that patch as starting point when fixing the issues I raise below. And when you have made changes, please generate a similar patch using 'p4 diff -du' from the command line.
    >>
    >> Detailed comments...
    >>
    >> 0. Would it be simpler if the servlet looked for the <Security> tag and session information and copied these into the HTTP headers? Then we could use HTTP athentication and session lifecycle management. Just an idea.
    >>
    >> My main problem is to create an authenticated OlapConnection.
    >> Hence I need the credentials to be processed in the code that creates the connection and not by the container.
    >>
    >>
    >> 1. MondrianServerImpl.getConnection is not used. Removed it.
    >>
    >> 2. It is a bad idea to pool connections. If you want to pool connections, use a connection pool. It is an even worse idea to pool connections based on session ID -- that implies that you are trying to make sessions stateful, and it is much better if the XMLA servlet is stateless.
    >>
    >> So, I removed ConnectionHolder and the "connections" member.
    >>
    >> The problem is that Simba will create something like 15 connections before you can even start configuring a Pivot in Excel.
    >>
    >> In general I believe that creating a new connection for each request is an anti-pattern as it leads to a substantial waste of resources.
    >>
    >> In my case in particular this approach wouldn't work at all as I cache the metadata objects at the connection level.
    >> So before displaying a Pivot in Excel I'd have to populate the whole metadata cache N times, once for each connection I create.
    >>
    >> Connection pooling is the technique normally used by more traditional web apps that require access to a database for this problem and it can be implemented either at the application level (e.g. commons-dbcp) and or at the container level (tomcat can handle pool of connections to databases) .
    >>
    >> I am aware that my implementation didn't clean up un-used connections.
    >> I didn't want to submit too much code at once and risk wasting time if you didn't like all the rest of the work.
    >>
    >>
    >> I see why we need to save username & password so that they can be retrieved by subsequent requests in the same session. But your implementation never removed entries from that table. I added code to remove the entry when we see an 'end of session'. It would be nice if we could hook into HTTP session management (see #0 above).
    >>
    >> We can definitely save the credentials in the Http Session. The new version of Simba supports Cookies too which means that this approach could work.
    >> I will start thinking about this approach.
    >>
    >>
    >> 3. In removing the "connections" member, I may have broken the mechanism by which subsequent requests in the same XMLA session inherit the same password. (Difficult to tell without unit tests.) If so, I apologize.
    >>
    >> But it is not obvious how session context is conveyed along with the XmlaRequest. Would it make sense to replace 'String XmlaRequest.getSessionId()' (and getUsername() and getPassword()) with a
    >> 'SessionInfo XmlaRequest.getSessionInfo()' method that contains all session context?
    >>
    >> Yes definitely - although the end result is very similar this approach is probably more flexible.
    >>
    >>
    >> 4. Please convince me that you are not opening up a security hole, as follows. The context contains a role name. It also may contain username and password, if the client happens to be using basic authentication. Suppose that a malicious client specified a valid username and password in its HTTP headers, but also specified a role that had greater privileges than the username and password allowed. Would that client be able to gain greater privileges than it deserved?
    >>
    >> I don't think the Xmla Servlet supports basic authentication - you could enable basic authentication at the container level but I really don't know much about this.
    >> The credentials I am interested in are provided in the SOAP payload by SimbaO2X, they don't come from HTTP headers.
    >>
    >> Also how are clients currently specifying their "role" ?
    >> What stops them from choosing anything they like as their role?
    >> (I will also start doing my own research on these points)
    >>
    >>
    >> It needs to be clear and foolproof in the code whether the client is trusted. If trusted, it can adopt whichever role it choses. If not, it must take the role assigned by olap4j after authentication.
    >>
    >> I don't fully understand the significance of the role - it's not something I use in my driver but I know that mondrian uses it. Is it a standard JDBC concept or something mondrian specific?
    >> I will find out more about it.
    >>
    >>
    >> 5. What does your comment "we'd need to inject the HttpServletRequest into this method" mean?
    >>
    >> What I meant was that if we wanted to make the host name that made the request (IP of the client machine) available in the context, we would need to have access to the HttpServletRequest.
    >> I need that information for licensing reasons.
    >>
    >>
    >> 6. There is a magic id for un-authenticated session. Is this a security hole?
    >>
    >> Unfortunately Simba fires off the very first XMLA "DISCOVER" request (Discover Datasources) without providing any authentication credentials.
    >> It's as if Simba expected the server side to know about its data sources without opening a database connection.
    >> We could approach this problem in other ways, for example by providing the list of data sources in a different way.
    >> I will think about it.
    >>
    >> In any case an un-authenticated connection is not a security hole per-se.
    >> The behaviour depends on the particular implementation of Olap4j.
    >> Some drivers might refuse to execute queries on OlapConnections created without credentials.
    >> Other might not need authenticated connections at all.
    >>
    >>
    >> 7. Would it make sense for the servlet to refuse basic authentication requests if they were not over HTTPS? (And not just the first request, which carries username/password. Subsequent requests carry an authenticated session ID, so they must be protected also.)
    >>
    >> Again I need to go back and study the relation between the xmla servlet and basic authentication as I don't understand it yet.
    >>
    >>
    >> 8. I fixed XmlaBasicTest. Maybe other tests are broken also. Can you please ensure that the tests run clean before you re-submit.
    >>
    >> Will do.
    >>
    >> 9. Add unit test for basic authentication. (It's hard for me to review this code if it is not used in the test suite.)
    >>
    >> Ok maybe by Basic Authentication you mean the SOAP authentication provided by Excel / Simba.
    >> I will look into it as discussed above.
    >>
    >>
    >> 10. Is the security model assuming that session ids are hard to guess?
    >>
    >> Yes that is always expected by session IDs - you want to prevent an attacker from guessing a valid ID.
    >> So I can make the session ID generation algo a bit better.
    >>
    >>
    >>
    >>

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


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

  4. #4
    Julian Hyde Guest

    Default Re: [Mondrian] Fwd: Re: xmla security header processing

    I could only see a boolean parameter:

    <init-param>

    <param-name>OlapDriverUsePreConfiguredDiscoverDatasourcesResponse</param-nam
    e>
    <param-value>true</param-value>
    </init-param>

    Where's the XML?



    Michele wrote:

    the configuration is in the web.xml, see attached screenshot.


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

  5. #5
    Michele Rossi Guest

    Default Re: [Mondrian] Fwd: Re: xmla security header processing

    hi Julian,
    see below, thanks
    Michele

    <web-app>
    <display-name>ARC XMLA Server</display-name>

    <servlet>
    <servlet-name>xmla</servlet-name>
    <servlet-class>mondrian.xmla.impl.Olap4jXmlaServlet</servlet-class>
    <init-param>
    <param-name>OlapDriverUsePreConfiguredDiscoverDatasourcesResponse</param-name>
    <param-value>true</param-value>
    </init-param>
    <init-param>
    <param-name>OlapDriverDiscoverDatasources.dataSourceName</param-name>
    <param-value>Proxy to Mondrian Foodmart</param-value>
    </init-param>
    <init-param>
    <param-name>OlapDriverDiscoverDatasources.dataSourceDescription</param-name>
    <param-value>Just a proxy to another mondrian xmla server</param-value>
    </init-param>
    <init-param>
    <param-name>OlapDriverDiscoverDatasources.url</param-name>
    <param-value>http://192.168.151.88:6080/xmla/xmla</param-value>
    </init-param>
    <init-param>
    <param-name>OlapDriverDiscoverDatasources.dataSourceInfo</param-name>
    <param-value>Proxy to Foodmart</param-value>
    </init-param>
    <init-param>
    <param-name>OlapDriverDiscoverDatasources.providerName</param-name>
    <param-value>Proxy to mondrian xmla server</param-value>
    </init-param>
    <init-param>
    <param-name>OlapDriverDiscoverDatasources.providerType</param-name>
    <param-value>TDP</param-value>
    </init-param>
    <init-param>
    <param-name>OlapDriverDiscoverDatasources.authenticationMode</param-name>
    <param-value>Unauthenticated</param-value>
    </init-param>

    [.........]

    On 21 June 2011 23:26, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:

    > **
    > I could only see a boolean parameter:
    >
    > <init-param>
    >
    > <param-name>OlapDriverUsePreConfiguredDiscoverDatasourcesResponse</param-name>
    > <param-value>true</param-value>
    > </init-param>
    >
    > Where's the XML?
    >
    > Michele wrote:
    >
    > the configuration is in the web.xml, see attached screenshot.
    >
    >


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

  6. #6
    Julian Hyde Guest

    Default Re: [Mondrian] Fwd: Re: xmla security header processing

    Looks good. Please make sure there's a test for it (so we don't break it
    accidentally).


    _____

    From: Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    Sent: Wednesday, June 22, 2011 12:35 AM
    To: jhyde (AT) pentaho (DOT) com; Mondrian developer mailing list
    Subject: Re: [Mondrian] Fwd: Re: xmla security header processing


    hi Julian,
    see below, thanks
    Michele

    <web-app>
    <display-name>ARC XMLA Server</display-name>

    <servlet>
    <servlet-name>xmla</servlet-name>
    <servlet-class>mondrian.xmla.impl.Olap4jXmlaServlet</servlet-class>

    <init-param>
    <param-name>OlapDriverUsePreConfiguredDiscoverDatasourcesResponse</param-nam
    e>
    <param-value>true</param-value>
    </init-param>

    <init-param>
    <param-name>OlapDriverDiscoverDatasources.dataSourceName</param-name>
    <param-value>Proxy to Mondrian Foodmart</param-value>
    </init-param>

    <init-param>
    <param-name>OlapDriverDiscoverDatasources.dataSourceDescription</param-name>
    <param-value>Just a proxy to another mondrian xmla server</param-value>
    </init-param>

    <init-param>
    <param-name>OlapDriverDiscoverDatasources.url</param-name>
    <param-value>http://192.168.151.88:6080/xmla/xmla</param-value>
    </init-param>

    <init-param>
    <param-name>OlapDriverDiscoverDatasources.dataSourceInfo</param-name>
    <param-value>Proxy to Foodmart</param-value>
    </init-param>

    <init-param>
    <param-name>OlapDriverDiscoverDatasources.providerName</param-name>
    <param-value>Proxy to mondrian xmla server</param-value>
    </init-param>

    <init-param>
    <param-name>OlapDriverDiscoverDatasources.providerType</param-name>
    <param-value>TDP</param-value>
    </init-param>

    <init-param>
    <param-name>OlapDriverDiscoverDatasources.authenticationMode</param-name>
    <param-value>Unauthenticated</param-value>
    </init-param>

    [.........]

    On 21 June 2011 23:26, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:



    I could only see a boolean parameter:

    <init-param>

    <param-name>OlapDriverUsePreConfiguredDiscoverDatasourcesResponse</param-nam
    e>
    <param-value>true</param-value>
    </init-param>

    Where's the XML?



    Michele wrote:

    the configuration is in the web.xml, see attached screenshot.



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

  7. #7
    Michele Rossi Guest

    Default Re: [Mondrian] Fwd: Re: xmla security header processing

    hi Julian,
    I've coded the connection pooling bit for the olap4j xmla servlet and I've
    tested it using Excel 2007.

    Basically I connect Excel 2007 to a local tomcat running the olap4j servlet
    and I configure the olap4j servlet to "talk" to another remote mondrian
    server using the XMLA Olap4j driver.

    Some of the pool parameters are configurable via the servlet configuration.
    You can change the "idle connections cleanup timeout" (default is 5 mins)
    and the max number of connections to pool per user (default is 1)

    I had to create a map of "BasicDataSource" connection pools as it was the
    only way I could find to create authenticated connections correctly.

    I couldn't find any other way to tell the DBCP classes to group together
    internally connections made for the same user.

    I also had to create a "Delegating Olap Connection" because you need to
    return something that implements "OlapConnection" and at the same time does
    the right thing when you call "close" (returns the connection to the pool).

    I had a look at creating unit tests and that seems like a fairly substantial
    piece of work.
    The existing testing classes are based on the MondrianOlap4jServlet.
    I guess we should try to run all xmla tests against the new olap4j servlet
    too.

    Do you have any opinion on that?

    thanks,
    Michele


    On 22 June 2011 19:51, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:

    > **
    > Looks good. Please make sure there's a test for it (so we don't break it
    > accidentally).
    >
    > ------------------------------
    > *From:* Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    > *Sent:* Wednesday, June 22, 2011 12:35 AM
    >
    > *To:* jhyde (AT) pentaho (DOT) com; Mondrian developer mailing list
    > *Subject:* Re: [Mondrian] Fwd: Re: xmla security header processing
    >
    > hi Julian,
    > see below, thanks
    > Michele
    >
    > <web-app>
    > <display-name>ARC XMLA Server</display-name>
    >
    > <servlet>
    > <servlet-name>xmla</servlet-name>
    > <servlet-class>mondrian.xmla.impl.Olap4jXmlaServlet</servlet-class>
    > <init-param>
    >
    > <param-name>OlapDriverUsePreConfiguredDiscoverDatasourcesResponse</param-name>
    > <param-value>true</param-value>
    > </init-param>
    > <init-param>
    > <param-name>OlapDriverDiscoverDatasources.dataSourceName</param-name>
    > <param-value>Proxy to Mondrian Foodmart</param-value>
    > </init-param>
    > <init-param>
    >
    > <param-name>OlapDriverDiscoverDatasources.dataSourceDescription</param-name>
    > <param-value>Just a proxy to another mondrian xmla server</param-value>
    > </init-param>
    > <init-param>
    > <param-name>OlapDriverDiscoverDatasources.url</param-name>
    > <param-value>http://192.168.151.88:6080/xmla/xmla</param-value>
    > </init-param>
    > <init-param>
    > <param-name>OlapDriverDiscoverDatasources.dataSourceInfo</param-name>
    > <param-value>Proxy to Foodmart</param-value>
    > </init-param>
    > <init-param>
    > <param-name>OlapDriverDiscoverDatasources.providerName</param-name>
    > <param-value>Proxy to mondrian xmla server</param-value>
    > </init-param>
    > <init-param>
    > <param-name>OlapDriverDiscoverDatasources.providerType</param-name>
    > <param-value>TDP</param-value>
    > </init-param>
    > <init-param>
    > <param-name>OlapDriverDiscoverDatasources.authenticationMode</param-name>
    > <param-value>Unauthenticated</param-value>
    > </init-param>
    >
    > [.........]
    >
    > On 21 June 2011 23:26, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >
    >> **
    >> I could only see a boolean parameter:
    >>
    >> <init-param>
    >>
    >> <param-name>OlapDriverUsePreConfiguredDiscoverDatasourcesResponse</param-name>
    >> <param-value>true</param-value>
    >> </init-param>
    >>
    >> Where's the XML?
    >>
    >> Michele wrote:
    >>
    >> the configuration is in the web.xml, see attached screenshot.
    >>
    >>

    >


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

  8. #8
    Michele Rossi Guest

    Default Re: [Mondrian] Fwd: Re: xmla security header processing

    hi Julian,
    please find attached a more recent version of my xmla-over-olap4j work.
    I've improved the connection pool management.
    I now use one scheduled task to run "evict" on all the active pools.
    It's better than using the default mechanism which would use a thread per
    pool.

    many thanks,
    Michele

    On 29 June 2011 17:51, Michele Rossi <michele.rossi (AT) gmail (DOT) com> wrote:

    > hi Julian,
    > I've coded the connection pooling bit for the olap4j xmla servlet and I've
    > tested it using Excel 2007.
    >
    > Basically I connect Excel 2007 to a local tomcat running the olap4j servlet
    > and I configure the olap4j servlet to "talk" to another remote mondrian
    > server using the XMLA Olap4j driver.
    >
    > Some of the pool parameters are configurable via the servlet configuration.
    > You can change the "idle connections cleanup timeout" (default is 5 mins)
    > and the max number of connections to pool per user (default is 1)
    >
    > I had to create a map of "BasicDataSource" connection pools as it was the
    > only way I could find to create authenticated connections correctly.
    >
    > I couldn't find any other way to tell the DBCP classes to group together
    > internally connections made for the same user.
    >
    > I also had to create a "Delegating Olap Connection" because you need to
    > return something that implements "OlapConnection" and at the same time does
    > the right thing when you call "close" (returns the connection to the pool).
    >
    > I had a look at creating unit tests and that seems like a fairly
    > substantial piece of work.
    > The existing testing classes are based on the MondrianOlap4jServlet.
    > I guess we should try to run all xmla tests against the new olap4j servlet
    > too.
    >
    > Do you have any opinion on that?
    >
    > thanks,
    > Michele
    >
    >
    > On 22 June 2011 19:51, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >
    >> **
    >> Looks good. Please make sure there's a test for it (so we don't break it
    >> accidentally).
    >>
    >> ------------------------------
    >> *From:* Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >> *Sent:* Wednesday, June 22, 2011 12:35 AM
    >>
    >> *To:* jhyde (AT) pentaho (DOT) com; Mondrian developer mailing list
    >> *Subject:* Re: [Mondrian] Fwd: Re: xmla security header processing
    >>
    >> hi Julian,
    >> see below, thanks
    >> Michele
    >>
    >> <web-app>
    >> <display-name>ARC XMLA Server</display-name>
    >>
    >> <servlet>
    >> <servlet-name>xmla</servlet-name>
    >> <servlet-class>mondrian.xmla.impl.Olap4jXmlaServlet</servlet-class>
    >> <init-param>
    >>
    >> <param-name>OlapDriverUsePreConfiguredDiscoverDatasourcesResponse</param-name>
    >> <param-value>true</param-value>
    >> </init-param>
    >> <init-param>
    >> <param-name>OlapDriverDiscoverDatasources.dataSourceName</param-name>
    >> <param-value>Proxy to Mondrian Foodmart</param-value>
    >> </init-param>
    >> <init-param>
    >>
    >> <param-name>OlapDriverDiscoverDatasources.dataSourceDescription</param-name>
    >> <param-value>Just a proxy to another mondrian xmla server</param-value>
    >> </init-param>
    >> <init-param>
    >> <param-name>OlapDriverDiscoverDatasources.url</param-name>
    >> <param-value>http://192.168.151.88:6080/xmla/xmla</param-value>
    >> </init-param>
    >> <init-param>
    >> <param-name>OlapDriverDiscoverDatasources.dataSourceInfo</param-name>
    >> <param-value>Proxy to Foodmart</param-value>
    >> </init-param>
    >> <init-param>
    >> <param-name>OlapDriverDiscoverDatasources.providerName</param-name>
    >> <param-value>Proxy to mondrian xmla server</param-value>
    >> </init-param>
    >> <init-param>
    >> <param-name>OlapDriverDiscoverDatasources.providerType</param-name>
    >> <param-value>TDP</param-value>
    >> </init-param>
    >> <init-param>
    >> <param-name>OlapDriverDiscoverDatasources.authenticationMode</param-name>
    >> <param-value>Unauthenticated</param-value>
    >> </init-param>
    >>
    >> [.........]
    >>
    >> On 21 June 2011 23:26, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >>
    >>> **
    >>> I could only see a boolean parameter:
    >>>
    >>> <init-param>
    >>>
    >>> <param-name>OlapDriverUsePreConfiguredDiscoverDatasourcesResponse</param-name>
    >>> <param-value>true</param-value>
    >>> </init-param>
    >>>
    >>> Where's the XML?
    >>>
    >>> Michele wrote:
    >>>
    >>> the configuration is in the web.xml, see attached screenshot.
    >>>
    >>>

    >>

    >


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

  9. #9
    Michele Rossi Guest

    Default Re: [Mondrian] Fwd: Re: xmla security header processing

    forgot to attach the file, sorry


    Michele

    On 1 July 2011 11:34, Michele Rossi <michele.rossi (AT) gmail (DOT) com> wrote:

    > hi Julian,
    > please find attached a more recent version of my xmla-over-olap4j work.
    > I've improved the connection pool management.
    > I now use one scheduled task to run "evict" on all the active pools.
    > It's better than using the default mechanism which would use a thread per
    > pool.
    >
    > many thanks,
    > Michele
    >
    >
    > On 29 June 2011 17:51, Michele Rossi <michele.rossi (AT) gmail (DOT) com> wrote:
    >
    >> hi Julian,
    >> I've coded the connection pooling bit for the olap4j xmla servlet and I've
    >> tested it using Excel 2007.
    >>
    >> Basically I connect Excel 2007 to a local tomcat running the olap4j
    >> servlet and I configure the olap4j servlet to "talk" to another remote
    >> mondrian server using the XMLA Olap4j driver.
    >>
    >> Some of the pool parameters are configurable via the servlet
    >> configuration.
    >> You can change the "idle connections cleanup timeout" (default is 5 mins)
    >> and the max number of connections to pool per user (default is 1)
    >>
    >> I had to create a map of "BasicDataSource" connection pools as it was the
    >> only way I could find to create authenticated connections correctly.
    >>
    >> I couldn't find any other way to tell the DBCP classes to group together
    >> internally connections made for the same user.
    >>
    >> I also had to create a "Delegating Olap Connection" because you need to
    >> return something that implements "OlapConnection" and at the same time does
    >> the right thing when you call "close" (returns the connection to the pool).
    >>
    >> I had a look at creating unit tests and that seems like a fairly
    >> substantial piece of work.
    >> The existing testing classes are based on the MondrianOlap4jServlet.
    >> I guess we should try to run all xmla tests against the new olap4j servlet
    >> too.
    >>
    >> Do you have any opinion on that?
    >>
    >> thanks,
    >> Michele
    >>
    >>
    >> On 22 June 2011 19:51, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >>
    >>> **
    >>> Looks good. Please make sure there's a test for it (so we don't break it
    >>> accidentally).
    >>>
    >>> ------------------------------
    >>> *From:* Michele Rossi [mailto:michele.rossi (AT) gmail (DOT) com]
    >>> *Sent:* Wednesday, June 22, 2011 12:35 AM
    >>>
    >>> *To:* jhyde (AT) pentaho (DOT) com; Mondrian developer mailing list
    >>> *Subject:* Re: [Mondrian] Fwd: Re: xmla security header processing
    >>>
    >>> hi Julian,
    >>> see below, thanks
    >>> Michele
    >>>
    >>> <web-app>
    >>> <display-name>ARC XMLA Server</display-name>
    >>>
    >>> <servlet>
    >>> <servlet-name>xmla</servlet-name>
    >>> <servlet-class>mondrian.xmla.impl.Olap4jXmlaServlet</servlet-class>
    >>> <init-param>
    >>>
    >>> <param-name>OlapDriverUsePreConfiguredDiscoverDatasourcesResponse</param-name>
    >>> <param-value>true</param-value>
    >>> </init-param>
    >>> <init-param>
    >>> <param-name>OlapDriverDiscoverDatasources.dataSourceName</param-name>
    >>> <param-value>Proxy to Mondrian Foodmart</param-value>
    >>> </init-param>
    >>> <init-param>
    >>>
    >>> <param-name>OlapDriverDiscoverDatasources.dataSourceDescription</param-name>
    >>> <param-value>Just a proxy to another mondrian xmla server</param-value>
    >>> </init-param>
    >>> <init-param>
    >>> <param-name>OlapDriverDiscoverDatasources.url</param-name>
    >>> <param-value>http://192.168.151.88:6080/xmla/xmla</param-value>
    >>> </init-param>
    >>> <init-param>
    >>> <param-name>OlapDriverDiscoverDatasources.dataSourceInfo</param-name>
    >>> <param-value>Proxy to Foodmart</param-value>
    >>> </init-param>
    >>> <init-param>
    >>> <param-name>OlapDriverDiscoverDatasources.providerName</param-name>
    >>> <param-value>Proxy to mondrian xmla server</param-value>
    >>> </init-param>
    >>> <init-param>
    >>> <param-name>OlapDriverDiscoverDatasources.providerType</param-name>
    >>> <param-value>TDP</param-value>
    >>> </init-param>
    >>> <init-param>
    >>> <param-name>OlapDriverDiscoverDatasources.authenticationMode</param-name>
    >>> <param-value>Unauthenticated</param-value>
    >>> </init-param>
    >>>
    >>> [.........]
    >>>
    >>> On 21 June 2011 23:26, Julian Hyde <jhyde (AT) pentaho (DOT) com> wrote:
    >>>
    >>>> **
    >>>> I could only see a boolean parameter:
    >>>>
    >>>> <init-param>
    >>>>
    >>>> <param-name>OlapDriverUsePreConfiguredDiscoverDatasourcesResponse</param-name>
    >>>> <param-value>true</param-value>
    >>>> </init-param>
    >>>>
    >>>> Where's the XML?
    >>>>
    >>>> Michele wrote:
    >>>>
    >>>> the configuration is in the web.xml, see attached screenshot.
    >>>>
    >>>>
    >>>

    >>

    >


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

  10. #10
    van der Werf, Guy Guest

    Default [Mondrian] Dynamic roles

    Hi all,

    With reference to Jira BISERVER-4992, I would like ask a question regarding caching in Mondrian.
    Using Pentaho 3.8, I

  11. #11
    Brian Hagan Guest

    Default Re: [Mondrian] Dynamic roles

    Guy,

    Instead of extending MDXConnection, you may want to consider using the MondrianUserSessionUserRoleListMapper (pentahoObjects.spring.xml) , which allows you to change the role of an authenticated user based upon a session variable. This technique does not require you to dynamically modify the schema. However, the role, which are you assigning to the user, must be defined in the schema. The trick is then getting the variable in the session.

    Thanks,

    Brian

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of van der Werf, Guy
    Sent: Tuesday, July 05, 2011 9:31 AM
    To: Mondrian developer mailing list
    Subject: [Mondrian] Dynamic roles

    Hi all,

    With reference to Jira BISERVER-4992, I would like ask a question regarding caching in Mondrian.

    Using Pentaho 3.8, I've extended "MDXConnection" to allow setting a custom role (extends RoleImpl) that is configured depending on reference metadata held in an existing authorization data source. This works as planned, but caching is a problem, and I wondering if anyone could shed some light on possible caching strategies. I should add that I do not use a dynamic schema processor in this solution.

    I have 1 solution so far. I switch schema cache off in the catalog, and set "UseSchemaPool=false" in "DataSourceInfo" in "datasources.xml". To ensure the same cache behavior (i.e. effectively none) in schemas not in "datasources.xml", I could set this in the connection properties too (but that's not done yet). The result is: I have no useful caching and performance in dashboards is noticeably pathetic.

    So... does anyone have experience in Mondrian caching when dynamically changing the role, but not the schema xml?

    Thanks,
    Guy


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

  12. #12
    van der Werf, Guy Guest

    Default Re: [Mondrian] Dynamic roles

    Hi Brian,
    Thanks for that. If I wanted to just assign a different role *name* (as in ceo, dev etc) then this would be a possibility, but I

  13. #13
    Julian Hyde Guest

    Default Re: [Mondrian] Dynamic roles

    Guy,

    You're on the right track using RoleImpl. However, I don't know the right
    way to configure BIServer to create the right RoleImpl objects on the fly;
    MondrianUserSessionUserRoleListMapper is a mapper but you need a factory,
    and I don't know whether there is such a thing in BIServer.

    Maybe someone with more BIServer knowledge can chime in.

    My recent work with Michele Rossi to refactor the XMLA server should help.
    We are exposing SPIs so that you can convert XMLA credentials into an
    authenticated olap4j connection that applies the appropriate role, so you
    should be able to slot into that framework. But (a) it's a work in progress
    on the main line, and (b) BIServer doesn't inherit it yet (it's just for raw
    XMLA requests to a standalone mondrian instance).

    When you say "caching is stuffed", you mean that you need to create RoleImpl
    objects for each request? I just want to clarify that mondrian's cache is
    still valid for each RoleImpl, so performance should be OK unless it takes a
    lot of effort to create each RoleImpl.

    Julian


    _____

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On
    Behalf Of van der Werf, Guy
    Sent: Tuesday, July 05, 2011 7:47 AM
    To: Mondrian developer mailing list
    Subject: Re: [Mondrian] Dynamic roles



    Hi Brian,

    Thanks for that. If I wanted to just assign a different role *name* (as in
    ceo, dev etc) then this would be a possibility, but I'm creating a
    customized Mondrian role (class) which extends "RoleImpl". I reference
    metadata in a DB based on user, schema and cube, and grant/revoke access to
    cubes, dims, hierarchies and members as required. Works, but caching is
    stuffed.

    Guy



    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On
    Behalf Of Brian Hagan
    Sent: Dienstag, 5. Juli 2011 15:57
    To: Mondrian developer mailing list
    Subject: Re: [Mondrian] Dynamic roles



    Guy,



    Instead of extending MDXConnection, you may want to consider using the
    MondrianUserSessionUserRoleListMapper (pentahoObjects.spring.xml) , which
    allows you to change the role of an authenticated user based upon a session
    variable. This technique does not require you to dynamically modify the
    schema. However, the role, which are you assigning to the user, must be
    defined in the schema. The trick is then getting the variable in the
    session.



    Thanks,



    Brian



    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On
    Behalf Of van der Werf, Guy
    Sent: Tuesday, July 05, 2011 9:31 AM
    To: Mondrian developer mailing list
    Subject: [Mondrian] Dynamic roles



    Hi all,



    With reference to Jira BISERVER-4992, I would like ask a question regarding
    caching in Mondrian.



    Using Pentaho 3.8, I've extended "MDXConnection" to allow setting a custom
    role (extends RoleImpl) that is configured depending on reference metadata
    held in an existing authorization data source. This works as planned, but
    caching is a problem, and I wondering if anyone could shed some light on
    possible caching strategies. I should add that I do not use a dynamic schema
    processor in this solution.



    I have 1 solution so far. I switch schema cache off in the catalog, and set
    "UseSchemaPool=false" in "DataSourceInfo" in "datasources.xml". To ensure
    the same cache behavior (i.e. effectively none) in schemas not in
    "datasources.xml", I could set this in the connection properties too (but
    that's not done yet). The result is: I have no useful caching and
    performance in dashboards is noticeably pathetic.



    So. does anyone have experience in Mondrian caching when dynamically
    changing the role, but not the schema xml?



    Thanks,

    Guy




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

  14. #14
    Gretchen Moran Guest

    Default Re: [Mondrian] Dynamic roles

    Hi Guy,

    Can you give any details on exactly what functionality in the role you are changing/extending (method overrides specifically)? We have implemented several versions of dynamic roles (specifically generating the grants/denies) with no caching issues, but the implementation has many nuances we've learned over time. We have descended both RoleImpl and the DelegatingRole with success.

    Gretchen Moran

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of van der Werf, Guy
    Sent: Tuesday, July 05, 2011 10:47 AM
    To: Mondrian developer mailing list
    Subject: Re: [Mondrian] Dynamic roles

    Hi Brian,
    Thanks for that. If I wanted to just assign a different role *name* (as in ceo, dev etc) then this would be a possibility, but I'm creating a customized Mondrian role (class) which extends "RoleImpl". I reference metadata in a DB based on user, schema and cube, and grant/revoke access to cubes, dims, hierarchies and members as required. Works, but caching is stuffed.
    Guy

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of Brian Hagan
    Sent: Dienstag, 5. Juli 2011 15:57
    To: Mondrian developer mailing list
    Subject: Re: [Mondrian] Dynamic roles

    Guy,

    Instead of extending MDXConnection, you may want to consider using the MondrianUserSessionUserRoleListMapper (pentahoObjects.spring.xml) , which allows you to change the role of an authenticated user based upon a session variable. This technique does not require you to dynamically modify the schema. However, the role, which are you assigning to the user, must be defined in the schema. The trick is then getting the variable in the session.

    Thanks,

    Brian

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of van der Werf, Guy
    Sent: Tuesday, July 05, 2011 9:31 AM
    To: Mondrian developer mailing list
    Subject: [Mondrian] Dynamic roles

    Hi all,

    With reference to Jira BISERVER-4992, I would like ask a question regarding caching in Mondrian.

    Using Pentaho 3.8, I've extended "MDXConnection" to allow setting a custom role (extends RoleImpl) that is configured depending on reference metadata held in an existing authorization data source. This works as planned, but caching is a problem, and I wondering if anyone could shed some light on possible caching strategies. I should add that I do not use a dynamic schema processor in this solution.

    I have 1 solution so far. I switch schema cache off in the catalog, and set "UseSchemaPool=false" in "DataSourceInfo" in "datasources.xml". To ensure the same cache behavior (i.e. effectively none) in schemas not in "datasources.xml", I could set this in the connection properties too (but that's not done yet). The result is: I have no useful caching and performance in dashboards is noticeably pathetic.

    So... does anyone have experience in Mondrian caching when dynamically changing the role, but not the schema xml?

    Thanks,
    Guy


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

  15. #15
    van der Werf, Guy Guest

    Default Re: [Mondrian] Dynamic roles

    Hi Gretchen,

    Important lines are:
    *************
    public class WirecardMdxConnection extends MDXConnection
    protected void init(PropertyList properties) {
    super.init(properties);
    this.session = PentahoSessionHolder.getSession();
    Authentication auth = SecurityHelper.getAuthentication(this.session, false);
    GrantedAuthority[] platformRoles = auth.getAuthorities();
    Connection connection = this.getConnection();
    Role wr = new WirecardRole(connection.getSchema(), this.datasourceService, this.session);
    connection.setRole(wr);
    setRole(wr);

    public class WirecardRole extends RoleImpl {
    public WirecardRole(Schema schema, IDatasourceService datasourceService, IPentahoSession session) {
    super();
    Cube[] cubes = schema.getCubes();
    Dimension[] dimensions = cube.getDimensions();
    Hierarchy[] hierarchies = dimension.getHierarchies();
    Level[] levels = hierarchy.getLevels();
    *************
    The last 4 lines above checks each cube, dim, hierarchy and level-members for authorization based on (cached) metadata from a DB. Appropriate calls to

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of Gretchen Moran
    Sent: Dienstag, 5. Juli 2011 19:51
    To: Mondrian developer mailing list
    Subject: Re: [Mondrian] Dynamic roles

    Hi Guy,

    Can you give any details on exactly what functionality in the role you are changing/extending (method overrides specifically)? We have implemented several versions of dynamic roles (specifically generating the grants/denies) with no caching issues, but the implementation has many nuances we

  16. #16
    van der Werf, Guy Guest

    Default Re: [Mondrian] Dynamic roles

    Hi Julian,

    Thanks for confirming my direction. I definitely need a factory on this one.. Furthermore, we

  17. #17
    van der Werf, Guy Guest

    Default Re: [Mondrian] Dynamic roles


  18. #18
    Gretchen Moran Guest

    Default Re: [Mondrian] Dynamic roles

    Hi Guy,

    What you are trying to do at a glance seems very straight forward, and has been successfully implemented. Let me clarify some areas in the solution to possibly help root out your problem.

    If you are using the Pentaho BI Server's standard mechanism for serving up MDXConnections, the code you have should successfully set your custom role on the connection. The BI Server does not reuse these instances, so the grants you set are thus "clean" with each new connection, and you should not have to worry about resetting the role grants on the connection. However, if you are custom writing the code to ask for an MDXConnection instance, you may want to mimic what the BI Server does - use the connection to issue a query, then discard it. There is a class called the PentahoConnectionFactory to accomodate this use.

    I see nothing inherently wrong in the description of the logic in your constructor. The line of code that you single out, however, may cause you grief - if you want to define a constraint (a grant or deny) on any members under a hierarchy, you must set that hierarchy's access to CUSTOM. So unless you intended to restrict all access to the hierarchy and all of its members, the grant(hierarchy, Access.NONE, null, null, null) will be a problem. In either case, the fact that you are passing a NULL rollupPolicy (the last argument in the grant) may be hazardous - if you look a the original RoleImpl code, there is an assert that rollupPolicy != null. You can easily set that value using a constant value from the RollupPolicy enum:

    enum RollupPolicy {
    /**
    * The value of the cell is null if any of the children are
    * inaccessible.
    */
    HIDDEN,

    /**
    * The value of the cell is obtained by rolling up the values of
    * accessible children.
    */
    PARTIAL,

    /**
    * The value of the cell is obtained by rolling up the values of all
    * children.
    */
    FULL,
    }

    Sadly, none of my observations directly correlate to your assertion that an unrestricted user remains restricted after a restricted user has issued a query. Am I correct to assume that these users are two different Pentaho BI Server authenticated sessions? What are the results if you access the cube with the unrestricted user first? I am very skeptical that the cache is your culprit, because the role grants operate one level above the cache, and modify the actual query that gets issued. My advice is to continue to examine the logic in your constructor for the root of the problem.

    Some other obvious checks that I make when I am working with this kind of customization:


    1. The metadata related to the authenticated user is what I believe it should be - for me, this usually means interrogating and verifying a set of session variables - yours may be to verify you are getting the proper metadata that you are expecting from your DB.

    2. Double check the rules and ordering that govern member grants in a Mondrian role.. they are listed in the Mondrian documentation. The ordering of grants can be tricky, and has caused me problems. Many times I have statically defined what I thought were the appropriate grants, only to find out that what I was asking for in my grants did not resolve to what I would have expected.

    And the very last option, I have a simple, simple reference example of this implementation if you cannot get it sorted out. It uses the Pentaho sample data and Steel Wheels schema to demonstrate the approach you describe here.. Let me know if that may be of any value to you, and I will get it to you.

    Hope something here helps,
    Gretchen Moran

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of van der Werf, Guy
    Sent: Wednesday, July 06, 2011 4:24 AM
    To: Mondrian developer mailing list
    Subject: Re: [Mondrian] Dynamic roles

    .... Sorry - it helps if one clicks "paste" instead of "send"
    I completed my email below.
    Thanks
    Guy

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of van der Werf, Guy
    Sent: Mittwoch, 6. Juli 2011 10:01
    To: Mondrian developer mailing list
    Subject: Re: [Mondrian] Dynamic roles

    Hi Gretchen,

    Important lines are:
    *************
    public class WirecardMdxConnection extends MDXConnection
    protected void init(PropertyList properties) {
    super.init(properties);
    this.session = PentahoSessionHolder.getSession();
    Authentication auth = SecurityHelper.getAuthentication(this.session, false);
    GrantedAuthority[] platformRoles = auth.getAuthorities();
    Connection connection = this.getConnection();
    Role wr = new WirecardRole(connection.getSchema(), this.datasourceService, this.session);
    connection.setRole(wr);
    setRole(wr);

    public class WirecardRole extends RoleImpl {
    public WirecardRole(Schema schema, IDatasourceService datasourceService, IPentahoSession session) {
    super();
    Cube[] cubes = schema.getCubes();
    Dimension[] dimensions = cube.getDimensions();
    Hierarchy[] hierarchies = dimension.getHierarchies();
    Level[] levels = hierarchy.getLevels();
    *************
    The last 4 lines above check each cube, dim, hierarchy and level-members for authorization based on (cached) metadata from a DB. I make appropriate calls to:
    grant(<cube|dim|hierarchy|level-members>, Access.NONE) OR grant(<cube|dim|hierarchy|level-members>, Access.ALL)

    Only the constructor is overridden. I do not clone existing roles, and mine are mutable. I'm happy with all business logic.
    Only 1 statement gives me concern as to whether the implementation is correct: grant(hierarchy, Access.NONE, null, null, null); Confirm that too if you can please.

    Your time on this is appreciated.
    Thanks,
    Guy

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of Gretchen Moran
    Sent: Dienstag, 5. Juli 2011 19:51
    To: Mondrian developer mailing list
    Subject: Re: [Mondrian] Dynamic roles

    Hi Guy,

    Can you give any details on exactly what functionality in the role you are changing/extending (method overrides specifically)? We have implemented several versions of dynamic roles (specifically generating the grants/denies) with no caching issues, but the implementation has many nuances we've learned over time. We have descended both RoleImpl and the DelegatingRole with success.

    Gretchen Moran
    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of van der Werf, Guy
    Sent: Tuesday, July 05, 2011 10:47 AM
    To: Mondrian developer mailing list
    Subject: Re: [Mondrian] Dynamic roles

    Hi Brian,
    Thanks for that. If I wanted to just assign a different role *name* (as in ceo, dev etc) then this would be a possibility, but I'm creating a customized Mondrian role (class) which extends "RoleImpl". I reference metadata in a DB based on user, schema and cube, and grant/revoke access to cubes, dims, hierarchies and members as required. Works, but caching is stuffed.
    Guy

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of Brian Hagan
    Sent: Dienstag, 5. Juli 2011 15:57
    To: Mondrian developer mailing list
    Subject: Re: [Mondrian] Dynamic roles

    Guy,

    Instead of extending MDXConnection, you may want to consider using the MondrianUserSessionUserRoleListMapper (pentahoObjects.spring.xml) , which allows you to change the role of an authenticated user based upon a session variable. This technique does not require you to dynamically modify the schema. However, the role, which are you assigning to the user, must be defined in the schema. The trick is then getting the variable in the session.

    Thanks,

    Brian

    From: mondrian-bounces (AT) pentaho (DOT) org [mailto:mondrian-bounces (AT) pentaho (DOT) org] On Behalf Of van der Werf, Guy
    Sent: Tuesday, July 05, 2011 9:31 AM
    To: Mondrian developer mailing list
    Subject: [Mondrian] Dynamic roles

    Hi all,

    With reference to Jira BISERVER-4992, I would like ask a question regarding caching in Mondrian.

    Using Pentaho 3.8, I've extended "MDXConnection" to allow setting a custom role (extends RoleImpl) that is configured depending on reference metadata held in an existing authorization data source. This works as planned, but caching is a problem, and I wondering if anyone could shed some light on possible caching strategies. I should add that I do not use a dynamic schema processor in this solution.

    I have 1 solution so far. I switch schema cache off in the catalog, and set "UseSchemaPool=false" in "DataSourceInfo" in "datasources.xml". To ensure the same cache behavior (i.e. effectively none) in schemas not in "datasources.xml", I could set this in the connection properties too (but that's not done yet). The result is: I have no useful caching and performance in dashboards is noticeably pathetic.

    So... does anyone have experience in Mondrian caching when dynamically changing the role, but not the schema xml?

    Thanks,
    Guy


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

  19. #19
    van der Werf, Guy Guest

    Default Re: [Mondrian] Dynamic roles

    Hi Gretchen,

    I can confirm I use the standard mechanism for serving MDXConnections, so roles are created clean each time. BTW I debug in Eclipse/Tomcat, and for a first-time Java coder, the incite into Pentaho

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.