Thanks Andy,
for your suggestion. Hard to say, will this solve the authentication
problem, but anyway your message included valuable information for me.
Actually while writing my question, I used original FOP, but thanks to
Kai Mütz, I am now succesfully using fop-ng. I have all my xsls'
configured with some "host-variable" in order to avoid writing the whole
path onto the all src-definitions on the fo:external-graphics. It still
is a pain in my ass to change them if the host changes and that matter
has caused real errors when the image has been fetched from the wrong
server. I guess there would have been some kind of "basedir" definition
or similar but I never got it. This anyway makes my life easier. Thanks :-D
I am quite happy, for now on, with my user:[EMAIL PROTECTED] solution. Does
anyone know any issue why not to use it in an xsl? Yeah, I know,
username and password in an ASCII file without any encryption is not the
worlds most secure thing to do, but... Can someone e.g. get an access to
my xsl, if for example Cocoon crashes? I still stress that this is not a
high security level application.
Cheers
- mika -
Andy Stevens kirjoitti:
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 -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
