jdev - 2022-09-05


  1. EOF

    Perl 6 solved problems we didn't even know we had. I love it.

  2. 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.

  3. 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

  4. flow

    hmm, does xep356 not have a disco feature or am I missing it?

  5. nicoco_

    apparently not. on login, the server sends a message informing the entity of its privileges

  6. flow

    I assume the message's 'from' attribute contains the address of the entity which the privilged entity is allowed to act upon

  7. 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

  8. 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"

  9. 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

  10. nicoco_

    thanks flow!

  11. flow

    not sure if I was really helpful here, but you're welcome :)

  12. 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

  13. flow

    probably asking the entity that is addressable via the domainpart as a reasonable first try

  14. 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`?

  15. flow

    Well, I can't certainly rule out that there are such cases, but I don't think they are that relevant

  16. 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

  17. flow

    nicoco_, if the need arises, you could always add a config option later

  18. nicoco_

    wise words, I'll do that. inferring from the domain part sounds very reasonable to me