On Mittwoch, 21. Februar 2018 19:42:19 CET Georg Lukas wrote: > * Jonas Wielicki <jo...@wielicki.name> [2018-01-25 15:57]: > > > However, then we need to define how the client can determine whether > > > this Data Form is a PREAUTH compatible form, and whether the user is > > > still required to add more content. > > > > This can easily be done. Just specify the field @var. If the form has a > > field with that specified @var, hide it from the UI and insert the > > preauth token automatically on submit. > > This is not overly complex logic, but it requires a full data forms > display in the client, and then manipulation of the form before display, > plus addition of a hidden field when sending the response. And then we > also have to solve the i18n issue with the field names. > > The alternative would be to perform a full mapping of the returned form > fields to 'username', 'password', 'token' [, 'email'], and to display the > client-intergrated original account creation dialog if these were the > only fields that were sent in the form. > > But we need to extend the IBR flow anyway, so I don't really see a > compelling reason to use data forms here as opposed to an additional XML > element in the 'jabber:iq:register' block.
I understand, and what you say (finally, I think you tried to express that multiple times, but I didn’t get it) makes sense to me. I wonder whether it still might sense however to use a Data Form to have a specified way how services can extend the form with additional fields. kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
