Mantenha sua chave da API de CAPTCHA fora do JavaScript do navegador
Mantenha a chave de API do workspace solvethree no servidor. O navegador controla o formulário e a sessão da aplicação; seu backend autenticado controla a criação e a consulta de tarefas. Não substitua uma chave vazada no navegador por uma rota de backend irrestrita que qualquer pessoa possa usar para gastar o saldo do seu workspace.
Nesta página
NEXT_PUBLIC não é lugar para uma chave de workspace
Uma chave de workspace autentica requisições ao solvethree com Authorization: Bearer. Colocá-la no JavaScript do navegador, inclusive por meio de uma variável de ambiente pública incluída no bundle, como NEXT_PUBLIC_SOLVETHREE_API_KEY, expõe essa credencial ao navegador. Ofuscar o valor ou adicioná-lo apenas ao fazer uma chamada fetch direta não o torna privado.
Mantenha SOLVETHREE_API_KEY em uma configuração exclusiva do servidor e use-a apenas em código confiável do servidor. O navegador deve chamar a rota da sua aplicação, nunca a API de tarefas do solvethree com a chave do seu workspace.
Mantenha os parâmetros da tarefa em um helper exclusivo do servidor
// Import only from trusted server code. Your application authenticates the caller.
import { Solvethree } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY });
export async function createCaptchaForLogin(requestId) {
return client.createTask({
site: process.env.CAPTCHA_SITE,
action: 'login',
proxy: process.env.SOLVETHREE_PROXY,
requestId,
}, { waitMs: 0, signal: AbortSignal.timeout(20000) });
}
// The browser calls your authenticated application route, not the solver API.
// Save the returned task ID; retrieve that ID from server code with getTask.
// Submit a ready token using the proxy/browser identity attached to that solve.
// Merely moving the key server-side does not configure the browser's proxy.Configure SOLVETHREE_API_KEY, CAPTCHA_SITE e SOLVETHREE_PROXY no servidor. CAPTCHA_SITE é o hostname de destino, não uma URL completa. O helper fixa a ação em login e fornece um proxy; o navegador não escolhe nenhum desses parâmetros.
Configure um perfil ativo para esse hostname no workspace antes de chamar o helper. Enviar site e action não cria um perfil. Consulte a configuração de perfil de site.
waitMs: 0 solicita a criação sem esperar a conclusão da resolução. Salve o ID da tarefa retornado e consulte-a pelo código do servidor com getTask. O sinal de cancelamento de 20 segundos do helper limita essa requisição; ele não garante que a resolução termine em 20 segundos.
Exponha uma operação de login, não um serviço de resolução arbitrário
O helper, por si só, não é uma rota autenticada. Implemente estas verificações ao redor dele antes de aceitar requisições do navegador:
| Operação | O navegador envia | O backend faz |
|---|---|---|
| Iniciar a resolução para login | A sessão da aplicação e um requestId para esta tentativa de login. | Autentica o cliente, valida a tentativa, verifica os limites de criação e chama o helper com parâmetros fixos. Salva o ID da tarefa associado a esse cliente e a essa tentativa; retorna apenas o ID da tarefa e o status necessários para a interface. |
| Consultar progresso | A sessão da aplicação e o ID da tarefa retornado para essa tentativa. | Verifica se a tarefa pertence ao cliente antes de consultá-la. Retorna o progresso, uma resposta de falha controlada ou o resultado pronto necessário para o cliente autorizado a fazer o envio. |
Não encaminhe um corpo de tarefa fornecido pelo navegador. Rejeite tentativas de escolher outro hostname, ação, proxy ou tipo de tarefa. Aplique um limite de criação por cliente ou sessão da aplicação: mesmo um cliente autenticado pode esgotar os créditos iniciando novas tarefas. Se a rota usar autenticação por cookies, proteja as requisições que criam tarefas contra falsificação de requisições entre sites.
Um ID de tarefa não é uma autorização. Verifique a titularidade em cada requisição de progresso e não retorne credenciais do workspace nem credenciais do proxy do servidor nas respostas ao navegador.
Recupere a tarefa existente antes de criar outra
- Mantenha um único requestId para a tentativa lógica de login. Valide seu formato documentado: 1–64 letras ASCII, números, sublinhados ou hífens. Vincule-o à tentativa do cliente; ele não é uma credencial de autenticação.
- Se a criação exceder o tempo limite, mantenha esse requestId e os parâmetros originais da tarefa. Repetir a mesma requisição com o mesmo ID recupera a tarefa existente. Alterar os parâmetros reutilizando o ID gera um conflito.
- Trate as respostas HTTP sem sucesso antes de interpretar um payload de sucesso. Para uma tarefa consultada, pending e solving indicam que você deve continuar consultando; ready indica que há uma solução disponível.
Depois de obter um ID de tarefa, consulte essa tarefa em vez de iniciar outra resolução a cada atualização do navegador ou requisição de progresso. Consulte tratamento de erros da API para diagnosticar falhas.
Decida qual cliente enviará o token
Antes de retornar um token pronto ao navegador, decida onde a requisição ao destino será executada. O cliente que fará o envio deve usar a identidade retornada em userAgent e secChUa e o proxy bem-sucedido dessa resolução. Mover a chave do workspace para um backend não configura o proxy do navegador.
Se o navegador não puder fazer o envio com essas configurações, entregar apenas o token não constitui uma integração completa. Use um cliente de envio que você possa configurar de forma consistente, sem misturar a identidade, o proxy ou a URL de destino de outra sessão. Uma tarefa pronta significa que o solvethree gerou uma solução, não que o destino aceitou a requisição subsequente.
Fontes e referência da API
Execute sua primeira tarefa.
Comece com $5 em créditos no espaço de trabalho.