[dev] Horde_RPC_soap tweaks

Jan Schneider jan at horde.org
Mon May 21 22:30:41 UTC 2007


Zitat von John Morrissey <jwm at horde.net>:

> On Mon, May 21, 2007 at 01:33:24PM -0400, Chuck Hagenbuch wrote:
>> Quoting John Morrissey <jwm at horde.net>:
>> > 1. Adds a restrictCalls parameter, a regex that calls must match to be
>> >    allowed.
>>
>> This one I have a gut reaction against, though I certainly see your
>> use case. I'm not sure how widespread that need is, though, and I feel
>> like having more fine-grained control over which methods are exposed,
>> for all backends, would be better. Unlikely that can be done without
>> breaking BC though, so I'm neutral on this for now.

We actually discussed this earlier under different circumstances, to  
add an additional parameter to the api descriptions that turns certain  
methods off for the external interfaces. This could even be done BC.
It was supposed to be a boolean setting, but you could as well turn it  
into a setting that accepts endpoint names.

> So you're thinking of a programmatic or configurable way to specify which
> API calls are exposed via any/all RPC methods? That would be useful, but to
> handle the use case I mentioned, we'd still need a way to selectively expose
> certain calls *only* via certain endpoints (not backends, endpoints).
>
> To give you an idea, to create our customer-facing SOAP endpoint, we copied
> horde's rpc.php and modified it for SOAP-only use, using a restrictCalls
> argument in only that copy of rpc.php. The "internal use" endpoint uses
> horde's unmodified rpc.php and the customer-facing endpoint uses the
> modified rpc.php.

I already wondered where you are going to provide the endpoint  
parameter. While being able to set the endpoint is nice, you still  
need to hack the code to use it. I'm against introducing a parameter  
that actually can't be used inside Horde.

> Applying this setting to all backends is definitely the Right Thing, but
> implementing that is more than I have time for right now. You'll hear no
> complaint from me if you'd rather I not commit this. This was an
> itch-scratching feature. :-)

Did you try setting the available methods explicitly in the 'provides'  
settings in registry.php instead?

>> > 3. Adds logging of SOAP calls (method, arguments, calling user,
>> >    elapsed time, and bytes output) at PEAR_LOG_INFO.
>>
>> I'd make the level PEAR_LOG_DEBUG, but otherwise this is good.
>
> I was torn between _INFO and _DEBUG. On one hand, these logs are a lot like
> web server access logs in that they're useful for after-the-fact
> troubleshooting or usage-pattern profiling ("oh, so the box is 300MB into
> swap because $REMOTE_APPLICATION started throwing 10x the normal SOAP
> transaction load at us"). This use doesn't seem amenable to _DEBUG since
> _DEBUG turns up the verbosity significantly, such as with individual SQL
> queries, which don't seem that useful on an ongoing basis.

This is definitely a DEBUG log. And is there any reason why you use  
global vars instead of object properties?

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/



More information about the dev mailing list