You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Raymond Boswel <ra...@gmail.com> on 2015/02/10 09:04:55 UTC
Using the OpenAuthorizationConfigurationClass
Hi all,
I want to use the OpenAuthorizationConfiguration class so that all
repository users have crud rights in the repository. It seems like a simple
use case, but I have been unable to find any info on how to set this up
and, to paraphrase Thomas Edison, I have found a lot of ways that don't
work :) Any ideas would be most welcome.
Kind regards,
Raymond
Re: Using the OpenAuthorizationConfigurationClass
Posted by Raymond Boswel <ra...@gmail.com>.
Hi Angela,
Haha, yes, I saw my authentication/authorization mix up much too late :)
For my own purposes the oak codebase doesn't need to change; I solved the
problem by copying the securityProviderImpl code into a securityProvider
class of my own, just changing out the necessary classes.
I'm not familiar with the osgi architecture myself; we're using oak in a
straight forward JavaEE/glassfish deployment. If you think the suggested
alteration would be useful to the user base at large then we should do so,
but for the moment my oak deployment is running smoothly.
Kind regards,
Raymond
On 2 Mar 2015 18:45, "Angela Schreiber" <an...@adobe.com> wrote:
> hi raymond
>
> alternatively we may consider adding dedicated (protected) bindXYZ
> methods as we already have them for the composite modules.
> i don't know in details what you want to achieve... so not sure
> what's the best solution for you.
>
> but i know for sure that you confuse me if you mix up
> authorization and authentication ;-)
>
> best regards
> angela
>
>
>
> On 24/02/15 07:24, "Raymond Boswel" <ra...@gmail.com> wrote:
>
> >Hi Angela,
> >
> >I've written a new constructor with signature
> >SecurityProviderImpl(SecurityConfiguration... configurations). The problem
> >is, in the current constructor, each SecurityConfiguration is created with
> >e.g. authenticationConfiguration = new
> >AuthenticationConfigurationImpl(this), setting the securityProvider,
> >whereas creating the SecurityConfiguration before the SecurityProvider and
> >passing it in as a parameter, the SecurityConfiguration would have to be
> >constructed with authenticationConfiguration = new
> >AuthenticationConfigurationImpl(), not setting the securityProvider. This
> >seems problematic to me. Though I'm not sure of the possible
> >repercussions.
> >Any thoughts?
> >
> >Kind regards,
> >Raymond
> >
> >On Tue, Feb 17, 2015 at 11:32 AM, Raymond Boswel <raymondboswel@gmail.com
> >
> >wrote:
> >
> >> Hi Angela,
> >>
> >> I got it working thanks! I'll be glad to add my 10 cents to the
> >>project.
> >> Hopefully I'll have a patch for you within the next few days.
> >>
> >> Kind regards,
> >> Raymond
> >>
> >> On Tue, Feb 17, 2015 at 10:04 AM, Angela Schreiber <an...@adobe.com>
> >> wrote:
> >>
> >>> hi raymond
> >>>
> >>> alternatively you may want to create a subclass of the default
> >>> security provider implementation and make sure you return your
> >>> implementation of authorization config (not setting the private
> >>> field).
> >>>
> >>> what we also could do is adding a constructor
> >>> SecurityProviderImpl(SecurityConfiguration... configurations);
> >>>
> >>> the reason we we don't have something like this is simply that
> >>> we use oak in a osgi setup where there the default setup can
> >>> be overwritten by plugging new services.
> >>>
> >>> feel free to create an improvement issue and attach a patch.
> >>>
> >>> kind regards
> >>> angela
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 17/02/15 06:54, "Raymond Boswel" <ra...@gmail.com> wrote:
> >>>
> >>> >Hi Angela,
> >>> >
> >>> >I have tried using the OpenSecurityProvider before, but I want to be
> >>>able
> >>> >to log in users so I can use the created/createdBy mixins. I'll have
> >>>to
> >>> go
> >>> >the extension route. The authorizationConfiguration variable is
> >>>private
> >>> in
> >>> >the securityProviderImpl class, so I can't access it by extending the
> >>> >class
> >>> >itself. As an alternate route I could just copy the contents in a new
> >>> >class
> >>> >and change the authorizationConfiguration assignment, but there seems
> >>>to
> >>> >be
> >>> >a mismatch between what's in the repository and what I get from
> >>>maven. In
> >>> >version 1.1.5 there is no WhiteboardAuthorizableNodeName available,
> >>>but I
> >>> >see it in the securityProviderImpl class as far back as October.
> >>>Should I
> >>> >use an even older version?
> >>> >
> >>> >Many thanks,
> >>> >Raymond
> >>> >
> >>> >On Mon, Feb 16, 2015 at 12:10 PM, Angela Schreiber <anchela@adobe.com
> >
> >>> >wrote:
> >>> >
> >>> >> hi raymond
> >>> >>
> >>> >> it depends on what kind of security setup you wish to have.
> >>> >> in any case you have to set the desired SecurityProvider
> >>> >> which depending on your needs requires more/less customisation.
> >>> >>
> >>> >> oak current provides 2 implementations:
> >>> >> - OpenSecurityProvider : a very limited one that grants full
> >>>everywhere
> >>> >> but otherwise doesn't support any security related operations.
> >>> >> - SecurityProviderImpl: exposes all security related modules.
> >>> >>
> >>> >> so, unless you wish to come up with your custom implementation for
> >>> >> everything you may start extending one of those to provide your
> >>> expected
> >>> >> setup and pass your custom implementation to the repository e.g.
> >>> >>
> >>> >> new Jcr().with(mySecurityProvider).createRepository()
> >>> >>
> >>> >> or i case you are operating on Oak
> >>> >>
> >>> >> new Oak().with(mySecurityProvider).createContentRepository()
> >>> >>
> >>> >> hope that helps
> >>> >> angela
> >>> >>
> >>> >> On 10/02/15 09:04, "Raymond Boswel" <ra...@gmail.com>
> wrote:
> >>> >>
> >>> >> >Hi all,
> >>> >> >
> >>> >> >I want to use the OpenAuthorizationConfiguration class so that all
> >>> >> >repository users have crud rights in the repository. It seems like
> >>>a
> >>> >> >simple
> >>> >> >use case, but I have been unable to find any info on how to set
> >>>this
> >>> up
> >>> >> >and, to paraphrase Thomas Edison, I have found a lot of ways that
> >>> don't
> >>> >> >work :) Any ideas would be most welcome.
> >>> >> >
> >>> >> >Kind regards,
> >>> >> >Raymond
> >>> >>
> >>> >>
> >>>
> >>>
> >>
>
>
Re: Using the OpenAuthorizationConfigurationClass
Posted by Angela Schreiber <an...@adobe.com>.
hi raymond
alternatively we may consider adding dedicated (protected) bindXYZ
methods as we already have them for the composite modules.
i don't know in details what you want to achieve... so not sure
what's the best solution for you.
but i know for sure that you confuse me if you mix up
authorization and authentication ;-)
best regards
angela
On 24/02/15 07:24, "Raymond Boswel" <ra...@gmail.com> wrote:
>Hi Angela,
>
>I've written a new constructor with signature
>SecurityProviderImpl(SecurityConfiguration... configurations). The problem
>is, in the current constructor, each SecurityConfiguration is created with
>e.g. authenticationConfiguration = new
>AuthenticationConfigurationImpl(this), setting the securityProvider,
>whereas creating the SecurityConfiguration before the SecurityProvider and
>passing it in as a parameter, the SecurityConfiguration would have to be
>constructed with authenticationConfiguration = new
>AuthenticationConfigurationImpl(), not setting the securityProvider. This
>seems problematic to me. Though I'm not sure of the possible
>repercussions.
>Any thoughts?
>
>Kind regards,
>Raymond
>
>On Tue, Feb 17, 2015 at 11:32 AM, Raymond Boswel <ra...@gmail.com>
>wrote:
>
>> Hi Angela,
>>
>> I got it working thanks! I'll be glad to add my 10 cents to the
>>project.
>> Hopefully I'll have a patch for you within the next few days.
>>
>> Kind regards,
>> Raymond
>>
>> On Tue, Feb 17, 2015 at 10:04 AM, Angela Schreiber <an...@adobe.com>
>> wrote:
>>
>>> hi raymond
>>>
>>> alternatively you may want to create a subclass of the default
>>> security provider implementation and make sure you return your
>>> implementation of authorization config (not setting the private
>>> field).
>>>
>>> what we also could do is adding a constructor
>>> SecurityProviderImpl(SecurityConfiguration... configurations);
>>>
>>> the reason we we don't have something like this is simply that
>>> we use oak in a osgi setup where there the default setup can
>>> be overwritten by plugging new services.
>>>
>>> feel free to create an improvement issue and attach a patch.
>>>
>>> kind regards
>>> angela
>>>
>>>
>>>
>>>
>>>
>>> On 17/02/15 06:54, "Raymond Boswel" <ra...@gmail.com> wrote:
>>>
>>> >Hi Angela,
>>> >
>>> >I have tried using the OpenSecurityProvider before, but I want to be
>>>able
>>> >to log in users so I can use the created/createdBy mixins. I'll have
>>>to
>>> go
>>> >the extension route. The authorizationConfiguration variable is
>>>private
>>> in
>>> >the securityProviderImpl class, so I can't access it by extending the
>>> >class
>>> >itself. As an alternate route I could just copy the contents in a new
>>> >class
>>> >and change the authorizationConfiguration assignment, but there seems
>>>to
>>> >be
>>> >a mismatch between what's in the repository and what I get from
>>>maven. In
>>> >version 1.1.5 there is no WhiteboardAuthorizableNodeName available,
>>>but I
>>> >see it in the securityProviderImpl class as far back as October.
>>>Should I
>>> >use an even older version?
>>> >
>>> >Many thanks,
>>> >Raymond
>>> >
>>> >On Mon, Feb 16, 2015 at 12:10 PM, Angela Schreiber <an...@adobe.com>
>>> >wrote:
>>> >
>>> >> hi raymond
>>> >>
>>> >> it depends on what kind of security setup you wish to have.
>>> >> in any case you have to set the desired SecurityProvider
>>> >> which depending on your needs requires more/less customisation.
>>> >>
>>> >> oak current provides 2 implementations:
>>> >> - OpenSecurityProvider : a very limited one that grants full
>>>everywhere
>>> >> but otherwise doesn't support any security related operations.
>>> >> - SecurityProviderImpl: exposes all security related modules.
>>> >>
>>> >> so, unless you wish to come up with your custom implementation for
>>> >> everything you may start extending one of those to provide your
>>> expected
>>> >> setup and pass your custom implementation to the repository e.g.
>>> >>
>>> >> new Jcr().with(mySecurityProvider).createRepository()
>>> >>
>>> >> or i case you are operating on Oak
>>> >>
>>> >> new Oak().with(mySecurityProvider).createContentRepository()
>>> >>
>>> >> hope that helps
>>> >> angela
>>> >>
>>> >> On 10/02/15 09:04, "Raymond Boswel" <ra...@gmail.com> wrote:
>>> >>
>>> >> >Hi all,
>>> >> >
>>> >> >I want to use the OpenAuthorizationConfiguration class so that all
>>> >> >repository users have crud rights in the repository. It seems like
>>>a
>>> >> >simple
>>> >> >use case, but I have been unable to find any info on how to set
>>>this
>>> up
>>> >> >and, to paraphrase Thomas Edison, I have found a lot of ways that
>>> don't
>>> >> >work :) Any ideas would be most welcome.
>>> >> >
>>> >> >Kind regards,
>>> >> >Raymond
>>> >>
>>> >>
>>>
>>>
>>
Re: Using the OpenAuthorizationConfigurationClass
Posted by Raymond Boswel <ra...@gmail.com>.
Hi Angela,
I've written a new constructor with signature
SecurityProviderImpl(SecurityConfiguration... configurations). The problem
is, in the current constructor, each SecurityConfiguration is created with
e.g. authenticationConfiguration = new
AuthenticationConfigurationImpl(this), setting the securityProvider,
whereas creating the SecurityConfiguration before the SecurityProvider and
passing it in as a parameter, the SecurityConfiguration would have to be
constructed with authenticationConfiguration = new
AuthenticationConfigurationImpl(), not setting the securityProvider. This
seems problematic to me. Though I'm not sure of the possible repercussions.
Any thoughts?
Kind regards,
Raymond
On Tue, Feb 17, 2015 at 11:32 AM, Raymond Boswel <ra...@gmail.com>
wrote:
> Hi Angela,
>
> I got it working thanks! I'll be glad to add my 10 cents to the project.
> Hopefully I'll have a patch for you within the next few days.
>
> Kind regards,
> Raymond
>
> On Tue, Feb 17, 2015 at 10:04 AM, Angela Schreiber <an...@adobe.com>
> wrote:
>
>> hi raymond
>>
>> alternatively you may want to create a subclass of the default
>> security provider implementation and make sure you return your
>> implementation of authorization config (not setting the private
>> field).
>>
>> what we also could do is adding a constructor
>> SecurityProviderImpl(SecurityConfiguration... configurations);
>>
>> the reason we we don't have something like this is simply that
>> we use oak in a osgi setup where there the default setup can
>> be overwritten by plugging new services.
>>
>> feel free to create an improvement issue and attach a patch.
>>
>> kind regards
>> angela
>>
>>
>>
>>
>>
>> On 17/02/15 06:54, "Raymond Boswel" <ra...@gmail.com> wrote:
>>
>> >Hi Angela,
>> >
>> >I have tried using the OpenSecurityProvider before, but I want to be able
>> >to log in users so I can use the created/createdBy mixins. I'll have to
>> go
>> >the extension route. The authorizationConfiguration variable is private
>> in
>> >the securityProviderImpl class, so I can't access it by extending the
>> >class
>> >itself. As an alternate route I could just copy the contents in a new
>> >class
>> >and change the authorizationConfiguration assignment, but there seems to
>> >be
>> >a mismatch between what's in the repository and what I get from maven. In
>> >version 1.1.5 there is no WhiteboardAuthorizableNodeName available, but I
>> >see it in the securityProviderImpl class as far back as October. Should I
>> >use an even older version?
>> >
>> >Many thanks,
>> >Raymond
>> >
>> >On Mon, Feb 16, 2015 at 12:10 PM, Angela Schreiber <an...@adobe.com>
>> >wrote:
>> >
>> >> hi raymond
>> >>
>> >> it depends on what kind of security setup you wish to have.
>> >> in any case you have to set the desired SecurityProvider
>> >> which depending on your needs requires more/less customisation.
>> >>
>> >> oak current provides 2 implementations:
>> >> - OpenSecurityProvider : a very limited one that grants full everywhere
>> >> but otherwise doesn't support any security related operations.
>> >> - SecurityProviderImpl: exposes all security related modules.
>> >>
>> >> so, unless you wish to come up with your custom implementation for
>> >> everything you may start extending one of those to provide your
>> expected
>> >> setup and pass your custom implementation to the repository e.g.
>> >>
>> >> new Jcr().with(mySecurityProvider).createRepository()
>> >>
>> >> or i case you are operating on Oak
>> >>
>> >> new Oak().with(mySecurityProvider).createContentRepository()
>> >>
>> >> hope that helps
>> >> angela
>> >>
>> >> On 10/02/15 09:04, "Raymond Boswel" <ra...@gmail.com> wrote:
>> >>
>> >> >Hi all,
>> >> >
>> >> >I want to use the OpenAuthorizationConfiguration class so that all
>> >> >repository users have crud rights in the repository. It seems like a
>> >> >simple
>> >> >use case, but I have been unable to find any info on how to set this
>> up
>> >> >and, to paraphrase Thomas Edison, I have found a lot of ways that
>> don't
>> >> >work :) Any ideas would be most welcome.
>> >> >
>> >> >Kind regards,
>> >> >Raymond
>> >>
>> >>
>>
>>
>
Re: Using the OpenAuthorizationConfigurationClass
Posted by Raymond Boswel <ra...@gmail.com>.
Hi Angela,
I got it working thanks! I'll be glad to add my 10 cents to the project.
Hopefully I'll have a patch for you within the next few days.
Kind regards,
Raymond
On Tue, Feb 17, 2015 at 10:04 AM, Angela Schreiber <an...@adobe.com>
wrote:
> hi raymond
>
> alternatively you may want to create a subclass of the default
> security provider implementation and make sure you return your
> implementation of authorization config (not setting the private
> field).
>
> what we also could do is adding a constructor
> SecurityProviderImpl(SecurityConfiguration... configurations);
>
> the reason we we don't have something like this is simply that
> we use oak in a osgi setup where there the default setup can
> be overwritten by plugging new services.
>
> feel free to create an improvement issue and attach a patch.
>
> kind regards
> angela
>
>
>
>
>
> On 17/02/15 06:54, "Raymond Boswel" <ra...@gmail.com> wrote:
>
> >Hi Angela,
> >
> >I have tried using the OpenSecurityProvider before, but I want to be able
> >to log in users so I can use the created/createdBy mixins. I'll have to go
> >the extension route. The authorizationConfiguration variable is private in
> >the securityProviderImpl class, so I can't access it by extending the
> >class
> >itself. As an alternate route I could just copy the contents in a new
> >class
> >and change the authorizationConfiguration assignment, but there seems to
> >be
> >a mismatch between what's in the repository and what I get from maven. In
> >version 1.1.5 there is no WhiteboardAuthorizableNodeName available, but I
> >see it in the securityProviderImpl class as far back as October. Should I
> >use an even older version?
> >
> >Many thanks,
> >Raymond
> >
> >On Mon, Feb 16, 2015 at 12:10 PM, Angela Schreiber <an...@adobe.com>
> >wrote:
> >
> >> hi raymond
> >>
> >> it depends on what kind of security setup you wish to have.
> >> in any case you have to set the desired SecurityProvider
> >> which depending on your needs requires more/less customisation.
> >>
> >> oak current provides 2 implementations:
> >> - OpenSecurityProvider : a very limited one that grants full everywhere
> >> but otherwise doesn't support any security related operations.
> >> - SecurityProviderImpl: exposes all security related modules.
> >>
> >> so, unless you wish to come up with your custom implementation for
> >> everything you may start extending one of those to provide your expected
> >> setup and pass your custom implementation to the repository e.g.
> >>
> >> new Jcr().with(mySecurityProvider).createRepository()
> >>
> >> or i case you are operating on Oak
> >>
> >> new Oak().with(mySecurityProvider).createContentRepository()
> >>
> >> hope that helps
> >> angela
> >>
> >> On 10/02/15 09:04, "Raymond Boswel" <ra...@gmail.com> wrote:
> >>
> >> >Hi all,
> >> >
> >> >I want to use the OpenAuthorizationConfiguration class so that all
> >> >repository users have crud rights in the repository. It seems like a
> >> >simple
> >> >use case, but I have been unable to find any info on how to set this up
> >> >and, to paraphrase Thomas Edison, I have found a lot of ways that don't
> >> >work :) Any ideas would be most welcome.
> >> >
> >> >Kind regards,
> >> >Raymond
> >>
> >>
>
>
Re: Using the OpenAuthorizationConfigurationClass
Posted by Angela Schreiber <an...@adobe.com>.
hi raymond
alternatively you may want to create a subclass of the default
security provider implementation and make sure you return your
implementation of authorization config (not setting the private
field).
what we also could do is adding a constructor
SecurityProviderImpl(SecurityConfiguration... configurations);
the reason we we don't have something like this is simply that
we use oak in a osgi setup where there the default setup can
be overwritten by plugging new services.
feel free to create an improvement issue and attach a patch.
kind regards
angela
On 17/02/15 06:54, "Raymond Boswel" <ra...@gmail.com> wrote:
>Hi Angela,
>
>I have tried using the OpenSecurityProvider before, but I want to be able
>to log in users so I can use the created/createdBy mixins. I'll have to go
>the extension route. The authorizationConfiguration variable is private in
>the securityProviderImpl class, so I can't access it by extending the
>class
>itself. As an alternate route I could just copy the contents in a new
>class
>and change the authorizationConfiguration assignment, but there seems to
>be
>a mismatch between what's in the repository and what I get from maven. In
>version 1.1.5 there is no WhiteboardAuthorizableNodeName available, but I
>see it in the securityProviderImpl class as far back as October. Should I
>use an even older version?
>
>Many thanks,
>Raymond
>
>On Mon, Feb 16, 2015 at 12:10 PM, Angela Schreiber <an...@adobe.com>
>wrote:
>
>> hi raymond
>>
>> it depends on what kind of security setup you wish to have.
>> in any case you have to set the desired SecurityProvider
>> which depending on your needs requires more/less customisation.
>>
>> oak current provides 2 implementations:
>> - OpenSecurityProvider : a very limited one that grants full everywhere
>> but otherwise doesn't support any security related operations.
>> - SecurityProviderImpl: exposes all security related modules.
>>
>> so, unless you wish to come up with your custom implementation for
>> everything you may start extending one of those to provide your expected
>> setup and pass your custom implementation to the repository e.g.
>>
>> new Jcr().with(mySecurityProvider).createRepository()
>>
>> or i case you are operating on Oak
>>
>> new Oak().with(mySecurityProvider).createContentRepository()
>>
>> hope that helps
>> angela
>>
>> On 10/02/15 09:04, "Raymond Boswel" <ra...@gmail.com> wrote:
>>
>> >Hi all,
>> >
>> >I want to use the OpenAuthorizationConfiguration class so that all
>> >repository users have crud rights in the repository. It seems like a
>> >simple
>> >use case, but I have been unable to find any info on how to set this up
>> >and, to paraphrase Thomas Edison, I have found a lot of ways that don't
>> >work :) Any ideas would be most welcome.
>> >
>> >Kind regards,
>> >Raymond
>>
>>
Re: Using the OpenAuthorizationConfigurationClass
Posted by Raymond Boswel <ra...@gmail.com>.
Hi Angela,
I have tried using the OpenSecurityProvider before, but I want to be able
to log in users so I can use the created/createdBy mixins. I'll have to go
the extension route. The authorizationConfiguration variable is private in
the securityProviderImpl class, so I can't access it by extending the class
itself. As an alternate route I could just copy the contents in a new class
and change the authorizationConfiguration assignment, but there seems to be
a mismatch between what's in the repository and what I get from maven. In
version 1.1.5 there is no WhiteboardAuthorizableNodeName available, but I
see it in the securityProviderImpl class as far back as October. Should I
use an even older version?
Many thanks,
Raymond
On Mon, Feb 16, 2015 at 12:10 PM, Angela Schreiber <an...@adobe.com>
wrote:
> hi raymond
>
> it depends on what kind of security setup you wish to have.
> in any case you have to set the desired SecurityProvider
> which depending on your needs requires more/less customisation.
>
> oak current provides 2 implementations:
> - OpenSecurityProvider : a very limited one that grants full everywhere
> but otherwise doesn't support any security related operations.
> - SecurityProviderImpl: exposes all security related modules.
>
> so, unless you wish to come up with your custom implementation for
> everything you may start extending one of those to provide your expected
> setup and pass your custom implementation to the repository e.g.
>
> new Jcr().with(mySecurityProvider).createRepository()
>
> or i case you are operating on Oak
>
> new Oak().with(mySecurityProvider).createContentRepository()
>
> hope that helps
> angela
>
> On 10/02/15 09:04, "Raymond Boswel" <ra...@gmail.com> wrote:
>
> >Hi all,
> >
> >I want to use the OpenAuthorizationConfiguration class so that all
> >repository users have crud rights in the repository. It seems like a
> >simple
> >use case, but I have been unable to find any info on how to set this up
> >and, to paraphrase Thomas Edison, I have found a lot of ways that don't
> >work :) Any ideas would be most welcome.
> >
> >Kind regards,
> >Raymond
>
>
Re: Using the OpenAuthorizationConfigurationClass
Posted by Angela Schreiber <an...@adobe.com>.
hi raymond
it depends on what kind of security setup you wish to have.
in any case you have to set the desired SecurityProvider
which depending on your needs requires more/less customisation.
oak current provides 2 implementations:
- OpenSecurityProvider : a very limited one that grants full everywhere
but otherwise doesn't support any security related operations.
- SecurityProviderImpl: exposes all security related modules.
so, unless you wish to come up with your custom implementation for
everything you may start extending one of those to provide your expected
setup and pass your custom implementation to the repository e.g.
new Jcr().with(mySecurityProvider).createRepository()
or i case you are operating on Oak
new Oak().with(mySecurityProvider).createContentRepository()
hope that helps
angela
On 10/02/15 09:04, "Raymond Boswel" <ra...@gmail.com> wrote:
>Hi all,
>
>I want to use the OpenAuthorizationConfiguration class so that all
>repository users have crud rights in the repository. It seems like a
>simple
>use case, but I have been unable to find any info on how to set this up
>and, to paraphrase Thomas Edison, I have found a lot of ways that don't
>work :) Any ideas would be most welcome.
>
>Kind regards,
>Raymond