Thanks. Some investigation and I found I had a bug in my code and the HTML case actually works now ! The session ID is being propagated through the browser, even to a new window and authentication works.
BUT ... the core question/problem still remains. I didnt describe it in my previous email because I didnt want to complicate things but I suppose now I need to :) I have a similar problem when I have to do HTTP that is not browser based ... This is what led me down the wrong track to not look for my HTML bug becuase the same problem occurs with PDF. Why ? I've set all documents to have the same permissions so I'm pretty sure its not a document security issue. My problem is actually more complex then noted. I produce both HTML and PDF. These are done with XSLT (because I'm using a FDA published XSLT stylesheet I dont want to rewrite to xquery). I send a http request via ML xquery. I run the transformation in a tomcat service (same machine) and get the HTML or PDF back and send the document to the user over the same connection as the request. The link that runs this uses "target=_new" so on IE8 it comes up as a new window, in Chrome it comes up in a new tab. THe PDF case is almost identical. I run a XSLT then a FO process on the server and produce a PDF which is sent back to the client. In the PDF case however the images are fetched by the FOP processor on the server. I have to pass in a prefix URL to the XSLT processor to construct image URLs that point to the ML server. These URLs are not authenticated hence I get no pictures in the PDF. I had originally thought this was the same problem as HTML but its not. In this case no browser is involved and the HTTP client side has never authenticated. I dont have access to the FOP code doing the HTTP request so I cant really hack it to do something special like use HTTP basic authentication. As I write this though I had an idea. Since the only issue is requests coming from the same server, maybe I could make an App server bound to 127.0.0.1 instead of 0.0.0.0 ... this would then limit access to the server itself. Alternatively I could also take advantage of the firewall to make sure that whatever port was open wasnt open to external uses. This way I could setup a app server just for image fetches and secure it without authentication. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Geert Josten Sent: Saturday, April 17, 2010 4:36 AM To: General Mark Logic Developer Discussion Subject: [MarkLogic Dev General] RE: Passing authentication information in aURL Hi David, The authentication itself shouldn't be the problem, your browser should make sure that the authentication header is preserved and passed in on each subsequent request to the same server. So, are you talking about a security issue? Security rules for binary documents aren't any different from other types of documents. You do may need additional privileges to set custom response headers, you would get an exception if these were missing.. You can use application-level authentication, check credentials all yourself, storing them in sessions and setting session id's in cookies, but that really shouldn't be necessary.. Can you give little more detail on how things are setup, which browser you are using, etc? Kind regards, Geert > drs. G.P.H. (Geert) Josten Consultant Daidalos BV Hoekeindsehof 1-4 2665 JZ Bleiswijk T +31 (0)10 850 1200 F +31 (0)10 850 1199 mailto:[email protected] http://www.daidalos.nl/ KvK 27164984 P Please consider the environment before printing this mail. De informatie - verzonden in of met dit e-mailbericht - is afkomstig van Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend. > From: [email protected] > [mailto:[email protected]] On Behalf Of > Lee, David > Sent: vrijdag 16 april 2010 20:58 > To: General Mark Logic Developer Discussion > Subject: [MarkLogic Dev General] Passing authentication > information in a URL > > Now that I've solved the "how to make app users" problem ... > (Thanks to Danny and Mike !) > > I now have a new and more exciting problem ! > > > > I have a protected app say running on > > http://host:8012/html/myapp > > > > I've setup a read-only executable user and the app works great. > > Part of the app generates an HTML document from XML. There > are image references in that document. These images reside > in the ML DB. > > Using some tricks I found on the forums I use a link like this: > > > > http://host:8012/html/common/getdbfile.xquery?uri=/SPL/2010011 > 4_fa3ed180-298a-4f9d-9d05-15182d7218bf/5c309ddf-b803-4ee1-98f6 > -81f4b21d9341-04.jpg > > > > The xquery script "getdbfile.xquery" sets the content type > based on the URI suffix and ends with a simple fn:doc($uri) > > > > All worked great until I protected my app ... Now (of course) > these calls are failing. > > > > > > My first idea is I would need to make an unprotected App > Server that only has this script and does some special > checking to make sure only images are returned (which are not > a security risk ... today). > > > > But ... I'd rather it go through the normal authentication .... > > > > Q1) Can I pass in the user/password into the URI ? Is that > supported by ML ? (like in FTP or XCC it would be > http://user:passw...@host:port ) > > Even if so though, thats a security hole because then the > user/pass is sent back as plain text in the HTML. ... yuck. > > > > Q2) Is there a way to pass in my 'logged in user' > authentication somehow as a session ID or other tag which > doesnt expose the user/pass in the clear ? > > I suppose I could write a custom app to do this, and use a > "secret encoding" , expose the app as an unprotected app and > do magic tricks to validate the request ... > > But maybe there is something in ML that does this more directly ... ? > > > > Suggestions welcome ... > > > > > > > > > > > > > > ---------------------------------------- > > David A. Lee > > Senior Principal Software Engineer > > Epocrates, Inc. > > [email protected] <mailto:[email protected]> > > 812-482-5224 > > > > _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
