2010/9/29 Daniel-Constantin Mierla <miconda(a)gmail.com>om>: Hi, a typo: "body lists - your contacts" should be: "buddy lists - your contacts" :) -- Iñaki Baz Castillo <ibc(a)aliax.net>

On 9/30/10 12:53 AM, Iñaki Baz Castillo wrote: thanks, fixed. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

2010/9/30 Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt;om>: In OMA specs *any* change (PUT/DELETE) in resource-lists document must trigger a reload of pres-rules and other applications including references to lists in 'resource-lists'. The same in 'pres-rules' document, sure. If for example Bob is included in <list id="friends> and such list is referred by <list id="oma_buddies"> and 'oma_buddies' is referred by a rule in pres-rules with action 'allow', then removing Bob from <list id="friends"> requires the *complete* (UGLY) pres-rules to be re-calculated so Bob's subscription status would change from "active" to "terminated". Now to demostrate how ugly is all this stuff, let imagine you want to temporally block Bob (so he cannot see your current real presence status). According to OMA specs (and there are no other specs): 1) First you should do a partial DELETE operation in 'resource-list' to remove Bob uri from your granted <list>. 2) Later you should do a partial PUT operation in 'resource-lists' to include Bob in a <list id="oma_polite_blocked"> (or something similar). Oppps, problem! After step 1 the presence server should *terminate* the subscription dialog with you (the watcher) so you receive a NOTIFY with "Subscription-Status: terminated;reason=rejected". Then it's *up to you* to subscribe to Bob again or not. Imagine you subscribe again to Bob's presence upon receipt of the NOTIFY (but before the above step 2). Then your SUSBCRIBE would be rejected again. Will you try *again* a new SUSBCRIBE? for how long? After step 2, if you send a new SUBSCRIBE then the server will accept your subscription but notify you with false presence status (or no info at all) as you are polite-blocked. Obviously this design is ugly. In contrast, in XMPP there is like an API to "authorize"/"desauthorize" a contact, "block" him... you must not deal with tedious XML files for *all*, neither you need to expect that the presence server and all your UA's (same AoR) interpret the whole XML documents in the same way (bob is included in "oma_granted" list but he is also included in 'pres-rules' document as a separate blocked entry, should I understand he is blocked or allowed? will the presence server understand the same as my UA?). Also, in XMPP a change in your buddylist doesn't require the presence server to re-compute all the permissions of all your watchers. Well, coming back to the original question: yes, any incremental/total change (PUT/DELETE) in pres-rules or resource-lists document should trigger a complete reload of watchers permissions. Also, the RLS application uses a reference to a <list> into resource-lists, so if a item in such list is modified the RLs should recompute the list of AoR's it must subscribe in behalf of the user (so ugly all of this...). Regards. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

Daniel, In addition to my previous letter, for multidomain case, to prevent user@domain1 from changing xcaps for user@domain2, we need do something like this (withing second WITH_XHTTPAUTH section): #!ifdef WITH_MULTIDOMAIN $var(tmp) = "sip:"+$aU; if ($var(uri)!=$var(tmp)) { #!else if ($au!=$(var(uri){uri.user})) { #!endif Regards, Andrey. 01.10.10, 20:12, "Rouskol Andrey" &lt;anry-dev(a)yandex.ru&gt;ru>:

Hello Andrey, On 10/1/10 7:47 PM, Rouskol Andrey wrote: But here is like this because your client uses user@domain in username field for authentication, right? However, in many cases, even in multi-domain environment, people still use only user part in username field and the domain is taken from R-URI or headers like From/To. To make this complete for multi-domain, I think there must be a condition to check for domain in $aU and if missing, try to get it from other parts, right? Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

Hello, On 10/4/10 3:37 PM, Rouskol Andrey wrote: the multidomain is for database query in order to do select based on domain field, otherwise is ignored. What sip phone do you use? Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

Daniel, What whould you think about this variant: event_route[xhttp:request] { xlog("L_INFO", "===== xhttp: request [$rv] $rm => $hu\n"); xdbg("===== xhttp: request [$rv] $rm => $hu\n"); if($hu=~"^/xcap-root/") { # xcap ops $xcapuri(u=>data) = $hu; if($xcapuri(u=>xuid)=~"^sip:.+@.+") $var(uri) = $xcapuri(u=>xuid); else if($xcapuri(u=>xuid)=~".+@.+") $var(uri) = "sip:"+ $xcapuri(u=>xuid); else $var(uri) = "sip:"+ $xcapuri(u=>xuid) + "@" + $Ri; xlog("L_INFO", "===== xhttp: $xcapuri(u=>auid) : $xcapuri(u=>xuid)\n"); if($xcapuri(u=>auid)=="xcap-caps") { set_reply_close(); set_reply_no_connect(); $var(xbody) = .. xhttp_reply("200", "ok", "application/xcap-caps+xml", "$var(xbody)"); exit; } #!ifdef WITH_XHTTPAUTH #!ifdef WITH_MULTIDOMAIN if (!www_authorize("$(var(uri){uri.host})", "subscriber")) { www_challenge("$(var(uri){uri.host})", "0"); #!else if (!www_authorize("xcap", "subscriber")) { www_challenge("xcap", "0"); #!endif exit; } set_reply_close(); set_reply_no_connect(); #!ifdef WITH_XHTTPAUTH # be sure auth user access only its documents #!ifdef WITH_MULTIDOMAIN if($aU=~".+@.+") $var(tmp) = "sip:"+$aU; else $var(tmp) = "sip:"+$aU+"@"+$(var(uri){uri.host}); if ($var(uri)!=$var(tmp)) { xlog("L_INFO", "===== xhttp: Forbidden!!! $var(tmp) - $var(uri)\n"); #!else if ($au!=$(var(uri){uri.user})) { xlog("L_INFO", "===== xhttp: Forbidden!!! $au - $(var(uri){uri.user})\n"); #!endif .. Regards, Andrey.