[OpenSIPS-Devel] pres_rules: Does presence_xml uses "sphere" element?

Anca Vamanu anca at opensips.org
Thu Jul 16 11:32:37 CEST 2009


The RFC really does not suggest the processing you recommend.
-----

   Care must be taken in using <sphere> as a condition for determining
   the subscription handling.  Since the value of <sphere> changes
   dynamically, a state change can cause a subscription to be suddenly
   terminated.  The watcher has no way to know, aside from polling, when
   their subscription would be reinstated as the value of <sphere>
   changes.  For this reason, <sphere> is primarily useful for matching
   on rules that define transformations.

---
Rules that define transformations refer to the rules that define the 
changes to be applied to the body before sending it in the Notify body. 
And from this paragraph I understand exactly that the check should not 
be that strict.
But since you say that it does not work with eyebeam and there are not 
so many client implementing XCAP auth and maybe none other using sphere 
specifications, I will change the check the way you suggested.

Regards,
Anca

Iñaki Baz Castillo wrote:
> El Miércoles, 15 de Julio de 2009, Anca Vamanu escribió:
>   
>>> This is incorrect (IMHO) and explains some strange issues I've detected.
>>> For example, EyeBeam uses a custom pres-rules document which also
>>> includes rules for IM and call (and of course also por presence).
>>> Theorically pres-rules is just for presence.
>>>
>>> Fortunatelly, the "rules" for IM and call authorization sent by
>>> EyeBeam includes a sphere which custom values as "im_whitelist",
>>> "call_whitelist" and so. Since nobody (neither EyeBeam) publishes a
>>> presence document containing "sphere" value, this means that the rules
>>> for IM and calls will *never* match and the PA should *ignore* them.
>>> In this way, a user allowed for IM but not for presence wouldn't be
>>> matched as "allowed" by OpenSIPS PA.
>>>       
>> You are saying that eyebeam forms the pres-rules document as more
>> sections each with a sphere definition - im_whitelist, call_whitelist
>> from your example. Right?
>>     
>
> I mean that it has various <rules>, some of them (those not for presence), 
> containing a sphere value.
>
>
>   
>> And isn't there a sphere defined also for the
>> section corresponding to the real pres-rules section.
>>     
>
> No, in presence <rules> there is no sphere.
>
>
>   
>> In this case,
>> making the check to fail when no sphere is defined would also mean that
>> the pres-rules section will not be processed.
>>     
>
> I don't mean that. I mean that if OpenSIPS PA finds a <rule> with sphere, and 
> there is no sphere in the published doc, then PA should *not* match that rule. 
> But I understand from your previous comment that OpenSIPS PA matches a rule 
> with sphere if no sphere is found in the published document:
>
>   "If a sphere condition is encountered, the PA searches in
>    the most recent published body for a sphere definition. If one is found,
>    then it is evaluated if it matches the one in the condition.
>    If no sphere definition is found then the condition is evaluated as true."
>
> Reading the last phrase I understand:
>
>   "If no sphere definition is found (in the pres-rules) then the condition is
>    evaluated as true."
>
> And that is wrong. It should be evaluated as false. This is, a rule with 
> sphere should just match if the published doc includes a sphere with, at 
> least, that value.
>
>
> Imagine this case:
>
> ------------------------------------------------------
> <ruleset>
>
> 	<rule id="im_blacklist">
> 		<conditions>
> 			<sphere value="im_blacklist"/>
> 			<identity>
> 				<one id="sip:alice at mydomain.net"/>
> 			</identity>
> 		</conditions>
> 		<actions>
> 			<cp:im-handling>block</cp:im-handling>
> 		</actions>
> 	</rule>
>
> 	<rule id="pres_whitelist">
> 		<conditions>
> 			<identity>
> 				<one id="sip:alice at mydomain.net"/>
> 				<one id="sip:eyebeam at mydomain.net"/>
> 				<one id="sip:ibc at aliax.net"/>
> 			</identity>
> 		</conditions>
> 		<actions>
> 			<pr:sub-handling>allow</pr:sub-handling>
> 		</actions>
> 	</rule>
> 	
> </ruleset>
> ------------------------------------------------------
>
> Imagine also that the published document has no sphere at all (the usual 
> case).
>
> Now alice at mydomain.net subscribes for the presence of this presentity.
>
> Let's assume the behaviour you describe above (the one implemented in 
> OpenSIPS):
>
> - PA inspects the first rule "im_blacklist".
> - It finds a sphere="im_blacklist".
> - No sphere is found in the published document.
> - So PA matches as true and goes deeper in this rule.
> - It finds "sip:alice at mydomain.net" and action "block".
> - So the watcher is blocked (wrong).
>
> With the behaviour I propose (the correct one IMHO according to RFC):
>
> - PA inspects the first rule "im_blacklist".
> - It finds a sphere="im_blacklist".
> - No sphere is found in the published document.
> - So PA matches as *false* and leaves this rule.
> - PA inspects now the second rule "press_whitelist".
> - It finds "sip:alice at mydomain.net" and action "allow".
> - So the watcher is allowed :)
>
>
> This is; the rules with sphere conditions created by EyeBeam are supposed to 
> be useful *just* for Eyebeam itself (for authorizing incoming IM and calls), 
> just it, PA should ignore them since "sphere" makes them "un-matcheable".
>
>
> Regards.
>
>
>
> PD: I paste now a complete pres-rules document generated by EyeBeam:
>
> ------------------------
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy" 
> xmlns:pr="urn:ietf:params:xml:ns:pres-rules" 
> xmlns:cp="www.counterpath.com/privacy-lists">
> 	<rule id="pres_whitelist_default">
> 		<conditions>
> 			<identity>
> 				<many>
> 					<except id="sip:blocked at calls.org"/>
> 				</many>
> 			</identity>
> 		</conditions>
> 		<actions>
> 			<pr:sub-handling>allow</pr:sub-handling>
> 		</actions>
> 	</rule>
> 	<rule id="im_whitelist_default">
> 		<conditions>
> 			<sphere value="im_whitelist_default"/>
> 			<identity>
> 				<many>
> 					<except id="sip:blocked at calls.org"/>
> 				</many>
> 			</identity>
> 		</conditions>
> 		<actions>
> 			<cp:im-handling>allow</cp:im-handling>
> 		</actions>
> 	</rule>
> 	<rule id="pres_whitelist">
> 		<conditions>
> 			<identity>
> 				<one id="sip:alice at mydomain.net"/>
> 				<one id="sip:eyebeam at mydomain.net"/>
> 				<one id="sip:ibc at aliax.net"/>
> 			</identity>
> 		</conditions>
> 		<actions>
> 			<pr:sub-handling>allow</pr:sub-handling>
> 		</actions>
> 	</rule>
> 	<rule id="pres_blacklist">
> 		<conditions>
> 			<identity>
> 				<one id="sip:blocked at calls.org"/>
> 			</identity>
> 		</conditions>
> 		<actions>
> 			<pr:sub-handling>block</pr:sub-handling>
> 		</actions>
> 	</rule>
> 	<rule id="im_whitelist">
> 		<conditions>
> 			<sphere value="im_whitelist"/>
> 			<identity>
> 				<one id="sip:alice at mydomain.net"/>
> 				<one id="sip:eyebeam at mydomain.net"/>
> 				<one id="sip:ibc at aliax.net"/>
> 			</identity>
> 		</conditions>
> 		<actions>
> 			<cp:im-handling>allow</cp:im-handling>
> 		</actions>
> 	</rule>
> 	<rule id="im_blacklist">
> 		<conditions>
> 			<sphere value="im_blacklist"/>
> 			<identity>
> 				<one id="sip:blocked at calls.org"/>
> 			</identity>
> 		</conditions>
> 		<actions>
> 			<cp:im-handling>block</cp:im-handling>
> 		</actions>
> 	</rule>
> 	<rule id="phone_blacklist">
> 		<conditions>
> 			<sphere value="phone_blacklist"/>
> 			<identity>
> 				<one id="sip:blocked at calls.org"/>
> 			</identity>
> 		</conditions>
> 		<actions>
> 			<cp:phone-handling>block</cp:phone-handling>
> 		</actions>
> 	</rule>
> </ruleset>
>
> ------------------------
>
>   




More information about the Devel mailing list