Epost onboarding #79
No reviewers
Labels
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
datakollektivet/systemer!79
Loading…
Reference in a new issue
No description provided.
Delete branch "nettside-onboarding-mails"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Etter en del frem og tilbake så tror jeg en god approach til onboarding akkurat nå er at vi oppretter en hei@datakollektivet.no epostboks som en person manuelt følger med på og hjelper nye medlemmer med å bli invitert til riktig sted.
To store hensyn tas:
Datakollektivet har hatt behov for en epost i lang tid nå så jeg slår to fluer i en smekk og får det på plass sammen med nettsiden. Vi kommer til å bruke Gigahost sitt webhotell som epostleverandør. Uendelige epostkontoer for 20,- måneden. Dette er en midlertidig løsning som kun velkomstansvarlig og evt. styremedlemmer kommer til å ha tilgang til. Om noen ønsker å få på plass en skikkelig løsning så er vi åpent for det.
Det er tre flyter vi må håndtere:
Flyten som det er satt opp nå er at når en bruker fyller ut et av skjemaene så deler de epostadressen og annen informasjon. Skjemainformasjonen blir så sendt til "hei@datakollektivet.no" i et malverk som hjelper velkomstansvarlig med å svare raskt på henvendelsen. Ønsket er at det skal bare være å videresende eposten, endre til feltet, modifisere teksten litt og så sende det avgårde.
PII: Disse skjemaene her skaper PII. Altså, vi får epostaddresser som vi må behandle. Vi lagrer det ikke på serveren eller i Django og lagrer det i innboksen på Gigahost. Når vi kommer lenger i prosessen med SSO så kan vi nå ut til de vi har vært i kontakt med på epost (og har samtykket til det) og be dem registrere seg på SSO.
Todo:
@ -12,1 +7,4 @@ALLOWED_HOSTS = ['localhost', '127.0.0.1', 'testserver']# Flag if we're running testsuiteTESTING = len(sys.argv) > 1 and sys.argv[1] == 'test'Er ikke dette litt rart å ha i en fil for development som ikke skal brukes i test modus?
Det er noe litt off med "test" miljøet for øyeblikket. Egentlig er det tiltenkt noe nærmere produksjon der man kan teste building av static assets og docker pipelinen uten å deploye til en annen maskin. Kall det en form for lokal "staging". Det er ikke en stor og gjennomtenkt teststrategi satt opp her. Kun noen enkle unit tests som kan kjøres rett i python miljøet med
uv run manage.py testKommer til å ekspandere på test suiten når det kommer flere tester. Så kan man også finne en cleanere måte å håndtere integration testing eller tester ting som kjører i docker "test miljøet" som static build pipelinen.
@ -30,0 +36,4 @@'BACKEND': 'django.core.mail.backends.smtp.EmailBackend','OPTIONS': {'host': 'smtp.tem.scaleway.com','port': 587,Jeg tror du må bruker port
2465som vi bruker i auth.Grunnen til dette er at 2465 ikke er blokkert av Gigahost og at 2465 bruker implicit TLS som starter koblingen til serveren med TLS fra starten. 587 bruker explicit TLS som starter uten TLS og bruker en STARTTLS kommando for å oppgradere.
@ -30,0 +38,4 @@'host': 'smtp.tem.scaleway.com','port': 587,'use_tls': True,'username': os.environ.get('SCALEWAY_TEM_PROJECT_ID', ''),Er det ikke bedre å ha:
os.environ['SCALEWAY_TEM_PROJECT_ID'],slik at serveren ikke starter hvis konfigurasjonen ikke er på plass?@ -0,0 +23,4 @@}),)newsletter = forms.BooleanField(Hvor skal vi lagre folk som har meldt seg inn til å få nyheter?
Det blir lagret i Gigahost postboksen. Så kan en personal manuelt migrere de epostadressene når man har et bedre system for å håndtere epostlister. Regner med at vi ikke får så titalls mange eposter. Malen i Django må være søkbart slik at vi enkelt kan søke opp de som har akseptert det.
Alle eposten blir lagret i postboksen eller bare de som ønsker nyheter blir lagret der?
Alle eposter lagres i postboksen, både i inboxen (fra scaleway) og i utboksen når en person manuelt har svart brukeren. I praksis har brukeren bedt om å bli kontaktet på epost og jeg regner jo med at folk ikke forventer at vi tømmer inboksen og utboksen vår hver dag.
Når vi har et faktisk system for dette så kan vi manuelt gå gjennom epostene.
Men vi bør forme en retention policy på epostkontoen. For eksempel så bør alle "trivielle" eposter slettes etter ~12 måneder e.l. Det må egentlig bli en del av personvernspolicyen vår.
Om vi ikke har et system for at folk kan melde seg på en ordentlig nyhetsliste, synes jeg det er best at vi fjerner påmelding fra nettsiden frem til vi får det på plass. Ser at det fort kan bli litt kaos i en frivillig organisasjon
Jeg tror namingen og teksten her er litt forvirrende. Det er egentlig ikke snakk nyhetsbrev, det er samtykke til at vi kan kontakte medlemmet i fremtiden relatert til noe annet enn det de fyller ut skjemaet for (innlogging til Matrix/betaling/etc). Slik at vi kan sende en eller tre eposter i fremtiden med "Nå har vi SSO registrer nicket ditt her", og "Nå har vi et system for nyhetsbrev, double opt-in her". En liten checkbox folk sikkert huker av for gir oss samtykke til det. Uten det bør vi ikke bruke disse epostene til noe annet enn kun en transaksjonell epost. Ikke sikkert vi bruker det engang, kommer an på om vi får 3 eller 40 folk som vil følge oss.
UXen og copy rundt dette bør egentlig ikke være et hensyn til denne branchen. Det er ikke gjennomtenkt. Formuleringer og detaljer tas på innholdsmøtet på mandag og de neste ukene 😎
@ -0,0 +2,4 @@from django.template.loader import render_to_stringONBOARDING_INBOX = "hei@datakollektivet.no"DEFAULT_FROM_EMAIL = "noreply@datakollektivet.no"Hva er grunn til å bruke en noreply? Om noen ønsker å ta kontakt med oss bor det være mulig?
Dette er eposten fra Scaleway som går til hei@datakollektivet.no fra @nettside.datakollektivet.no domenet. Den tar ikke i mot epost.
@ -0,0 +31,4 @@class Command(BaseCommand):help = 'Send test onboarding notification emails for all join flows.'Er dette for å sjekke hvordan epostene ser ut?
Yes. Når jeg tenker meg om kan det kanskje slettes nå som vi har tester oppe. Ikke veldig verdifullt.
DNS oppføringer på Gigahost er satt opp. DKIM, DMARC og SPF er delvis satt opp. Om noen er klokere på hvordan dette fungerer og vil validere det så er jeg veldig åpen. Slik jeg forstår må vi sette en annen policy enn p=none; på dmarc og bør sette opp noe monitorering med rua=mailto: om vi endrer det til noe strengere.
Oppføringene er sånn ca i banen her (ikke ment som dokumentasjon, bare til info).
Nye oppføringer:
mail A → 193.200.229.150
mail AAAA → 2a03:94e0:325d::1
smtp A → 193.200.229.150
smtp AAAA → 2a03:94e0:325d::1
@ MX → mail.datakollektivet.no
_dmarc TXT → v=DMARC1;p=none;
x._domainkey TXT → DKIM public key
Endret på oppføring:
@ TXT (SPF):
Gammel: v=spf1 -all
Ny: v=spf1 a mx ip4:193.200.229.150 ip6:2a03:94e0:325d::1 ~all
Har ikke testet sånn veldig nøye om det fungerer men jeg får mottatt og sendt epost fra hei@datakollektivet.no.
Scaleway TEM er satt opp. DNS på gigahost er satt opp for "nettside.datakollektivet.no".
Det er verdt å nevne at det ikke var mulig å scope API access ned mot kun et domene så vi bruker nok Scaleway feil atm @gingermusketeer. Deres IAM er ganske umoden og vi bør nok bryte hvert system ut i et eget scaleway prosjekt i stedet for at vi har flere systemer inn i et prosjekt. Dette er lettere å håndtere om/når vi får Scaleway på Terraform.
Jeg renamet "test" til "staging". Test ga ikke mening. Jeg ønsker et miljø der jeg kan teste produksjonsting uten å deploye til produksjon.
For at det skal fungere så må staging ha tilgang til hemmeligheter i SOPS. Jeg landet på å bruke make og å eksportere SOPS secrets til compose miljøet på "make up". Jeg er svært skeptisk til å bygge .env filer lokalt nå om dagen nå som det lett blir slukt opp av LLMer. Åpen for andre approaches, endrer seg sikkert i fremtiden. Denne branchen er ikke tiltenkt å lage et skikkelig staging og test miljø med god logging - men å lage det jeg trenger for å teste TEM lokalt og få det til å fungere.
Bortsett fra bruk av prod secrets lokalt ser dette bra ut!
@ -24,3 +24,3 @@# Copy the application source code into the build context so we can build static files.ENV DJANGO_ENVIRONMENT=test# May be a good idea to make this work with production env instead.💯
@ -0,0 +32,4 @@VIRTUAL_HOST: nettside.localhostVIRTUAL_PORT: 8000SCALEWAY_TEM_PROJECT_ID: "1371d104-a4f2-4bea-8fa9-c75274064525"SCALEWAY_TEM_SECRET_KEY: ${SCALEWAY_TEM_SECRET_KEY}Jeg synes det er litt farlig å koble til produksjons TEM konto lokalt. Min erfaring er at det er best å holde lokale miljøer ryddig frakoblet. Med auth har jeg brukt https://github.com/dbck/docker-mailtrap i terraform-local/compose.yaml for å teste e-post lokalt.
Nå som jeg har et fungerende oppsett så er jeg ferdig med lokal testing mot scaleway. Har byttet over til å bruke mailtrap. Fiffig liten verktøy det.
@ -4,2 +4,4 @@django:secret_key: ENC[AES256_GCM,data:e4TgSURtN7VnV/qt89mmCWrKI1he1A65JH6c2QcXoT3qN77CIFjdoIxxUCl7oaYGXDabAOjHnyeVubflXaZD0vDfdg==,iv:FJoydW2p1zPzBTJ1Ehh5s+4+yakyH1md7tyf3K4AQbQ=,tag:smdhGox3mgIFAFhdA4qLow==,type:str]scaleway:tem_secret_key: ENC[AES256_GCM,data:8RgnKfB+2voaPFr2ea0sUJR4qUBvXL72/CtKs9yIlZNS+fUb,iv:slEPF3xFjfg31zNYxDXYPdLUZsCJz5Q+yoT0xm+MY6k=,tag:Mq0QF3EH0nPmYN3OyEGAIg==,type:str]Kan vi bruke samme struktur (navn på nøkler osv) for konfigurasjon som vi bruker i auth? Det blir lettere å vedlikeholde ting hvis vi gjør det mer likt.
Jeg snakket med Stigo på onsdag og han mente at vi bør ha så få secrets i SOPS som mulig. Grunnen til dette er at tilgang til Age nøkkelen gir deg tilgang til alle secrets vi har i repoet. Tenker at vi kan endre dette i alle systemer etter SSO er på plass.
We'll get there when we get there. 👍
Følger standarden satt der. Gjør det provider-agnostisk og kaller det smtp.username/password.
@ -13,0 +14,4 @@'BACKEND': ('django.core.mail.backends.locmem.EmailBackend'if TESTINGelse 'django.core.mail.backends.console.EmailBackend'Har du vurdert å bruke en liggende oppsett til auth/terraform-local som har en e-post container som tar i mot e-poster lokalt? Da kan man ha samme backend i dev og prod.
Det er et veldig godt spørsmål. Håndteres i den andre kommentaren din.
Her derimot så har jeg tydeliggjort hva som foregår. Jeg har lagd en ekte test.py environment. Den trigges når man kjører
manage.py test. Den bruker 'django.core.mail.backends.locmem.EmailBackend' som er en fullverdig epostserver som spinnes opp og ned for tester. Når man er bare i vanligmanage.py runserverså printes eposter bare til console med 'django.core.mail.backends.console.EmailBackend'.@ -0,0 +14,4 @@self.assertEqual(response.status_code, 200)self.assertContains(response, 'class="success"')self.assertEqual(len(mail.outbox), 1)Bør vi sjekke hva e-posten inneholder for å sikre at det er riktig e-post som blir sendt?
Tenkte det men åpnet det heller mer opp fordi teksten skal endres på stort videre.
@ -9,0 +13,4 @@## Generelt- [ ] Implementer Terraform/IaC for alle resourcene våre på Scaleway.- [ ] Flytt hvert system som bruker Scaleway ut i et isolert prosjekt ikke et delt prosjekt slik at vi blir mindre avhengig av fine-grained IAM policies som Scaleway ikke har implementert spesielt godt.Bra ide! Trenger vi å vente for Terraform å lage et prosjekt for nettsiden i Scaleway?
Agreed. Splitta ut i et eget "Nettside" prosjekt. Var ganske straightforward. Bør gjøres på Loomio, Kode, Auth og andre.
WIP: Epost onboardingto Epost onboardingTakk for review @gingermusketeer. Tror jeg har tatt det meste. Men fortsatt arbeid å gjøre kodebasen skikkelig god. Bedre testing, mer organisert config, bedre logging, ++. Kommer nok mer utover når nettsiden bygges videre.
Godkjenning før mandag er fint da kan vi ta skrive innhold basert på dette i main, om du er trygg på det!
Egentlig bør vi rate limite eposter. Kommer til det før vi går live. Satt det i todo.