Hi David, I don't think xdmp functions will help you here. You have already passed authentication when you are able to execute them. So you will have to do some authentication of your own.
The simplest I can come up with is simply store the request id as a document in some shareable location and send that along as security token. The other app server runs at app-level authentication, but will simply refuse to return anything until you pass in a token that exists as document in the shared location. About cleaning up: you write the request id just before you call the FO parser, and clean up directly after. You will have to use xdmp:eval for this, but that is not such a big issue I guess.. Kind regards, Geert > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Lee, David > Sent: zondag 18 april 2010 16:18 > To: General Mark Logic Developer Discussion > Subject: RE: [MarkLogic Dev General] RE: Passing > authenticationinformationin aURL > > Yes was thinking of this. (security token). > I was hoping to find something like the session ID that ML > would automatically know about. > Maybe its there somewhere but I havent found it. > > like this > $session_id := xdmp:get_login_session(); > > send URI to FOP > HTTP request comes to different APP server > xdmp:login_with_session_id( $session_id ) > > > Your suggestion would work, I just need to think of a way of managing > the security tokens. There's a million ways > to do it of course depending on how insane I want to get like > * only valid for a specific user > * includes hash of password > * only valid for a time range (5 minutes?) > * only valid for a particular host > ... > > For my case I can live with something very trivial, but I was > hoping (hint hint ML ...) that there was a generalized and > available mechanism to solve this problem already. It seems > like a common design issue that begs for a common solution. > > Of course this will all be moot in ML N+1 where XSLT and FOP > are builtin services ! > > > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Geert Josten > Sent: Sunday, April 18, 2010 9:34 AM > To: General Mark Logic Developer Discussion > Subject: RE: [MarkLogic Dev General] RE: Passing > authenticationinformationin aURL > > By the way, it is not uncommon to work with security tokens. > You have little influence to how the FO parser is acquiring > the images, but you should be able to pass in request parameters. > > What you would need to do here is add a security token (just > a random number would do) to some lookup that is shared with > a different app server that uses it to verify any access. You > provide the FO parser the security token as part of the uri > to the other app server that will return the image binary. > This way, direct access to the other app server is not > possible without a valid security token, nor do you need to > go through a lot of fuss to customize your parser, sending > binary back and forth through temp or else.. > > HTH, > Geert > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Lee, > > David > > Sent: zondag 18 april 2010 15:07 > > To: General Mark Logic Developer Discussion > > Subject: RE: [MarkLogic Dev General] RE: Passing authentication > > informationin aURL > > > > Thanks Geert, > > I experimented with passing the user/password through the > URL and have > > only partial success. > > In the past (other servers) I've found that user/password > in the URL > > typically only works for FTP not HTTP, but I gave ML a try. Mixed > > results. > > > > Pure Java requests fail with a 401 (unaruthorized) Robust program > > (wget) fails with a 401 then does retry with the U/P and succeeds. > > > > Another solution for the PDF Problem I thought of is to extract the > > images locally to a temp directory before calling the > tomcat service. > > This might actually be more efficient as well as it > wouldn't require > > multiple authenticated callbacks into ML from the FOP processor. > > Another idea would be to encode all the images as a single > multi-part > > POST, but I think thats getting complicated ... > > > > > > > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Geert > > Josten > > Sent: Saturday, April 17, 2010 9:24 AM > > To: General Mark Logic Developer Discussion > > Subject: RE: [MarkLogic Dev General] RE: Passing authentication > > informationin aURL > > > > Hi David, > > > > > 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. > > > > Since you can reasonably trust the FO processor to not > misuse security > > information, you might be able to use url scheme's like > > http://user:p...@localhost:nnnn/getimage.xqy. It is legal, > though most > > browsers tend to block such requests, pretending not to understand > > them, for the sake of security. > > Basic auth over HTTP isn't very secure, but this is even less. > > Sticking to localhost though, there is no reason to fear > sniffing of > > the credentials. > > > > I am not sure binding the app server to a specific ip works as you > > think. If I'm not mistaken it doesn't work as a filter, but > as a bind. > > There should be some messages about that on the ML mailinglist. You > > might also be able to apply ip-filtering from within a rewrite > > script.. > > > > 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. > > > > _______________________________________________ > > General mailing list > > [email protected] > > http://xqzone.com/mailman/listinfo/general > > _______________________________________________ > > General mailing list > > [email protected] > > http://xqzone.com/mailman/listinfo/general > > _______________________________________________ > General mailing list > [email protected] > http://xqzone.com/mailman/listinfo/general > _______________________________________________ > General mailing list > [email protected] > http://xqzone.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
