-
EOF
Perl 6 solved problems we didn't even know we had. I love it.
-
nicoco_
I have a question about privileged entity (xep0356). If the component needs to send a message on behalf of `dude@lazy.af`, it must always address the privileged message to `lazy.af`, right? So I can just infer the outer message `to` attribute using the server part of the `from` attribute of the inner, wrapped msg. Does that make sense, or are there cases where a component might need to impersonate `dude@lazy.af` by addressing the "privileged message" to another vhost? Holder I hope it's OK to ping you here, since we discussed the matter via DM earlier.
-
flow
nicoco_, using the domainpart of the "spoofed" from address as the entity running a priviliged entity service for that particular address would be also my expectation
-
flow
hmm, does xep356 not have a disco feature or am I missing it?
-
nicoco_
apparently not. on login, the server sends a message informing the entity of its privileges
-
flow
I assume the message's 'from' attribute contains the address of the entity which the privilged entity is allowed to act upon
-
nicoco_
I was inferring the `to` attribute for impersonated messages using this "privilege advertising" message's `from`, but it turns out that several vhosts may advertise it so I have a choice to either make this `to` attribute an option, or guess from the impersonated JID server part
-
flow
Oh, it's even more: "Here pubsub.capulet.lit is allowed to do get and set operations on all entities managed by capulet.lit"
-
nicoco_
ok, thinking about it, I now believe I should keep track of "privilege advertising" message `from` attr AND use the `from` attr of the wrapped message to infer which vhost the privileged message should be addressed to. Or just attempt to send the privilege message and let the server answer with an iq error if the entity wasn't privileged after all, but maybe that's ugly
-
nicoco_
thanks flow!
-
flow
not sure if I was really helpful here, but you're welcome :)
-
flow
it appears that xep356 was written under the assumption that entitys somehow now where to request becoming a priviliged entity for some other entity from
-
flow
probably asking the entity that is addressable via the domainpart as a reasonable first try
-
nicoco_
but you think there are edge cases where this first try would be a bad guess, eg, to impersonate `dude@lazy.af` the component might need to actually address the privileged message to `donny.stfu`?
-
flow
Well, I can't certainly rule out that there are such cases, but I don't think they are that relevant
-
nicoco_
ok, let's see if someone else has any idea about this. I'm all for customizability, but I'd like to avoid cluttering my docs with nonsensical config options
-
flow
nicoco_, if the need arises, you could always add a config option later
-
nicoco_
wise words, I'll do that. inferring from the domain part sounds very reasonable to me