Mitgliedsantrag

[jstet]

what does the law say? make it so that data will be saved in memory of client?

[jstet]

spam protection

[jstet]

Form on website and send email to finanzen@ with email template

[jstet]

On Slack we agreed to send a notification email to finanzen@ containing an id or the name of the person but to upload the data directly to Nextcloud via their API. This avoids storing the data in emails on google servers. @friep already wrote some code to achieve this and sent it to me on Slack.

[jstet]

Will work on this after first release. We can use the old form till then. However is this something we can do not serverside/with a static website (#100)? This involves secrets tokens like access to Nextcloud.

[friep]

I did some research on the legal conditions of this:

1. SEPA In Germany, it's not strictly necessary that people sign the SEPA mandate (cf: https://www.haendlerbund.de/de/ratgeber/recht/3941-sepa-umstellung, https://www.vr.de/privatkunden/unsere-produkte/was-ist-ein-girokonto/sepa/sepa-lastschrift.html ) but there's no clear law text about it and other sources say it's necessary (e.g. https://www.novalnet.de/payment-lexikon/formular-sepa-lastschrift-nur-mit-unterschrift-gueltig)

2. Mitgliedsantrag: our Satzung only says: "Aktive Mitglieder erlangen die Mitgliedschaft durch einen schriftlichen Aufnahmeantrag, über den der Vorstand mit einfacher Mehrheit entscheidet." (and similar for Fördermitglieder) . I googled whether this requires a signature and again, while there is no strict legal need, it's "safer" to have something signed by the person.

FOr both, i'd take the safe route and require the signuture/ proper "written form".

Overall, to make this easiest for the user, maybe we could do something like:

1. form where user enters their data
2. button or "next" to generate the PDF document(s) (ideally client-side?) -> user just has to sign them.
3. upload documents via form. Process then directly to nextcloud or store on directus first.

[friep]

i talked to @jandix and he said that it should be possible to do something like 2. with https://github.com/parallax/jsPDF

[jstet]

todo von Sabrina: "Mir ist eben aufgefallen, dass die EN Übersetzung der Mitgliedschaft meiner Meinung nach nicht vollständig ist: es fehlt in der EN Version bei "Fördermitgelid/Sustaining membership" der Hinweis zum Betrag ("frei wählbar, mindestens 30 Euro / Jahr") und "Fördermitglieder sind in der Mitgliederversammlung nicht stimmberechtigt.” https://www.correlaid.org/en/community/become-member/"

[jstet]

182 : refactor membership application page to not use svelte-kit form actions

[jstet]

Plan for automating the membership application

Objective: Develop a secure process to upload membership application PDFs to Nextcloud while processing user data client-side on our static SvelteKit website. Since the website is static and we can't perform server-side operations directly, we need to leverage external services to achieve this functionality.

Client-Side Form and PDF:

• Create a form for membership application data
• Secure the form with something like Turnstile
• Utilize JavaScript to gather and process user data, generating PDFs with the jsPDF
• Users can download the generated PDF to sign it.

• Allow users to submit their completed application with the signed PDFs.

  Intermediary API:

• Develop a backend API service responsible for receiving PDFs from the SvelteKit frontend.
• Store necessary authentication tokens securely within the API.
• implement logic to securely upload PDFs to Nextcloud using webdav.
• Host: Digital Ocean Functions

Feedback and User Notification:

• Upon successful Nextcloud upload, have the intermediary API notify the SvelteKit frontend.

@friep @KonradUdoHannes @jandix Thoughts?

[jandix]

@jstet looks good to me. As the PDF could be tempered with you probably could store some metadata like the upload time in a database? This could also include the Nextcloud transaction metadata and would allow you to keep track of failed jobs.

[KonradUdoHannes]

Generally it looks like a good strategy, at the same time I have the following remarks

• if integrating jsPDF in in svelte-kit for client side use is too much trouble we could also provide this functionality via the intermediary API. Since we have to make that API connection private anyways, there is conceptually not too much overhead. Also website load time might be a little better.
• In the suggested solution with client side pdf creation I'm not sure we need to secure the Form with a Turnstile or similar. There is not DOS attack vector here if the work happens client side. I think we only need to worry about securing the Intermediary API, so basically secure the "upload pdf" button not the "create pdf" button
• We have to see how to best notify the frontend which can possibly get a little complex.
  • we can wait for the response of the POST request as confirmations. Here the problem is that these requests time out eventually (usually after 1 min) so if our background processing, i.e. the connection from the server to nextcloud, takes too long (not sure how high the risk here really is) the request might time out even though the pdf was received and is still being processed.
  • We can establish a websocket connection (possibly through our service worker). Through this connection we can push a confirmation from the serverside and don't have to worry about timeouts as much. While safer connection wise this is a bit more complex to implement.
  • Alternatively we could send email confirmations from the backend services directly to the user instead of the frontend.

[jstet]

I created a new repo for the intermediary API here: https://github.com/CorrelAid/membership_application_uploader

[jstet]

Thanks for your advice @jandix @KonradUdoHannes ! I have kind of finished the intermediary API (see repo) but I am wondering if its secure enough as it provides a direct way to upload pdfs to our nextcloud. How can we avoid people automating post requests and using all our nextcloud storage with fake pdfs? the nextcloud token is stored securely but i fear that we have just upstreamed the problem. I implemented some functionality that stores the email of the member and restricts multiple requests with that email. Rate limiting relative to IP?

[KonradUdoHannes]

I think we should aim for the following.

• bot protection with a turnstile or similar, not sure how this works exactly the bot protection service would probably generate some kind of token that our API would then expects such that uploads only happen when a valid token is provided.
• size limit on the payload (as small as possible given that its still usable)
• temporary IP blocking in case too many requests com from the same IP in a short period of time (so basically rate limiting as you suggested)
• Check that email addresses are correctly formatted email addresses. (Very little protection but most likely very easy to implement)

[jstet]

Yes turnstile seems to be a good option! https://www.troyhunt.com/fighting-api-bots-with-cloudflares-invisible-turnstile/

I'll implement the other stuff as well

[jstet]

So API should be done and relatively secure now. Now we need to create the form on the website.

[jstet]

Update

Change still happen in the branch 94-mitgliedsantrag

The form works now and is connected to the API. However, I have not added the feature that people can download the pdf and then upload it with a signature. Instead, consent is given through a text input field.

Take a look at this form: https://kletterfreunde-wicker.de/online-mitgliedsantrag/

Here, all consent is just given with checkboxes. The form was built with a trustworthy provider (campai) that should know what is legal. I have also asked myself how to realize accessible signatures. People that use screenreaders can't sign stuff with drawing their names. Solutions for this problem are too sophisticated.

If we keep this form of consent, we may not need to generate and upload a pdf. We could just add a row to a csv or upload a json or smth as the pdf does just contain data now.

I also don't know how to properly test all the stuff that I implemented because so much verification is going on in between the steps. @KonradUdoHannes

I will add a feature to the api that sends an email to finanzen@ to notify a new application. I could also send a notification to the user with the generated pdf to let them know everything worked.

All of this is way too much work/time for this simple goal tbh, but now i got so far already :D

@friep

[KonradUdoHannes]

I'll have a closer look next week give some feedback on how what makes sense to test on our end.

[KonradUdoHannes]

I've looked through the branch and made a couple of notes, but I think it might be easiest if we already make a PR and I put my comments in there. That way I can more easily put them next to the code where they belong. We could even mark the PR as a draft until its ready if we want to, but since there is probably nobody around who could accidentally merge it, it would not do extremely much.

[jstet]

Thats reasonable, heres the PR: https://github.com/CorrelAid/correlaid_website/pull/585

[jstet]

Used an external provider and linked it in footer: https://easyverein.com/public/correlaid/applicationform/7737