<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 9.00.8112.16430"></HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=295043918-21062011><FONT color=#000080 size=2 
face="Lucida Sans">Looks good; but where do you configure that actual XML that 
DiscoverDatasources will return? Could that XML go in web.xml 
also?</FONT></SPAN></DIV>
<DIV><SPAN class=295043918-21062011><FONT color=#000080 size=2 
face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=295043918-21062011><FONT color=#000080 size=2 
face="Lucida Sans">(For the other devs on the list, some context. The problem is 
with an XMLA&nbsp;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.)</FONT></SPAN></DIV><BR>
<BLOCKQUOTE 
style="BORDER-LEFT: #000080 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px" 
dir=ltr>
  <DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
  <HR tabIndex=-1>
  <FONT size=2 face=Tahoma><B>From:</B> mondrian-bounces@pentaho.org 
  [mailto:mondrian-bounces@pentaho.org] <B>On Behalf Of </B>Michele 
  Rossi<BR><B>Sent:</B> Tuesday, June 21, 2011 10:29 AM<BR><B>To:</B> Mondrian 
  developer mailing list<BR><B>Subject:</B> [Mondrian] Fwd: Re: xmla security 
  header processing<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><BR><BR>Sent from my iPhone</DIV>
  <DIV><BR>Begin forwarded message:<BR><BR></DIV>
  <BLOCKQUOTE type="cite">
    <DIV><B>From:</B> "Julian Hyde" &lt;<A 
    href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</A>&gt;<BR><B>Date:</B> 21 
    June 2011 19:23:53 CEST<BR><B>To:</B> "'Michele Rossi'" &lt;<A 
    href="mailto:michele.rossi@gmail.com">michele.rossi@gmail.com</A>&gt;<BR><B>Subject:</B> 
    <B>RE: [Mondrian] Re: xmla security header 
    processing</B><BR><B>Reply-To:</B> &lt;<A 
    href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</A>&gt;<BR><BR></DIV></BLOCKQUOTE>
  <DIV><SPAN></SPAN></DIV>
  <BLOCKQUOTE type="cite">
    <DIV>
    <DIV><SPAN class=670472317-21062011><FONT color=#000080 size=2 
    face="Lucida Sans">again, to devs list please.</FONT></SPAN></DIV><BR>
    <BLOCKQUOTE 
    style="BORDER-LEFT: #000080 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px" 
    dir=ltr>
      <DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
      <HR tabIndex=-1>
      <FONT size=2 face=Tahoma><B>From:</B> Michele Rossi 
      [mailto:michele.rossi@gmail.com] <BR><B>Sent:</B> Tuesday, June 21, 2011 
      8:52 AM<BR><B>To:</B> <A href="mailto:jhyde@pentaho.com"><A 
      href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</A></A><BR><B>Subject:</B> 
      Re: [Mondrian] Re: xmla security header processing<BR></FONT><BR></DIV>
      <DIV></DIV>hi Julian, 
      <DIV>I've implemented the first easy bit so that we can test whether the 
      packChange process works.</DIV>
      <DIV>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.</DIV>
      <DIV><BR></DIV>
      <DIV>Could you please let me know if this change is ok and if you can read 
      my packed change?</DIV>
      <DIV><BR></DIV>
      <DIV>Tomorrow I will start the more complex bit - the use of commons-dbcp 
      to pool the OlapConnections.</DIV>
      <DIV><BR></DIV>
      <DIV><BR></DIV>
      <DIV>thanks,</DIV>
      <DIV>Michele</DIV>
      <DIV><BR><IMG title=web_xml_xmla.png alt=web_xml_xmla.png 
      src="cid:295043918@21062011-155F"><BR>
      <DIV class=gmail_quote>On 20 June 2011 21:29, Julian Hyde <SPAN 
      dir=ltr>&lt;<A href="mailto:jhyde@pentaho.com"><A 
      href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</A></A>&gt;</SPAN> 
      wrote:<BR>
      <BLOCKQUOTE 
      style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
      class=gmail_quote><U></U>
        <DIV>
        <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">The two should 
        be equivalent. Let's go with the 'unpackChange' approach since it seems 
        to be working.</FONT></SPAN></DIV>
        <DIV><SPAN><FONT color=#000080 size=2 
        face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
        <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">The only 
        problem is with NonEmptyTest.java. It refused to overwrite a writable 
        file -- which&nbsp;is sensible if you think about 
it.</FONT></SPAN></DIV>
        <DIV><SPAN><FONT color=#000080 size=2 
        face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
        <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">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.</FONT>&nbsp;</SPAN></DIV>
        <DIV><SPAN><FONT color=#000080 size=2 
        face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
        <DIV><SPAN><FONT color=#000080 size=2 
        face="Lucida Sans">Julian</FONT></SPAN></DIV><BR>
        <BLOCKQUOTE 
        style="BORDER-LEFT: #000080 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px" 
        dir=ltr>
          <DIV dir=ltr lang=en-us align=left>
          <HR>
          <FONT size=2 face=Tahoma>
          <DIV class=im><B>From:</B> Michele Rossi [mailto:<A 
          href="mailto:michele.rossi@gmail.com" target=_blank><A 
          href="mailto:michele.rossi@gmail.com">michele.rossi@gmail.com</A></A>] 
          <BR></DIV><B>Sent:</B> Monday, June 20, 2011 8:33 AM<BR><B>To:</B> <A 
          href="mailto:jhyde@pentaho.com" target=_blank><A 
          href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</A></A> 
          <DIV>
          <DIV></DIV>
          <DIV class=h5><BR><B>Subject:</B> Re: [Mondrian] Re: xmla security 
          header processing<BR></DIV></DIV></FONT><BR></DIV>
          <DIV>
          <DIV></DIV>
          <DIV class=h5>
          <DIV></DIV>hi Julian, 
          <DIV>I've been able to apply the packed change but the patching 
          continues to be elusive.</DIV>
          <DIV>The two approaches are equivalent right?</DIV>
          <DIV><BR></DIV>
          <DIV>I've included the output of the "unpackChange" and "patch" 
          commands.</DIV>
          <DIV><BR></DIV>
          <DIV>Thanks!</DIV>
          <DIV>Michele</DIV>
          <DIV><BR></DIV>
          <DIV>
          <DIV>mrossi@PI-mrossi-L-1 
          /cygdrive/c/Work/thirdparty/mondrian_perforce/open/mondrian</DIV>
          <DIV>$ unpackChange -c 14233 
          ../../../mondrian_scripts/patches_and_packed_changes/changelist14233.tar.gz</DIV>
          <DIV>File(s) not opened on this client.</DIV>
          <DIV>//open/mondrian/src/main/mondrian/tui/XmlaSupport.java#27 - 
          file(s) up-to-date.</DIV>
          <DIV>Change 14233 belongs to client jhyde.marmite2.</DIV>
          <DIV>//open/mondrian/src/main/mondrian/xmla/RowsetDefinition.java#81 - 
          file(s) up-to-date.</DIV>
          <DIV>Change 14233 belongs to client jhyde.marmite2.</DIV>
          <DIV>//open/mondrian/src/main/mondrian/xmla/XmlaConstants.java#13 - 
          file(s) up-to-date.</DIV>
          <DIV>Change 14233 belongs to client jhyde.marmite2.</DIV>
          <DIV>//open/mondrian/src/main/mondrian/xmla/XmlaHandler.java#76 - 
          file(s) up-to-date.</DIV>
          <DIV>Change 14233 belongs to client jhyde.marmite2.</DIV>
          <DIV>//open/mondrian/src/main/mondrian/xmla/XmlaRequest.java#11 - 
          file(s) up-to-date.</DIV>
          <DIV>Change 14233 belongs to client jhyde.marmite2.</DIV>
          <DIV>//open/mondrian/src/main/mondrian/xmla/XmlaServlet.java#40 - 
          file(s) up-to-date.</DIV>
          <DIV>Change 14233 belongs to client jhyde.marmite2.</DIV>
          <DIV>//open/mondrian/src/main/mondrian/xmla/XmlaUtil.java#31 - file(s) 
          up-to-date.</DIV>
          <DIV>Change 14233 belongs to client jhyde.marmite2.</DIV>
          <DIV>//open/mondrian/src/main/mondrian/xmla/impl/DefaultSaxWriter.java#12 
          - file(s) up-to-date.</DIV>
          <DIV>Change 14233 belongs to client jhyde.marmite2.</DIV>
          <DIV>//open/mondrian/src/main/mondrian/xmla/impl/DefaultXmlaRequest.java#19 
          - file(s) up-to-date.</DIV>
          <DIV>Change 14233 belongs to client jhyde.marmite2.</DIV>
          <DIV>//open/mondrian/src/main/mondrian/xmla/impl/DefaultXmlaServlet.java#30 
          - file(s) up-to-date.</DIV>
          <DIV>Change 14233 belongs to client jhyde.marmite2.</DIV>
          <DIV>//open/mondrian/testsrc/main/mondrian/rolap/NonEmptyTest.java#145 
          - updating 
          C:\Work\thirdparty\mondrian_perforce\open\mondrian\test</DIV>
          <DIV>src\main\mondrian\rolap\NonEmptyTest.java</DIV>
          <DIV>Can't clobber writable file 
          C:\Work\thirdparty\mondrian_perforce\open\mondrian\testsrc\main\mondrian\rolap\NonEmptyTest.java</DIV>
          <DIV>Change 14233 belongs to client jhyde.marmite2.</DIV>
          <DIV>//open/mondrian/testsrc/main/mondrian/xmla/test/XmlaTest.java#23 
          - file(s) up-to-date.</DIV>
          <DIV>Change 14233 belongs to client jhyde.marmite2.</DIV>
          <DIV>New change number is 14233</DIV>
          <DIV><BR></DIV>
          <DIV><BR></DIV>
          <DIV><BR></DIV>
          <DIV><BR></DIV>
          <DIV>mrossi@PI-mrossi-L-1 
          /cygdrive/c/Work/thirdparty/mondrian_perforce/open/mondrian</DIV>
          <DIV>$ patch -p l &lt; 
          ../../../mondrian_scripts/patches_and_packed_changes/jhyde2.patch</DIV>
          <DIV>patch: **** strip count l is not a number</DIV>
          <DIV><BR></DIV>
          <DIV>mrossi@PI-mrossi-L-1 
          /cygdrive/c/Work/thirdparty/mondrian_perforce/open/mondrian</DIV>
          <DIV>$<B> patch -p 1 &lt; 
          ../../../mondrian_scripts/patches_and_packed_changes/jhyde2.patch</B></DIV>
          <DIV>patching file src/main/mondrian/tui/XmlaSupport.java</DIV>
          <DIV>Reversed (or previously applied) patch detected! &nbsp;Assume -R? 
          [n] Y</DIV>
          <DIV>Apply anyway? [n] Y</DIV>
          <DIV>Skipping patch.</DIV>
          <DIV>1 out of 1 hunk ignored -- saving rejects to file 
          src/main/mondrian/tui/XmlaSupport.java.rej</DIV>
          <DIV>patching file src/main/mondrian/xmla/RowsetDefinition.java</DIV>
          <DIV>Reversed (or previously applied) patch detected! &nbsp;Assume -R? 
          [n]</DIV>
          <DIV>Apply anyway? [n] y</DIV>
          <DIV>Hunk #1 FAILED at 1.</DIV>
          <DIV>Hunk #2 FAILED at 41.</DIV>
          <DIV>Hunk #3 succeeded at 6436 with fuzz 2 (offset 12 lines).</DIV>
          <DIV>2 out of 3 hunks <B>FAILED </B>-- saving rejects to file 
          src/main/mondrian/xmla/RowsetDefinition.java.rej</DIV>
          <DIV>patching file src/main/mondrian/xmla/XmlaConstants.java</DIV>
          <DIV>Reversed (or previously applied) patch detected! &nbsp;Assume -R? 
          [n] Y</DIV>
          <DIV>Apply anyway? [n] y</DIV>
          <DIV>Hunk #1 succeeded at 9 with fuzz 2 (offset -38 lines).</DIV>
          <DIV>Hunk #2 FAILED at 26.</DIV>
          <DIV>1 out of 2 hunks FAILED -- saving rejects to file 
          src/main/mondrian/xmla/XmlaConstants.java.rej</DIV>
          <DIV>patching file src/main/mondrian/xmla/XmlaHandler.java</DIV>
          <DIV>Reversed (or previously applied) patch detected! &nbsp;Assume -R? 
          [n]</DIV></DIV>
          <DIV><BR></DIV>
          <DIV><BR><BR>
          <DIV class=gmail_quote>On 16 June 2011 23:11, Julian Hyde <SPAN 
          dir=ltr>&lt;<A href="mailto:jhyde@pentaho.com" target=_blank><A 
          href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</A></A>&gt;</SPAN> 
          wrote:<BR>
          <BLOCKQUOTE 
          style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
          class=gmail_quote><U></U>
            <DIV>
            <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">Two options 
            for the patch file:</FONT></SPAN></DIV>
            <DIV><SPAN><FONT color=#000080 size=2 
            face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
            <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">1. The 
            patch file was the wrong format. I fixed it. See attached. Apply it 
            using 'patch -p 1 &lt; jhyde2.patch'.</FONT></SPAN></DIV>
            <DIV><SPAN><FONT color=#000080 size=2 
            face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
            <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">For this 
            you will need to install cygwin, including the patch 
            command.</FONT></SPAN></DIV>
            <DIV><SPAN><FONT color=#000080 size=2 
            face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
            <DIV><SPAN><FONT color=#000080 size=2 
            face="Lucida Sans">OR...</FONT></SPAN></DIV>
            <DIV><SPAN><FONT color=#000080 size=2 
            face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
            <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">2. I have 
            also attached a file generated by packChange. See attached. Apply 
            using 'unpackChange changelist14233.tar.gz'.</FONT></SPAN></DIV>
            <DIV><SPAN><FONT color=#000080 size=2 
            face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
            <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">For this 
            you will need to install cygwin, plus the packChange and 
            unpackChange scripts from <A 
            href="http://p4webhost.eigenbase.org:8080/open/util/bin/" 
            target=_blank><FONT size=3 
            face="Times New Roman">http://p4webhost.eigenbase.org:8080/open/util/bin/</FONT></A>. 
            Put them somewhere on cygwin's path, e.g. /usr/local/bin, and give 
            them execute access 'chmod 755 ...'.</FONT></SPAN></DIV>
            <DIV><SPAN><FONT color=#000080 size=2 
            face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
            <DIV><FONT face="Lucida Sans"><FONT size=2><FONT 
            color=#000080><SPAN>To check out files for edit, use the user 
            </SPAN>'<SPAN>considerate_guest'. The password&nbsp;is 
            'consider8'.</SPAN></FONT></FONT></FONT></DIV>
            <DIV><SPAN><FONT color=#000080 size=2 
            face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
            <DIV><SPAN><FONT color=#000080 size=2 
            face="Lucida Sans">Julian</FONT></SPAN></DIV>
            <DIV><SPAN><FONT color=#000080 size=2 
            face="Lucida Sans"></FONT></SPAN><SPAN><FONT color=#000080 size=2 
            face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
            <DIV><SPAN><FONT color=#000080 size=2 
            face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV><BR>
            <BLOCKQUOTE 
            style="BORDER-LEFT: #000080 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px" 
            dir=ltr>
              <DIV dir=ltr lang=en-us align=left>
              <HR>
              <FONT size=2 face=Tahoma>
              <DIV><B>From:</B> Michele Rossi [mailto:<A 
              href="mailto:michele.rossi@gmail.com" target=_blank><A 
              href="mailto:michele.rossi@gmail.com">michele.rossi@gmail.com</A></A>] 
              <BR></DIV><B>Sent:</B> Wednesday, June 15, 2011 6:47 AM 
              <DIV><BR><B>To:</B> <A href="mailto:jhyde@pentaho.com" 
              target=_blank><A 
              href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</A></A>; 
              Mondrian developer mailing list<BR></DIV>
              <DIV><B>Subject:</B> Re: [Mondrian] Re: xmla security header 
              processing<BR></DIV></FONT><BR></DIV>
              <DIV>
              <DIV></DIV>
              <DIV>
              <DIV></DIV>hi Julian, 
              <DIV>sorry for the long delay, I've only just started working on 
              this task again.</DIV>
              <DIV><BR></DIV>
              <DIV>I have been trying to apply your patch but unfortunately I 
              get an error message, "Invalid patch file".</DIV>
              <DIV>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).</DIV>
              <DIV><BR></DIV>
              <DIV>Could we consider switching to "perforce shelving" instead of 
              patches?</DIV>
              <DIV>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.</DIV>
              <DIV>Then you could decide what things you want to merge back to 
              the main branch.</DIV>
              <DIV>It's just an idea..&nbsp;I am obviously not too good with 
              patch files.</DIV>
              <DIV><BR></DIV>
              <DIV>Back to the XMLA servlet:</DIV>
              <DIV><BR></DIV>
              <DIV>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.</DIV>
              <DIV>If it's something that you don't want could we think about 
              allowing the injection of different OlapConnectionFactory 
              implementations?</DIV>
              <DIV>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.</DIV>
              <DIV><BR></DIV>
              <DIV>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</DIV>
              <DIV><BR></DIV>
              <DIV>3. We have a problem with the first request that SimbaO2X 
              sends without authentication.</DIV>
              <DIV>The request is "Discover Datasources".</DIV>
              <DIV>Are you happy if I allow users to provide their own 
              hard-coded response to such request?</DIV>
              <DIV>It could go in the web.xml.</DIV>
              <DIV>When such configuration is not hard coded the system would 
              behave as now and would try to obtain it from a OlapConnection 
              object.</DIV>
              <DIV><BR></DIV>
              <DIV><BR></DIV>
              <DIV>many thanks,</DIV>
              <DIV>Michele</DIV>
              <DIV><BR></DIV>
              <DIV><BR><BR>
              <DIV class=gmail_quote>On 26 May 2011 15:49, Michele Rossi <SPAN 
              dir=ltr>&lt;<A href="mailto:michele.rossi@gmail.com" 
              target=_blank><A 
              href="mailto:michele.rossi@gmail.com">michele.rossi@gmail.com</A></A>&gt;</SPAN> 
              wrote:<BR>
              <BLOCKQUOTE 
              style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
              class=gmail_quote>hi Julian, 
                <DIV>I've replied to some of your questions inline.</DIV>
                <DIV><BR></DIV>
                <DIV>thanks,</DIV>
                <DIV>Michele<BR><BR>
                <DIV class=gmail_quote>
                <DIV>On 25 May 2011 00:43, Julian Hyde <SPAN dir=ltr>&lt;<A 
                href="mailto:jhyde@pentaho.com" target=_blank><A 
                href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</A></A>&gt;</SPAN> 
                wrote:<BR>
                <BLOCKQUOTE 
                style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
                class=gmail_quote>
                  <DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 
                  face="Lucida Sans">Michele,</FONT></SPAN></DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">As 
                  promised, I've reviewed your changes. </FONT></SPAN></DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">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 &amp; password are now present in the API, and the 
                  result is so confusing it's difficult to say that there are 
                  not security holes.</FONT></SPAN></DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">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.</FONT></SPAN></DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 
                  face="Lucida Sans">Detailed comments...</FONT></SPAN></DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT></SPAN>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">0. 
                  Would it be simpler if the servlet looked for the 
                  &lt;Security&gt; tag and session information and copied these 
                  into the HTTP headers? Then we could use HTTP athentication 
                  and session lifecycle management. Just an 
                  idea.</FONT></SPAN></DIV></DIV></BLOCKQUOTE>
                <DIV><BR></DIV></DIV>
                <DIV>My main problem is to create an authenticated 
                OlapConnection.</DIV>
                <DIV>Hence I need the credentials to be processed in the code 
                that creates the connection and not by the container.</DIV>
                <DIV>
                <DIV>&nbsp;</DIV>
                <BLOCKQUOTE 
                style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
                class=gmail_quote>
                  <DIV>
                  <DIV><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">1. 
                  MondrianServerImpl.getConnection is not used. Removed 
                  it.</FONT></SPAN></DIV>
                  <DIV><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">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.</FONT></SPAN></DIV>
                  <DIV><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">So, I 
                  removed ConnectionHolder and the "connections" 
                  member.</FONT></SPAN></DIV></DIV></BLOCKQUOTE>
                <DIV><BR></DIV></DIV>
                <DIV>The problem is that Simba will create something like 15 
                connections before you can even start configuring a Pivot in 
                Excel.&nbsp;</DIV>
                <DIV><BR></DIV>
                <DIV>In general I believe that creating a new connection for 
                each request is &nbsp;an anti-pattern as it leads to a 
                substantial waste of resources.</DIV>
                <DIV><BR></DIV>
                <DIV>In my case in particular this approach wouldn't work at all 
                as I cache the metadata objects at the connection 
                level.&nbsp;</DIV>
                <DIV>So before displaying a Pivot in Excel I'd have to populate 
                the whole metadata cache N times, once for each connection I 
                create.</DIV>
                <DIV><BR></DIV>
                <DIV>Connection pooling is the technique normally used&nbsp;by 
                more traditional web apps that require access to a 
                database&nbsp;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) .</DIV>
                <DIV><BR></DIV>
                <DIV>I am aware that my implementation didn't clean up un-used 
                connections.</DIV>
                <DIV>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.</DIV>
                <DIV>
                <DIV>&nbsp;</DIV>
                <BLOCKQUOTE 
                style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
                class=gmail_quote>
                  <DIV>
                  <DIV><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">I see 
                  why we need to save username &amp; 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).</FONT></SPAN></DIV></DIV></BLOCKQUOTE>
                <DIV><BR></DIV></DIV>
                <DIV>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.</DIV>
                <DIV>I will start thinking about this approach.</DIV>
                <DIV>
                <DIV>&nbsp;</DIV>
                <BLOCKQUOTE 
                style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
                class=gmail_quote>
                  <DIV>
                  <DIV><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">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.</FONT></SPAN></DIV>
                  <DIV><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">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<BR>'SessionInfo 
                  XmlaRequest.getSessionInfo()' method that contains all session 
                  context?</FONT></SPAN></DIV></DIV></BLOCKQUOTE>
                <DIV><BR></DIV></DIV>
                <DIV>Yes definitely - although the end result is very similar 
                this approach is probably more flexible.</DIV>
                <DIV>
                <DIV>&nbsp;</DIV>
                <BLOCKQUOTE 
                style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
                class=gmail_quote>
                  <DIV>
                  <DIV><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">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?</FONT></SPAN></DIV></DIV></BLOCKQUOTE>
                <DIV><BR></DIV></DIV>
                <DIV>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.</DIV>
                <DIV>The credentials I am interested in are provided in the SOAP 
                payload by SimbaO2X, they don't come from HTTP headers.</DIV>
                <DIV><BR></DIV>
                <DIV>Also how are clients currently specifying their "role" 
                ?</DIV>
                <DIV>What stops them from choosing anything they like as their 
                role?</DIV>
                <DIV>(I will also start doing my own research on these 
                points)</DIV>
                <DIV>
                <DIV><BR></DIV>
                <BLOCKQUOTE 
                style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
                class=gmail_quote>
                  <DIV>
                  <DIV><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">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.</FONT></SPAN></DIV></DIV></BLOCKQUOTE>
                <DIV>&nbsp;</DIV></DIV>
                <DIV>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?</DIV>
                <DIV>I will find out more about it.</DIV>
                <DIV>
                <DIV><BR></DIV>
                <BLOCKQUOTE 
                style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
                class=gmail_quote>
                  <DIV>
                  <DIV><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">5. 
                  What does your comment "we'd need to inject the 
                  HttpServletRequest into this method" 
                  mean?</FONT></SPAN></DIV></DIV></BLOCKQUOTE>
                <DIV><BR></DIV></DIV>
                <DIV>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.</DIV>
                <DIV>I need that information for licensing reasons.</DIV>
                <DIV>
                <DIV>&nbsp;</DIV>
                <BLOCKQUOTE 
                style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
                class=gmail_quote>
                  <DIV>
                  <DIV><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">6. 
                  There is a magic id for un-authenticated session. Is this a 
                  security hole?</FONT></SPAN></DIV></DIV></BLOCKQUOTE>
                <DIV><BR></DIV></DIV>
                <DIV>Unfortunately Simba fires off the very first XMLA 
                "DISCOVER" request (Discover Datasources) without providing any 
                authentication credentials.</DIV>
                <DIV>It's as if Simba expected the server side to know about its 
                data sources without opening a database connection.</DIV>
                <DIV>We could approach this problem in other ways, for example 
                by providing the list of data sources in a different way.</DIV>
                <DIV>I will think about it.</DIV>
                <DIV><BR></DIV>
                <DIV>In any case an un-authenticated connection is not a 
                security hole per-se.</DIV>
                <DIV>The behaviour depends on the particular implementation of 
                Olap4j.<BR>Some drivers might refuse to execute queries on 
                OlapConnections created without credentials.</DIV>
                <DIV>Other might not need authenticated connections at 
all.</DIV>
                <DIV>
                <DIV>&nbsp;</DIV>
                <BLOCKQUOTE 
                style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
                class=gmail_quote>
                  <DIV>
                  <DIV><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">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.)</FONT></SPAN></DIV></DIV></BLOCKQUOTE>
                <DIV>&nbsp;</DIV></DIV>
                <DIV>Again I need to go back and study &nbsp;the relation 
                between the xmla servlet and basic authentication as I don't 
                understand it yet.</DIV>
                <DIV>
                <DIV><BR></DIV>
                <BLOCKQUOTE 
                style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
                class=gmail_quote>
                  <DIV>
                  <DIV><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">8. I 
                  fixed XmlaBasicTest. Maybe other tests are broken also. Can 
                  you please ensure that the tests run clean before you 
                  re-submit.</FONT></SPAN></DIV></DIV></BLOCKQUOTE>
                <DIV><BR></DIV></DIV>
                <DIV>Will do.&nbsp;</DIV>
                <DIV>
                <BLOCKQUOTE 
                style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
                class=gmail_quote>
                  <DIV>
                  <DIV><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">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.)</FONT></SPAN></DIV></DIV></BLOCKQUOTE>
                <DIV><BR></DIV></DIV>
                <DIV>Ok maybe by Basic Authentication you mean the SOAP 
                authentication provided by Excel / Simba.</DIV>
                <DIV>I will look into it as discussed above.</DIV>
                <DIV>
                <DIV>&nbsp;</DIV>
                <BLOCKQUOTE 
                style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
                class=gmail_quote>
                  <DIV>
                  <DIV><FONT color=#000080 size=2 
                  face="Lucida Sans"></FONT>&nbsp;</DIV>
                  <DIV><SPAN><FONT color=#000080 size=2 face="Lucida Sans">10. 
                  Is the security model assuming that session ids are hard to 
                  guess?<BR></FONT></SPAN></DIV></DIV></BLOCKQUOTE>
                <DIV><BR></DIV></DIV>
                <DIV>Yes that is always expected by session IDs - you want to 
                prevent an attacker from guessing a valid ID.</DIV>
                <DIV>So I can make the session ID generation algo a bit 
                better.</DIV>
                <DIV>&nbsp;</DIV></DIV></DIV></BLOCKQUOTE></DIV><BR></DIV></DIV></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE></DIV><BR></DIV></DIV></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE></DIV><BR></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>