On 15 May 2014 21:02, Goffi <[email protected]> wrote: > Hi, > > thanks for your feedback > > Le 2014-05-15 10:15, Dave Cridland a écrit : > >> I suspect Section 4.1 is entirely unnecessary - a component either >> needs admin rights or doesnt, and this would be provisioned within the >> server. >> > > > A component may need to know if it has privileges granted, e.g. to offer > different features (a PubSub service may enable or disable roster > access-model if it is privileged or not). > > Furhtermore, Binary suggested to use permission even in admin mode > (without user confirmation in this case): a server may want to only allow > "'jabber:iq:roster' get" to a component. We can use this phase to > aknowledge the component of which permissions are granted. > > We could possibly use a "do I have permission to do X" query, but I don't think we want a request.
> > >> Section 4.2 seems like a reasonable idea on the face of it. I wonder >> if we couldnt reuse stanza forwarding here. I dont think this needs to >> >> be limited to components, and I think the general processing by the >> server ought to be to send the stanza from target bare jid, relaying >> responses back, something like: >> >> <iq [email protected] [2] [email protected]/resource [3] >> type=set id=123> >> >> <privilege><!-- or something --> >> <forwarded> >> <iq [email protected] [4] type=get> >> >> <foo/> >> </iq> >> </forwarded> >> </privilege> >> </iq> >> > > > Indeed that's an option. Binary suggested that the <priviledge/> wrapping > is unnecessary: the top level <iq/> is enough, as we just need the bare jid > to know which client we want to access. The example 4 would then simply be: > > <iq from='pubsub.capulet.net' to '[email protected]' type='get' > id='roster1'> > <query xmlns='jabber:iq:roster'/> > </iq> > > That's the best way to access particular resources as the component, certainly. If you want to send stanzas as the bare jid, though, it won't work. > > I'm not sure to understand well you example, can you be more explicit > about which one it the component, which one the client, which one the > target ? Maybe a concrete use case would help here. > > In my examples, there's no component - a user's client is, here, wanting to send stanzas from the bare jid, in effect. A component might wish to send stanzas from other bare jids. As you say above, there's no need to do this to access, for example, the user's roster, but accessing, say a remote pubsub service as the user needs some kind of relaying. > > Section 5, I worry over - I dont think components which arent >> >> explicitly provisioned in the server are really going to work. That >> said, expanding the stanza relaying thing from Section 4.2 across to >> all clients probably works for most use cases. >> > > > Actualy that's a new step in decentralisation, and that's better for > security: A client can choose to host its own gateway or pubsub service, > sometimes it's the only way to do. For example the spectrum skype gateway > only works by wrapping skype client, which mean 50 mb memory on each > connexion. That's not acceptable for a production server with thousand of > accounts, but in this case a client can host the component himself. I think > component unliked to the server are needed. > > Right, but how does the component authenticate, how does the server know to route stanzas to it, who sets up the DNS, etc? I wouldn't let arbitrary domains be hosted unwittingly on my server, certainly. We can, though, have clients act as Skype gateways - that's entirely fine. > > The bit I was expecting to see, and didnt, was a protocol for trapping >> >> and/or intercepting specific namespaces. I think a small amount of >> expansion of Section 4.2 should do the trick, something like: >> >> <iq [email protected] [15] [email protected]/resource [16] >> type=set id=789> >> <privilege> >> <handle stanzas=* namespace=.../> >> </privilege> >> </iq> >> > > > That's already planned in a separate XEP that I need to write, « namespace > delegation ». The feature is not in privileged component because you may > want to delegate a namespace (e.g. vcard-temp) without giving privileged > access, it's an other thing. > OK.
