<html><body bgcolor="#FFFFFF"><div>hi Julian,</div><div>the configuration is in the web.xml, see attached screenshot.</div><div><br></div><div>Michele<br><br>Sent from my iPhone</div><div><br>On 21 Jun 2011, at 20:41, Julian Hyde <<a href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</a>> wrote:<br><br></div><div><span></span></div><blockquote type="cite"><div>
<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> </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 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> <a href="mailto:mondrian-bounces@pentaho.org">mondrian-bounces@pentaho.org</a>
[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" <<a href="mailto:jhyde@pentaho.com"><a href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</a></a>><br><b>Date:</b> 21
June 2011 19:23:53 CEST<br><b>To:</b> "'Michele Rossi'" <<a href="mailto:michele.rossi@gmail.com"><a href="mailto:michele.rossi@gmail.com">michele.rossi@gmail.com</a></a>><br><b>Subject:</b>
<b>RE: [Mondrian] Re: xmla security header
processing</b><br><b>Reply-To:</b> <<a href="mailto:jhyde@pentaho.com"><a href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</a></a>><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><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><web_xml_xmla.png><br>
<div class="gmail_quote">On 20 June 2011 21:29, Julian Hyde <span dir="ltr"><<a href="mailto:jhyde@pentaho.com"></a><a href="mailto:jhyde@pentaho.com"><a href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</a></a>></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> </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 is sensible if you think about
it.</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </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> </span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </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><a href="mailto:michele.rossi@gmail.com"><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><a href="mailto:jhyde@pentaho.com"><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 <
../../../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 <
../../../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! 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! 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! 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! 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"><<a href="mailto:jhyde@pentaho.com" target="_blank"></a><a href="mailto:jhyde@pentaho.com"><a href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</a></a>></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> </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 < jhyde2.patch'.</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </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> </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> </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> </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> </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 is
'consider8'.</span></font></font></font></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </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> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></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><b>From:</b> Michele Rossi [mailto:<a href="mailto:michele.rossi@gmail.com" target="_blank"></a><a href="mailto:michele.rossi@gmail.com"><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><a href="mailto:jhyde@pentaho.com"><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.. 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"><<a href="mailto:michele.rossi@gmail.com" target="_blank"></a><a href="mailto:michele.rossi@gmail.com"><a href="mailto:michele.rossi@gmail.com">michele.rossi@gmail.com</a></a>></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"><<a href="mailto:jhyde@pentaho.com" target="_blank"></a><a href="mailto:jhyde@pentaho.com"><a href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</a></a>></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> </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> </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 & 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> </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> </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> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans">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.</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> </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> </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> </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> </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. </div>
<div><br></div>
<div>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.</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. </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 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) .</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> </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> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans">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).</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> </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> </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> </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> </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> </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> </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> </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> </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> </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> </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> </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> </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> </div></div>
<div>Again I need to go back and study 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> </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. </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> </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> </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> </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> </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>
</div><div><span>_______________________________________________</span><br><span>Mondrian mailing list</span><br><span><a href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a></span><br><span><a href="http://lists.pentaho.org/mailman/listinfo/mondrian">http://lists.pentaho.org/mailman/listinfo/mondrian</a></span><br></div></blockquote></body></html>