Pular para o conteúdo
supastack
Explorar a documentação
WebNext.js

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 /pt/docs/web/github-sign-in.md (or send Accept: text/markdown).

Adicionar o início de sessão com GitHub

Crie uma OAuth App do GitHub por ambiente e ligue «Continuar com GitHub» à app.

Passo a passo para iniciantes

Pré-requisitos: a app web a correr em local e um banco de dados migrado para contas reais. Precisa de uma conta GitHub — a que possui o repositório serve. Gratuito, cerca de 5 minutos por ambiente.

Terminologia rápida: uma OAuth App do GitHub é o registo que permite ao GitHub iniciar a sessão dos utilizadores por si. Ao contrário da maioria dos provedores, uma OAuth App permite exatamente uma Authorization callback URL — logo, local (http://localhost:3000/…) e produção (https://yourdomain.com/…) precisam cada uma da sua própria app. Reutilizar uma app alternando o callback entre ambientes parte um lado de cada vez.

1. Crie uma OAuth App local nas Developer settings da sua conta. 2. Copie o Client ID e gere um Client Secret. 3. Defina os três valores de ambiente e reinicie. 4. Repita uma vez com o seu domínio real antes de ir para o ar.

Criar a OAuth App local

1. Abra github.com e inicie sessão. Clique na sua foto de perfil no canto superior direito → Settings.

2. Desça até ao fim da barra lateral esquerda e abra Developer settings → OAuth Apps → New OAuth App.

3. Application name: algo como supastack local — os utilizadores veem este nome na página de autorização do GitHub. Homepage URL: http://localhost:3000. Authorization callback URL: http://localhost:3000/api/auth/callback/github. Clique em Register application.

4. Na página da app, copie o Client ID, clique em Generate a new client secret e copie o segredo de imediato — o GitHub só o mostra uma vez, embora possa sempre gerar outro.

Criar a OAuth App de produção

Repita os mesmos passos de New OAuth App com o nome do produto, Homepage URL https://yourdomain.com e Authorization callback URL https://yourdomain.com/api/auth/callback/github.

Guarde as credenciais de cada app no seu próprio ambiente: o par da app local vive em apps/web/.env.local, o par da app de produção no cofre de segredos do seu host. O segredo local nunca deve chegar à configuração de produção nem vice-versa.

Adicionar os valores à app

Preencha as três linhas abaixo em apps/web/.env.local usando as credenciais da app local. AUTH_GITHUB_ENABLED=true ativa o botão; o par identifica a OAuth App.

O client secret fica apenas no servidor — nunca em variáveis NEXT_PUBLIC_/EXPO_PUBLIC_ e nunca no Git. Reinicie o servidor de desenvolvimento depois de editar.

Não reutilize valores GITHUB_APP_* que possa ver noutro lado — pertencem a uma integração de GitHub App sem relação, não ao início de sessão de utilizadores. O docs/github-auth-setup.md do kit percorre todo o fluxo de ponta a ponta se quiser uma segunda referência.

# 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

Verificar e resolver problemas

Abra http://localhost:3000/auth e clique no botão do GitHub. Autorize a app em github.com e confirme que regressa com sessão iniciada.

Enquanto AUTH_GITHUB_ENABLED=true não estiver definido, a opção GitHub em /auth permanece visível mas desativada — verifique os nomes do ficheiro env e reinicie. Definir a flag sem GITHUB_CLIENT_ID e GITHUB_CLIENT_SECRET faz o arranque falhar e nomeia a variável em falta.

Um callback mal correspondido é a falha habitual: a Authorization callback URL da app deve ser exatamente {APP_URL}/api/auth/callback/github — protocolo, host, porta e caminho. Um erro redirect_uri após a implementação geralmente significa que o pedido atingiu as credenciais da app local enquanto APP_URL diz produção, ou o contrário.

Reinicie o servidor de desenvolvimento após cada edição do env; os valores só são lidos no arranque.

Para continuar a configuração, leia Adicionar o início de sessão com Apple.

Perguntas frequentes

14 perguntas

O que é o supastack?

O supastack é uma base modular para construir produtos SaaS com IA. Reúne a infraestrutura comum para que possas concentrar-te nas funcionalidades próprias do teu produto.

Suporta web e mobile?

Sim. O supastack inclui apps Next.js e Expo como pontos de partida para experiências web e mobile.

Que autenticação está incluída?

O Better Auth cobre email/palavra-passe, OTP e login social. Os workspaces pessoais são aprovisionados com a conta para que os registos fiquem delimitados desde o primeiro dia.

Como é suportada a IA?

O supastack inclui IA multi-fornecedor configurável, registo de utilização, orçamentos e suporte encriptado de chaves próprias (BYOK).

Como são geridas as subscrições?

Para produtos construídos sobre o kit, a faturação Stripe, as subscrições e as permissões formam a base do acesso pago. Os segredos de fornecedor ficam no servidor.

Onde vive o código próprio do meu produto?

As funcionalidades próprias do produto ficam num codebase separado, enquanto o produto configura e integra os módulos base do supastack.

Como funciona o preço do supastack?

O kit é uma compra única com atualizações vitalícias: Uma framework por 249 $ (preço de lançamento temporário — 100 $ de desconto sobre o preço normal de 349 $) ou Todas as frameworks (Next.js, iOS, Android) por 499 $ (preço de lançamento temporário — 100 $ de desconto sobre o preço normal de 599 $), mais 75 $ por lugar de programador adicional. Sem subscrição do kit. O checkout neste site entrega a tua chave de licença por email, com acesso ao repo por convite GitHub.

Como é que os workspaces delimitam os meus dados?

Os registos do utilizador são delimitados por workspaceId. Identidade, permissões, utilização de IA, eventos de faturação e entradas de auditoria ficam dentro do limite do workspace pessoal.

Como funcionam os jobs em segundo plano?

O Trigger.dev é o runtime de jobs explícito. O contrato JobRunner só promete enqueue, status e cancel — a semântica de workflow permanece específica e explícita do Trigger.dev.

Como difere o email da divulgação?

O email transacional cobre fluxos de produto como avisos de conclusão de tarefas. A divulgação fria e as campanhas pertencem ao próprio produto, fora do módulo de email deste kit.

Como funcionam as compras no aplicativo móvel?

O aplicativo móvel inclui compras nativas e restauração via RevenueCat, com acesso verificado pelo servidor. Configure as contas das lojas e conclua os testes em dispositivos antes de publicar. A cobrança web permanece separada.

Onde residem as chaves dos fornecedores de IA?

As credenciais BYOK são encriptadas e ficam no servidor. As chaves são higienizadas nos logs; a utilização e os orçamentos ficam visíveis ao nível do workspace.

Quais métodos de pagamento o checkout aceita?

O checkout hospedado na Stripe aceita cartões e também pode oferecer Alipay e WeChat Pay quando essas carteiras estiverem ativadas na conta Stripe — útil para compradores na China. As autorizações de carteira são confirmadas de forma assíncrona, então a página da licença é atualizada assim que o pagamento é liquidado.

Posso solicitar um reembolso?

Depois de obter acesso ao repositório, o supastack é seu para sempre, portanto não pode ser reembolsado. Mas fique tranquilo: você recebe o código-fonte completo com atualizações vitalícias para criar e lançar produtos ilimitados para você ou seus clientes. Você apenas não pode revender o código nem redistribuir o repositório como starter kit ou modelo.

PT
Tema