[Standards-JIG] Question about data form responses.
jd.conley at coversant.net
Wed Jan 19 18:45:38 UTC 2005
Our MUC Component has very similar ACL functionality. We send back an
error (not authorized, I think) and ignore the entire form. Any well
behaved x:data compatible client will only send in a form submittal
based on the form they received from the component server.
You are correct. There is nothing about this in the JEP. It does seem
to be an implementation detail. . .
> -----Original Message-----
> From: standards-jig-bounces at jabber.org [mailto:standards-jig-
> bounces at jabber.org] On Behalf Of Etan Reisner
> Sent: Wednesday, January 19, 2005 10:41 AM
> To: standards-jig at jabber.org
> Subject: [Standards-JIG] Question about data form responses.
> I'm working on modifying the ejabberd muc component to allow creating
> acls for individual muc config options. That is we want, for example,
> be able to limit who can create persistent rooms to certain classes of
> users. I've written all the acl code and ran into some questions when
> dealing with the room configuration forms. I have the component only
> include configuration options that a user is able to change in the
> when it is requested (I think this is the correct thing to do). The
> question is what should I do if the users client sends back a form
> includes even options that I do not allow them to set. As I see it I
> have a couple options:
> - I can ignore the entire request and return an error since they
> aren't following the form they were sent, however this could
> remove that users ability to configure rooms entirely since I assume
> their client will always send this incorrect form response.
> - I can ignore and drop the changes they are not allowed to make
> and allow the changes they are allowed to make to take effect, however
> this has the potential to be confusing and possibly generate a lot of
> invalid bug reports.
> - I can ignore and error on the changes they are allowed to make
> and allow the changes they are allowed to make to take effect, this
> would seem to be the best from usability standpoints since it avoids
> problems from both of the above options but I'm not sure that this is
> valid thing to do with these mechanisms.
> I'm not sure which of these (if any) is the right thing to do, thank
> for any guidance on this. I apologize if this is the wrong list for
> question, please anyone feel free to forward this to and respond on
> jdev list instead if that is more appropriate.
> P.S. I have read jep-0045 and jep-0004 but didn't see anything
> relating to this there, if there is somewhere else I should have
> please let me know.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards