Daniel,
What whould you think about this variant of xcap authentication:
event_route[xhttp:request] {
xdbg("= xhttp: request [$rv] $rm => $hu\n");
if($hu=~"^/xcap-root/")
{
# xcap ops
$xcapuri(u=>data) = $hu;
if($xcapuri(
2010/10/16 Rouskol Andrey :
> 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)=~".
Iñaki,
Yes, it does. Xcap module parses request url, and produces $xcapuri(u=>xuid),
which could have different formats: user, u...@domain or sip:u...@domain.
And $var{uri} is a "sip normalised" form of it, ie: sip:u...@domain.
This part was taken from Daniels tutorial as is. My question was abo
Hello,
the module parses inside the xcap uri, but you can build a custom one in
config and give it as parameter to xcap server functions. In this way
you can do normalization, sanity checks, etc.
For these kind of operations I added a variable that can be used to
access parts of an xcap uri
Hello Andrey,
seems ok, I will give some more thoughts about.
At the end of the day, it is your decision as administrator how you
enforce the xcap-uri format and authentication/authorization.
The fact is that http uri does not contain domain part usually, it is
just document/resource refere
2010/10/19 Daniel-Constantin Mierla :
> The fact is that http uri does not contain domain part usually,
It should, at least if such devices want to "interoperate" (a word
that doesn't exist in XCAP) with today's XCAP specifications.
> it is just document/resource reference part. I have seen serv
On 10/19/10 10:58 AM, Iñaki Baz Castillo wrote:
2010/10/19 Daniel-Constantin Mierla:
The fact is that http uri does not contain domain part usually,
It should, at least if such devices want to "interoperate" (a word
that doesn't exist in XCAP) with today's XCAP specifications.
it is just d
