Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Render Join Forms for embedding #279

Open
richardolsson opened this issue Oct 23, 2020 · 1 comment
Open

Render Join Forms for embedding #279

richardolsson opened this issue Oct 23, 2020 · 1 comment
Labels

Comments

@richardolsson
Copy link
Member

richardolsson commented Oct 23, 2020

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.:

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.:

  • 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.

@richardolsson
Copy link
Member Author

Postponing until after #277

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant