* 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. Marc was also kind enough to provide a PR for the element-vs-form change at https://github.com/xsf/xeps/pull/585 Kind regards, Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
