Din fremforge-konto
En fremforge-konto er din personlige identitet på plattformen. En organisasjon er en kunde som faktureres, et arbeidsområde der repositoryer, medlemmer, secrets, CI-kjøringer og policy hører hjemme. De to er bevisst atskilte begreper, og denne siden forklarer hva som ligger hvor, hvordan de virker sammen, og hvordan du fjerner hver av dem.
Én konto, mange organisasjoner
Du registrerer deg én gang. Du får én personlig konto på frem.sh/<your-username> med e-postadressen din, SSH-nøklene dine, de personlige tilgangstokenene dine, tofaktorautentiseringen din og det lokale passordet ditt (hvis du har satt et). Uansett hvor du autentiserer deg mot fremforge, i grensesnittet, i Git eller i API-et, autentiserer du deg som den kontoen.
Medlemskap i en organisasjon er et eget forhold. Den ene kontoen din kan være medlem av null, én eller mange organisasjoner. Hver organisasjon betaler for deg som en egen bruker. Organisasjonene du hører til, ser du i organisasjonsvelgeren i grensesnittet.
To konsekvenser som er verdt å ta inn over seg:
- Å fjerne deg fra en organisasjon sletter ikke kontoen din. Administratorer i en organisasjon kan når som helst fjerne deg fra organisasjonen sin. Det tilbakekaller tilgangen din til repositoryene deres og trekker én betalt bruker fra antallet deres, men den personlige kontoen din består, og du kan bli med i andre organisasjoner.
- Å slette kontoen din sletter ikke organisasjonene du hører til. Hvis du er eneste eier av en organisasjon, krever plattformen at du enten utpeker en annen eier eller sier opp organisasjonen helt før forespørselen om å slette kontoen kan fullføres.
Bli med i en organisasjon nummer to
Du kan være administratoren som oppretter mer enn én fremforge-organisasjon uten å lage flere kontoer. To tilfeller:
- Samme e-postadresse, ny registrering. Hvis du registrerer en ny organisasjon på
frem.sh/_app/signupmed en e-postadresse som allerede har en fremforge-konto, oppdager registreringsflyten den eksisterende brukeren, gjenbruker den og legger deg til som Owner i den nye organisasjonen. Du får ikke et passord til: den eksisterende innloggingen din virker for begge organisasjonene, og knappen i velkomst-e-posten heter «Åpne<slug>→» (logg inn med det eksisterende passordet ditt) i stedet for engangslenken «Logg inn i fremforge →» som en helt ny administrator får. (Ingen velkomst-e-post fra fremforge inneholder noen gang et passord.) - Invitert til en eksisterende organisasjon. Hvis en annen administrator inviterer e-postadressen din, godtar du invitasjonen fra
frem.sh/user/notificationsog blir lagt til som medlem av organisasjonen deres. Ingen konto nummer to, intet passord nummer to.
Hver organisasjon har sitt eget faktureringsforhold med fremverk, sitt eget antall brukere, sin egen Mollie-fullmakt, sine egne fakturaer og sin egen adminflate på frem.sh/<slug>/_admin/billing. Det finnes ingen samlet faktura på tvers av organisasjoner.
Bytte mellom organisasjoner
Det finnes ingen organisasjonsvelger i produktet på frem.sh/_app; adminflaten per kunde styres av slugen i URL-stien (/<slug>/_admin/...). Den naturlige velgeren ligger på Forgejo-siden på frem.sh:
- Logg inn på
frem.sh/user/login(eller klikk «Sign in» hvor som helst på markedsføringsnettstedet, som sender deg viafrem.sh/_app/loginfor å finne riktig innlogging ut fra e-postdomenet; se Slik fungerer innlogging). - Dashbordet ditt viser hver organisasjon du hører til. Klikk deg inn i en av dem for å begynne å jobbe med repositoryer, issues, CI og innstillinger.
- For å åpne fremforge-administrasjonen (fakturering, SSO, medlemmer) for en bestemt organisasjon går du til
frem.sh/<slug>/_admin/billing. Det vanligste er å lagre et bokmerke til admin-URL-en for hver organisasjon du administrerer.
Sesjonsbinding per organisasjon er slått på som standard for alle kunder. Første gang du åpner adminflaten til en organisasjon, sender fremforge deg gjennom en innloggingsrunde for den organisasjonen og holder en registrering per organisasjon av den i opptil 8 timer. Hva runden beviser, avhenger av nivået nedenfor. Med myk binding beviser den at nettleseren din har en gyldig innlogging, ikke at du nettopp logget inn på nytt. Bare hard binding får deg til å autentisere deg på nytt.
Målet for runden er Forgejos felles innlogging på frem.sh/user/login, ikke en SSO-URL per organisasjon. Det er med vilje: den felles innloggingen godtar både alle SSO-knapper som er satt opp, og lokalt passord med tofaktorautentisering. Det bevarer Break-glass for SSO-veien (nødtilgang): hvis IdP-en din ikke kan nås, kan en eier av organisasjonen med lokal innlogging og tofaktorautentisering fortsatt autentisere seg, passere bindingen per organisasjon og nå organisasjonsadministrasjonen. En omvei gjennom en SSO-URL per organisasjon ville skapt et enkelt feilpunkt (organisasjonens IdP), og det er nettopp det break-glass-utformingen skal unngå.
To styrkenivåer, avhengig av hvordan IdP-en din er koblet til:
- Myk binding (standard, break-glass med lokal innlogging bevart): en registrering per organisasjon av hvem som brukte adminflaten til hver organisasjon og når, og en runde via Forgejo første gang du åpner hver organisasjon. Hvis Forgejo-sesjonen din er gyldig, er runden usynlig og ber ikke om noe: den beviser at du har sesjonen, ikke at du nettopp har autentisert deg. Hvis sesjonen ikke er gyldig, logger du inn på nytt. Målet for omdirigeringen er
frem.sh/user/login, som godtar lokalt passord med tofaktorautentisering, så et brudd hos IdP-en låser ikke eierne av organisasjonen ute. - Hard binding (regulerte arbeidslaster): tvunget ny bekreftelse hos IdP-en per organisasjon via OIDC
prompt=login. Runden blir en reell autentisering bekreftet av IdP-en og avgrenset til den organisasjonen. IdP-en MÅ be om innlogging og MFA på nytt, og callbacken vår kontrollerer atauth_timeer innenfor de siste 5 minuttene. Settes opp ved at du registrerer en OIDC-klient nummer to i IdP-en ved siden av Forgejo-klienten (samme utsteder, egen client_id og client_secret) og limer inn legitimasjonen under Organisasjonsadministrasjon → SSO.
Begge nivåene bevarer Break-glass for SSO-veien: eiere av organisasjonen med lokalt passord og tofaktorautentisering kan komme seg gjennom ethvert brudd hos IdP-en. Hard binding tvinger bare fram ny autentisering hos IdP-en mens organisasjonens IdP kan nås. Hvis IdP-en ikke kan nås, virker den eksisterende break-glass-prosedyren din fortsatt.
SSO på tvers av flere organisasjoner
Hver organisasjon kobler til sin egen IdP under Organisasjonsadministrasjon → SSO. Brukere logger inn i en bestemt organisasjon med organisasjonens <auth-source-name>-knapp på frem.sh/user/login?redirect_to=/<slug> (eller via oppslagsflyten på frem.sh/_app/login, som sender deg til innloggingssiden til riktig organisasjon ut fra domenet i e-postadressen din).
Hvis du er medlem av to organisasjoner som bruker forskjellige IdP-er, autentiserer du deg via den IdP-en du kommer inn gjennom; når Forgejo-sesjonen din er etablert, virker navigeringen mellom organisasjonene som beskrevet over. Hvis begge organisasjonene bruker samme IdP (for eksempel to forretningsenheter på samme Authentik-kunde), holder én autentisering for begge.
Første gang du går inn i en annen organisasjon, blir du sendt én runde. Hvor runden går, avhenger av om organisasjonen har satt opp hard binding (en OIDC-klient for ny autentisering):
- Organisasjon med hard binding: runden går til
frem.sh/<slug>/_admin/-/stepup, som starter en OIDC-autentiseringsforespørsel medprompt=loginmot organisasjonens klient for ny autentisering. IdP-en ber om innlogging og MFA på nytt, callbacken kontrollerer ID-tokenet og atauth_timeer fersk, og du havner på den opprinnelige URL-en med en ny registrering av sesjonen for organisasjonen. - Organisasjon med myk binding: runden går til
frem.sh/user/login. Forgejos felles innlogging viser de autentiseringskildene som er tilgjengelige: lokalt passord med tofaktorautentisering alltid, pluss organisasjonens SSO-knapp når den er satt opp. Hvis den eksisterende Forgejo-sesjonen din er fersk, følger siden bareredirect_touten å be om noe.
Begge nivåene lar break-glass med lokal innlogging være urørt. En eier av organisasjonen med lokalt passord og tofaktorautentisering på Forgejos felles innlogging kan komme seg gjennom ethvert brudd hos IdP-en; bindingen per organisasjon endrer ikke det.
Data på kontonivå og på organisasjonsnivå
Dette er skillelinjen som avgjør hvem som kontrollerer hva etter GDPR, og hvor du finner hvilken innstilling.
| Data | Ligger på | Behandlingsansvarlig | Hvor det administreres |
|---|---|---|---|
| E-post, visningsnavn, passordhash | Konto | fremverk ApS | Brukerinnstillinger → Sikkerhet og innlogging |
| SSH-nøkler, GPG-nøkler | Konto | fremverk ApS | Brukerinnstillinger → SSH- / GPG-nøkler |
| Personlige tilgangstokener | Konto | fremverk ApS | Brukerinnstillinger → Git-tilgangstokener |
| Registrering av tofaktorautentisering og gjenopprettingskoder | Konto | fremverk ApS | Brukerinnstillinger → Sikkerhet og innlogging |
| Lokalt passord (når SSO også er satt opp) | Konto | fremverk ApS | Brukerinnstillinger → Sikkerhet og innlogging |
| OIDC-kobling | Konto, avgrenset per organisasjon | Eier av organisasjonen + IdP | Organisasjonsadministrasjon → SSO |
| Repositoryer, issues, PR-er, wiki | Organisasjon | Organisasjonen (kunden) | Organisasjonsadministrasjon / innstillinger for repositoryet |
| Secrets, runnere og policy på organisasjonsnivå | Organisasjon | Organisasjonen (kunden) | Organisasjonsadministrasjon |
| Revisjonslogg | Organisasjon | Organisasjonen (kunden) | Revisjonslogg |
| Fakturering, fakturaer, betalingsmåte | Organisasjon | Organisasjonen (kunden) | Organisasjonsadministrasjon → Fakturering |
Data på kontonivå er regulert av personvernerklæringen for produktet; fremverk ApS er behandlingsansvarlig. Innhold på organisasjonsnivå er regulert av databehandleravtalen; organisasjonen din er behandlingsansvarlig, og fremverk er databehandler på dens vegne.
Referanse for kontoinnstillinger
frem.sh/user/settings er flaten for personlige innstillinger, levert av Forgejo. De relevante undersidene:
- Profil: navn, e-post, avatar, språkvalg.
- Sikkerhet og innlogging: lokalt passord, tofaktorautentisering, gjenopprettingskoder, sletting av kontoen. Se Tofaktorautentisering.
- SSH-nøkler og GPG keys: offentlige nøkler for Git-operasjoner og commit-signering.
- Git-tilgangstokener: personlige tilgangstokener (PAT-er). OAuth-applikasjoner du har autorisert, ser og tilbakekaller du på
frem.sh/user/settings/applications, som ikke har noen oppføring i innstillingsmenyen. - Varsler: innstillinger for varsler på e-post og i appen.
Via REST API
Noen få operasjoner på kontonivå er også tilgjengelige i det offentlige REST API-et. Det er nyttig når du skripter oppstart av CI, bekrefter hvilke organisasjoner et token kan handle i, eller roterer PAT-er fra en automatisering.
- Les profilen din og medlemskapene i organisasjoner
GET /_app/api/v1/users/me - Utsted et personlig tilgangstoken
POST /_app/api/v1/auth/tokens - List de aktive tokenene dine
GET /_app/api/v1/auth/tokens - Tilbakekall et token
DELETE /_app/api/v1/auth/tokens/:tokenId
Autentiser med et personlig tilgangstoken (PAT) som Authorization: Bearer ${FREMFORGE_PAT}. For å utstede et nytt PAT kreves en aktiv innlogget sesjon i admingrensesnittet; scopet til tokenet som utstedes, kan ikke gå ut over rollen din.
curl -H "Authorization: Bearer ${FREMFORGE_PAT}" \
https://frem.sh/_app/api/v1/users/meSe referansen for det offentlige REST API-et for hele OpenAPI-spesifikasjonen.
Grensesnittene for den personlige kontoen over (SSH-nøkler, GPG-nøkler, registrering av tofaktorautentisering, sletting av kontoen) er bevisst ikke tilgjengelige i det offentlige REST API-et. Det er handlinger med personlig legitimasjon som av sikkerhetshensyn krever en innlogget nettlesersesjon.
Slette fremforge-kontoen din (retten til sletting etter GDPR)
Etter GDPR art. 17 har du rett til å få personopplysningene dine slettet, med begrensede unntak for lovpålagte oppbevaringsplikter. fremverk ApS støtter denne retten som behandlingsansvarlig for kontodataene dine.
Hva du kan slette selv
User settings → Security & sign-in → Delete account. Sletting med selvbetjening:
- Fjerner deg fra hver organisasjon du er medlem av. Antallet brukere i hver berørt organisasjon reduseres ved neste faktureringsperiode.
- Gravlegger brukernavnet ditt, slik at det ikke kan registreres på nytt (dette hindrer at noen utgir seg for å være deg i historiske commits og oppføringer i revisjonsloggen).
- Sletter de personlige kontodataene dine permanent: profil, SSH-nøkler, GPG-nøkler, PAT-er, tofaktor-secret, hasher av gjenopprettingskoder og varselinnstillinger. Innen 30 dager; sletting fra sikkerhetskopier innen ytterligere 30 dager etter databehandleravtalen §9.
- Bevarer de historiske bidragene dine: forfatterattribusjon i commits, forfatterskap av issues og PR-er, kommentarer og oppføringer i revisjonsloggen som nevner deg. Å fjerne disse ville ødelagt hver organisasjon som er avhengig av disse registreringene som bevis på hvem som gjorde hva. Brukernavnet ditt vises som
<deleted-account>i grensesnittet, mens den underliggende referansen til bruker-id-en (et stabilt heltall) holder revisjons- og Git-historikken intakt.
Hva som krever support
To tilfeller krever at du går via compliance@frem.sh:
- Du er eneste eier av en organisasjon. Sletting med selvbetjening er blokkert. Enten utpeker du en annen eier via Organisasjonsadministrasjon → Medlemmer og sletter deretter kontoen din, eller du skriver til compliance@frem.sh og ber om at organisasjonen og kontoen slettes samtidig.
- Du vil at historiske bidrag aktivt skal skrives om. Standard er å bevare attribusjonen under et gravlagt brukernavn. Hvis du har et dokumentert rettslig grunnlag for en sterkere sletting (for eksempel et endelig navnebytte som fremgår av rettsdokumenter), sender du en e-post til compliance@frem.sh med grunnlaget. Hver forespørsel vurderes for seg opp mot begrensningene i GDPR art. 17(3).
Hva vi ikke sletter på forespørsel
Etter GDPR art. 17(3) kan følgende oppbevares etter at kontoen er slettet:
- Fakturerings- og fakturaopplysninger for organisasjoner du var knyttet til, oppbevart i 5 år etter dansk bokføringslov (Bogføringsloven).
- Oppføringer i revisjonsloggen om sikkerhet og misbruk der oppbevaring er nødvendig for å fastsette, gjøre gjeldende eller forsvare rettskrav, eller for å oppfylle en rettslig forpliktelse (for eksempel rapporter om misbruk etter DSA art. 16, som oppbevares i 5 år etter personvernerklæringen §6).
- Samlede, anonymiserte driftsmålinger, som ikke kan identifisere deg og faller utenfor GDPRs begrep om personopplysninger.
Bekreftelse før sletting
Sletting av kontoen er destruktiv og kan ikke angres. Selvbetjeningsflyten krever at du autentiserer deg på nytt (lokalt passord, eller en ny autentisering hos IdP-en hvis du bare bruker SSO) og bekrefter ved å skrive inn brukernavnet ditt, det samme mønsteret i Forgejo som brukes når et repository slettes. En bekreftelse sendes på e-post når du sender inn forespørselen, og igjen når perioden for sletting fra sikkerhetskopier er over.
Reaktivering
Når slettingen er fullført, kan kontoen ikke reaktiveres. Brukernavnet er reservert mot den slettede bruker-id-en for å beskytte den historiske attribusjonen, så du kan ikke registrere det samme brukernavnet på nytt med en ny registrering. Hvis du trenger å bruke fremforge igjen, registrerer du deg med en ny e-postadresse og et annet brukernavn.
Se også
- Medlemmer og team, administrere medlemskap i organisasjonen fra organisasjonsadministrasjonen
- Tofaktorautentisering, oppsett og gjenoppretting av tofaktorautentisering på kontonivå
- Organisasjonsadministrasjon, flaten for innstillinger på organisasjonsnivå
- Koble til, SSH-vertsnøkler, bekreftelse av fingeravtrykk, reserveløsning via port 443
- Personvernerklæring for produktet, det rettslige grunnlaget for behandling av kontodata og de registrertes rettigheter etter GDPR