Naar inhoud gaan
supastack
Blader door de docs

For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /nl/docs/web/github-sign-in.md (or send Accept: text/markdown).

GitHub-inloggen toevoegen

Maak een GitHub OAuth App per omgeving en verbind Doorgaan met GitHub met de app.

Walkthrough voor beginners

Vereisten: de webapp lokaal draaiend en een gemigreerde database voor echte accounts. U heeft een GitHub-account nodig — hetzelfde dat de repository bezit is prima. Gratis, ongeveer 5 minuten per omgeving.

Snelle begrippen: een GitHub OAuth App is de registratie waarmee GitHub gebruikers voor u aanmeldt. Anders dan de meeste providers staat één OAuth App precies één Authorization callback URL toe — dus lokaal (http://localhost:3000/…) en productie (https://yourdomain.com/…) hebben elk een eigen app nodig. Eén app hergebruiken en de callback heen en weer bewerken breekt elke keer één kant.

1. Maak een lokale OAuth App onder de Developer settings van uw account. 2. Kopieer de Client ID en genereer een Client Secret. 3. Stel de drie omgevingswaarden in en herstart. 4. Herhaal dit eenmaal met uw echte domein voordat u live gaat.

De lokale OAuth App aanmaken

1. Open github.com en meld u aan. Klik op uw profielfoto rechtsboven → Settings.

2. Scroll naar de onderkant van de linkerzijbalk en open Developer settings → OAuth Apps → New OAuth App.

3. Application name: iets als supastack local — gebruikers zien deze naam op GitHub's autorisatiepagina. Homepage URL: http://localhost:3000. Authorization callback URL: http://localhost:3000/api/auth/callback/github. Klik op Register application.

4. Kopieer op de pagina van de app de Client ID, klik op Generate a new client secret en kopieer het geheim onmiddellijk — GitHub toont het maar één keer, hoewel u altijd een nieuwe kunt genereren.

De productie-OAuth App aanmaken

Herhaal dezelfde New OAuth App-stappen met de naam van uw product, Homepage URL https://yourdomain.com en Authorization callback URL https://yourdomain.com/api/auth/callback/github.

Houd de inloggegevens van elke app in de eigen omgeving: het paar van de lokale app leeft in apps/web/.env.local, het paar van de productie-app in de geheimenopslag van uw host. Het lokale geheim mag productieconfiguratie nooit bereiken en vice versa.

De waarden aan de app toevoegen

Stel de drie regels hieronder in apps/web/.env.local in met de inloggegevens van de lokale app. AUTH_GITHUB_ENABLED=true zet de knop aan; het paar identificeert de OAuth App.

Het clientgeheim blijft alleen op de server — nooit in NEXT_PUBLIC_/EXPO_PUBLIC_-variabelen en nooit gecommit. Herstart de devserver na het bewerken.

Hergebruik geen GITHUB_APP_*-waarden die u elders tegenkomt — die horen bij een ongerelateerde GitHub App-integratie, niet bij gebruikerslogin. De docs/github-auth-setup.md van de kit loopt deze hele flow van begin tot eind door als u een tweede referentie wilt.

# apps/web/.env.local — from the LOCAL OAuth App
AUTH_GITHUB_ENABLED=true
GITHUB_CLIENT_ID=your-oauth-app-client-id
GITHUB_CLIENT_SECRET=your-oauth-app-secret

Verifiëren en problemen oplossen

Open http://localhost:3000/auth en klik op de GitHub-knop. Autoriseer de app op github.com en controleer dat u aangemeld terugkeert.

Totdat AUTH_GITHUB_ENABLED=true is ingesteld, blijft de GitHub-optie op /auth zichtbaar maar uitgeschakeld — controleer de namen in het env-bestand en herstart dan. De vlag instellen zonder zowel GITHUB_CLIENT_ID als GITHUB_CLIENT_SECRET laat het opstarten mislukken en noemt de ontbrekende variabele.

Een callback-mismatch is de gebruikelijke fout: de Authorization callback URL van de app moet exact gelijk zijn aan {APP_URL}/api/auth/callback/github — protocol, host, poort en pad. Een redirect_uri-fout na deployment betekent meestal dat het verzoek de inloggegevens van de lokale app raakte terwijl APP_URL productie aangeeft, of andersom.

Herstart de devserver na elke env-bewerking; waarden worden alleen bij het opstarten gelezen.

Veelgestelde vragen

14 vragen

Wat is supastack?

supastack is een modulair fundament voor het bouwen van SaaS-producten met AI. Het brengt gemeenschappelijke infrastructuur samen zodat jij je kunt richten op productspecifieke functies.

Ondersteunt het web en mobiel?

Ja. supastack bevat Next.js- en Expo-apps als startpunten voor web- en mobiele ervaringen.

Welke authenticatie is inbegrepen?

Better Auth dekt e-mail/wachtwoord, OTP en sociale login. Persoonlijke workspaces worden bij het account geprovisioneerd zodat productrecords vanaf dag één afgebakend blijven.

Hoe ondersteunt het AI?

supastack bevat configureerbare multi-provider AI, usage-tracking, budgetten en versleutelde bring-your-own-key-ondersteuning.

Hoe worden abonnementen afgehandeld?

Voor producten op de kit vormen Stripe-billing, abonnementen en entitlements het fundament voor betaalde toegang. Providersecrets blijven server-only.

Waar leeft mijn productspecifieke code?

Productspecifieke functies blijven in een aparte codebase terwijl het product de fundamentmodules van supastack configureert en integreert.

Hoe werkt de prijs van supastack?

De kit is een eenmalige aankoop met lifetime updates: One Framework voor $249 (tijdelijke lanceringsprijs — $100 korting op de normale prijs van $349) of All Frameworks (Next.js, iOS, Android) voor $499 (tijdelijke lanceringsprijs — $100 korting op de normale prijs van $599), plus $75 per extra developer seat. Geen kit-abonnement. Checkout op deze site levert je licentiesleutel per e-mail, met repositorytoegang via een GitHub-uitnodiging.

Hoe bakens workspaces mijn data af?

Records van gebruikers worden afgebakend per workspaceId. Identiteit, entitlements, AI-gebruik, billing-events en auditentries blijven binnen de grens van de persoonlijke workspace.

Hoe werken achtergrondjobs?

Trigger.dev is de expliciete jobruntime. Het JobRunner-contract belooft alleen enqueue, status en cancel — workflowsemantiek blijft Trigger.dev-specifiek en expliciet.

Hoe verschilt e-mail van outreach?

Transactionele e-mail dekt productworkflows zoals voltooiingsnotices. Koude outreach en campagnes zijn productzaken buiten de e-mailmodule van deze kit.

Hoe werken mobiele aankopen?

Mobiel bevat native aankopen en herstel via RevenueCat, met toegang die je server verifieert. Configureer de winkelaccounts en rond apparaattests af vóór publicatie. Webfacturatie blijft afzonderlijk.

Waar leven de AI-providerkeys?

Bring-your-own-key-credentials zijn versleuteld en blijven server-only. Keys worden uit logs gefilterd; gebruik en budgetten blijven zichtbaar op workspaceniveau.

Welke betaalmethoden accepteert de checkout?

De door Stripe gehoste checkout accepteert kaarten en kan ook Alipay en WeChat Pay aanbieden zodra die wallets op het Stripe-account zijn geactiveerd — handig voor kopers in China. Wallet-autorisaties worden asynchroon bevestigd, dus de licentiepagina wordt bijgewerkt zodra de betaling is afgerond.

Kan ik een terugbetaling krijgen?

Zodra je toegang hebt gekregen tot de repository, is supastack voor altijd van jou en kan er dus geen terugbetaling plaatsvinden. Maar wees gerust: je krijgt de volledige broncode met levenslange updates om onbeperkt producten voor jezelf of je klanten te bouwen en te lanceren. Je mag de code alleen niet doorverkopen of de repository herdistribueren als starterkit of template.

NL
Thema