[Standards] request for reviews: XEP-0045 v1.25rc5

Ralph Meijer ralphm at ik.nu
Tue Sep 6 14:17:23 UTC 2011


On Tue, 2011-09-06 at 15:37 +0200, Alexander Holler wrote:
> Am 06.09.2011 11:09, schrieb Ralph Meijer:
> > On Tue, 2011-09-06 at 09:24 +0200, Alexander Holler wrote:
> >> [..]
> >>
> >> I don't see any reason why the user should send a form to the server.
> >>
> >> If using a form is wanted, the correct way would be that the user
> >> requests a form for the request from the server, and sends back the
> >> result, which is then processed by the server (resulting in a form for
> >> the moderator).
> >>
> >> The described way where the user generates a form only makes sense, if
> >> that form is forwarded to the moderator. But that would result in the
> >> possible problems I've described (e.g. hidden fields and wrong labels).
> >
> > I don't see how requesting a form from the service first somehow makes
> > this better. An attacker could simply ignore that form and submit its
> > own bad one.
> 
> Whats the point that the user sends labels?
> 
> Where do the user gets the list of required fields from?

Ah, these are valid concerns. Looking into it in more detail, of course
the form for requesting voice, as shown in example 74 of XEP-0045
v1.25rc5, is of type 'submit'. The form sent to the moderator for
approval, as shown in example 103 is of type 'form', as at should be.
The latter is thus an entirely different one, with additional fields
muc#jid, muc#roomnick and muc#request_allow, constructed by the MUC
service.

You are taking the associated prose, that suggests to 'forward the
request', too literal.

The form sent by the user's client can be entirely constructed by the
client, without displaying it as such to the user. As it is of type
'submit', no labels are required. The required field is 'muc#role' and
the value is 'participant'. The type and label attributes should
probably be removed from the example.

Even thought this is currently not specified, future extensions could
define how an interaction might be, with additional fields required of
the user. Your suggestion of first requesting a form to get these fields
(as with registering a nick or configuring a room) seems the obvious
solution to that. If there is no immediate need for this, I suggest we
leave things as is, though.

--
ralphm






More information about the Standards mailing list