Hi Mika, You didn't say which FOP version you're using, but since you said this is for Cocoon 2.1.x I'll assume it's the original cocoon-fop block. The problem with that is the source resolver isn't passed in, so you have to use a full http://... URL for the external graphics and you're stuck with whatever HTTP Client FOP is using internally (and as you've seen, there's no easy way to configure this to log in the way any other external client request would).
With the newer "fop-ng" block, Cocoon's source resolver is passed through to FOP so you can use another pipeline as the fo:external-graphics souce (e.g. src="cocoon:/pipeline_using_resourcereader.gif") If you were running Cocoon and the wms-server in the same vhost you could maybe even use context: to access it, but I guess that's not possible in your case. But perhaps you could create a custom reader that connects through to the other host(s) and somehow does the authentication-forwarding/SSO ? Be warned - I've not tried anything like this myself, so if it doesn't work don't blame me ;-) Andy. On 15/02/2008, Lehtonen, Mika <[EMAIL PROTECTED]> wrote: > Hi Joerg, > > I am afraid it's not working because Cocoon is running on the localhost > and wms-server on a virtual host which can't be accessed using localhost > or 127.0.0.1. I am planning of adding these "secure" wms-servers into > other virtual hosts which each have their own subdomain.domain.net > address. To my knowledge, it's the only reasonable way of separate > Geoservers datasets from each other so that users will have access only > for their own data. > On the other hand I need Cocoon for document production and that > instance can be common. As far as I know, there is no point of deploying > multiple Cocoon on the same host. It just doesn't work. > So this seems to be much of a TomCat issue. But I don't know is that > user:[EMAIL PROTECTED] approach so bad after all. I just have to make > sure that nobody can't access that xsl. Security level demand in this > application is quite low. > > cheers > mika > > Joerg Heinicke kirjoitti: > > > If I understand it correctly you have two independent web applications > > in the same Tomcat instance. Couldn't you stay "inside" the secure > > area so that you don't need to authenticate from Cocoon when accessing > > the WMS server? I think you can check if the accessed URL was > > localhost or 127.0.0.1. > > > > Joerg > > > > On 14.02.2008 12:44, Lehtonen, Mika wrote: > >> > >> I did a quick and dirty solution: I add > >> src="http://user:[EMAIL PROTECTED]" to my fo:external-graphics > >> tag. Just for the testing. > >> > >> Any better ideas? > >> > >> Are there any way to build something to sitemap, which would do the > >> trick? The user has just logged into the GeoServer so there must be > >> some way to forward authentication info into cocoon and pass it back > >> to Geoserver. Sounds stupid. Am I doing this too complicated? > >> > >> reg. mika > >> > >> > >> Lehtonen, Mika kirjoitti: > >>> Hi, > >>> > >>> Cocoon 2.1.11 / TomCat 6.0.14 > >>> > >>> Cocoon is running in "main" host and wms-server (GeoServer) in > >>> another virtual host. Cocoon gets rasterdata from wms and renders it > >>> into pdf. So there is fo:external-graphics tag in the xsl, which has > >>> a wms-request as a src attribute. > >>> > >>> Everything works fine until I add authentication (openLDAP + JNDI) > >>> into wms-server. Cocoon can't get the data anymore, because it can't > >>> authenticate itself. > >>> > >>> Have anybody any idea how to solve this? It might be as much a > >>> TomCat issue, but I believe there are lots of TomCat experts round > >>> here too. I tried SingleSignOn valve in Tomcat but I guess it works > >>> only among the applications under same virtual host. > >>> > >>> - mika - -- http://pseudoq.sourceforge.net/ Open source java Sudoku application --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
