You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To make Join Forms available to a wide audience, removing the need for any programming, we should create an HTML renderer here along with server-side submission of the form to the API.
For the API to accept a join form submission, a valid submit_token must be supplied. This token must not be publicly shared. For organizations which implement their own forms this is easily achieved by embedding the token somewhere on the server side.
submit_token for procedural forms
For www, which would render forms "procedurally", there is nowhere to store this token. It can't be received from the API, which is accessed anonymously. To solve this, I propose encrypting the token using a server-side secret (shared for all organizations and forms) and putting it in the URL, e.g.:
This URL would be created and shared with officials through Organize (which would need to share the encryption key with www, which is easily done since we control both deployments).
The last portion of the URL, let's call it form_meta would need to be decrypted by WWW using the shared secret key, and include everything needed to retrieve and submit the form, e.g.:
Organization ID
Form ID
Submit token
High-level flow
When requested, the server would decrypt the form_meta and retrieve the form configuration from the API. It would then verify that it's renderable, and render HTML along with a CSRF token.
The render logic would also respect the embeddable property of the form, either via an X-Frame-Options header or via javascript on the client side (which would allow a nice error message to be shown).
When the user submits the form, the server would take the necessary steps to prevent CSRF, and again decrypt the form_meta to be able to make a valid POST to the submission API.
The text was updated successfully, but these errors were encountered:
To make Join Forms available to a wide audience, removing the need for any programming, we should create an HTML renderer here along with server-side submission of the form to the API.
For the API to accept a join form submission, a valid
submit_token
must be supplied. This token must not be publicly shared. For organizations which implement their own forms this is easily achieved by embedding the token somewhere on the server side.submit_token
for procedural formsFor www, which would render forms "procedurally", there is nowhere to store this token. It can't be received from the API, which is accessed anonymously. To solve this, I propose encrypting the token using a server-side secret (shared for all organizations and forms) and putting it in the URL, e.g.:
https://www.zetk.in/join/vansterpartiet-malmo/Bn1MXVsrqkZkbaBCh8m-1nE363Uw_5nFmFRRlxNNcf0
This URL would be created and shared with officials through Organize (which would need to share the encryption key with www, which is easily done since we control both deployments).
The last portion of the URL, let's call it
form_meta
would need to be decrypted by WWW using the shared secret key, and include everything needed to retrieve and submit the form, e.g.:High-level flow
When requested, the server would decrypt the
form_meta
and retrieve the form configuration from the API. It would then verify that it'srenderable
, and render HTML along with a CSRF token.The render logic would also respect the
embeddable
property of the form, either via anX-Frame-Options
header or via javascript on the client side (which would allow a nice error message to be shown).When the user submits the form, the server would take the necessary steps to prevent CSRF, and again decrypt the
form_meta
to be able to make a validPOST
to the submission API.The text was updated successfully, but these errors were encountered: