Hi Graham,

On 10 Dec, 10:25, Graham Charters <[EMAIL PROTECTED]> wrote:
> Disclaimer: I've never done this...
>
> Looking at the docs for the Soap Extension it seems you need to
> specify two entries in the "options" on the soap client constructor.
> These could be added as annotations that the binding understands:
>
> /**
>  * @reference
>  * @binding.soap
>  * @local_cert <location of the certificate>
>  * @passphrase <the passphrase>
>  */
>  public $the_secure_service;
>
> Extensions I made to support the ebaysoap binding mean that these
> values would get passed through to the soap binding, so we could
> extend the soap support to pass them through to the SoapClient.  We
> could do this for all the extra configuration of the soap client. The
> down side would be that these annotation names would be determined by
> the soap client, and might not be as we would like.
>
> A slightly different approach would be to use an ini file, as is done
> by the ebaysoap support (actually, it supports both).  We could just
> read all the name value pairs out of the ini, validate them and put
> them into the SoapClient.  Ebaysoap does this and then uses the
> annotations as a way to override the values in the ini.
>
> Unfortuantely, I don't have the time at the moment to do this, but if
> anyone is interested, the ebaysoap binding code would be a good place
> to start.

I have been thinking about this for a long time with respect to
security but the issue seems to be broader than that.
The first option is not really good imo. There are a lot of options
and it also means it is SOAP specific. Using ini files is flexible,
but also not ideal (for the simple fact that you need an ini file).

What about the possibility of being able to set specific containers
within SCA? I started thinking along this line when thinking about how
to apply WS-* or even authentication for REST and thought of some sort
of policy bucket. Either an array or object is passed to a static
method of SCA and set as a static variable. An annotation could
possibly be used indicating that it had policy which causes SCA to
grab and use the data that was set. This allows it to be flexible
where additional buckets/annoatiation flags can be added so that it is
not specific to just the use case I mention here.

i.e.

$policy = array('local_cert'=>'/usr/...', 'passphrase'=>'123');
SCA::setPolicy($policy);


/**
 * @reference
 * @binding.soap
 * @policy True // or some other indicator (maybe policy name if
multiple policies are allowed)
 */

The same idea could be used to provide different information for
different bindings. Instead of being so generic could also make the
annotation @security and pass a security object instead. Just ideas I
thought I'd toss out.

Rob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"phpsoa" group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to