Gerar chave de API do usuário sem aprovação do usuário

Dev
1

Estou usando o Discourse headless e consigo obter informações do usuário usando a chave da API de administrador, mas foi recomendado gerar uma API de usuário para cada usuário. Portanto, estou tentando usar esse método em vez disso, mas não quero que o usuário precise navegar para uma nova interface para “aprovar” a API que estou criando para ele.

Portanto, minha solução é enviar a confirmação programaticamente. A partir de uma solicitação GET para ‘/user-api-key/new’, consigo extrair os dados do elemento ‘form’, mas não consigo enviar uma solicitação POST para ‘/user-api-key/’ porque receberei um erro CSRF.

Desativei a proteção CSRF para o Discourse Connect, mas existe outra para api-key?
SiteSetting.discourse_connect_csrf_protection

Se não, não usarei as chaves de API de usuário até que consiga criá-las sem a interrupção da interface.

Agradeço antecipadamente!

Aparentemente, uma solução que poderia funcionar existia em versões anteriores, mas não estou vendo nenhuma versão atualizada disso:

1 curtida
2

Talvez estejamos construindo a mesma coisa :slight_smile: embora o meu seja apenas parcialmente headless.

Suspeito que não exista, e que seja de propósito.

Eu também tenho me perguntado sobre a mesma coisa, mas acho que no meu caso tudo bem - eu não estou tentando esconder o Discourse.

Uma coisa a ter em mente com chaves de API de Usuário versus chaves de API de Todos os Usuários de administrador é que, por padrão, elas têm limites de taxa diferentes aplicados a elas: Available settings for global rate limits and throttling.

taxa de limite de API de usuário:
DISCOURSE_MAX_USER_API_REQS_PER_MINUTE : padrão 20
DISCOURSE_MAX_USER_API_REQS_PER_DAY : padrão 2880

taxa de limite de API de administrador:
DISCOURSE_MAX_ADMIN_API_REQS_PER_MINUTE : 60

Se sua aplicação estiver se conectando a um site Discourse auto-hospedado, você provavelmente poderá substituir o limite de taxa da API de administrador. Se sua aplicação estiver se conectando a instâncias Discourse hospedadas, os limites de taxa da API de usuário oferecem muito mais flexibilidade. Com o limite de taxa da API de administrador, você acaba tendo que colocar todas as solicitações em uma fila com limite de taxa.

Editar: em vez de usar a Especificação de Chaves de API de Usuário para gerar as chaves, você pode usar uma chave de API de administrador para gerar chaves de API de usuário. Isso contorna o problema de os usuários terem que aprovar o aplicativo.

Note que a chave postada abaixo é para meu domínio localhost, então não há risco em postá-la.

parâmetros de chave não escapados: {key:description:sally} {key:username:sally} {key:scopes:[scope_id:topics:write]} {key:scopes:[key:write]} {key:scopes:[name:write]} {key:scopes:[params:[topic_id]]} {key:scopes:[urls:[/posts (POST)]]} {key:scopes:[selected:true]}

❯ curl -X POST \"http://localhost:4200/admin/api/keys\" \
      -H \"Api-Key: $api_key\" \
      -H \"Api-Username: system\" \
      -H \"Content-Type: application/json\" \
      -d $json
{\"key\":{\"id\":29,\"key\":\"f5c6307b51dd2882bde525dc9775fe7504b55c93fa40177b650f9e6b77a9d25b\",\"truncated_key\":\"f5c6\",\"description\":\"sally\",\"last_used_at\":null,\"created_at\":\"2024-06-02T00:44:19.944Z\",\"updated_at\":\"2024-06-02T00:44:19.944Z\",\"revoked_at\":null,\"user\":{\"id\":3,\"username\":\"sally\",\"avatar_template\":\"/user_avatar/127.0.0.1/sally/{size}/58_2.png\"},\"api_key_scopes\":[{\"resource\":\"topics\",\"action\":\"write\",\"parameters\":[\"topic_id\"],\"urls\":[\"/posts (POST)\"],\"allowed_parameters\":{},\"key\":\"write\"}]}}

Em qualquer um dos casos, você fica com uma chave de API que precisa ser gerenciada de alguma forma. Presumo que criptografada e salva em um banco de dados.

5 curtidas
3

Você está usando React no seu frontend? Estou aberto a encontrar uma maneira de colaborar para reduzir a redundância e aumentar a confiabilidade do código. Acho que a autenticação via SSO foi a parte mais difícil. Então, espero que seja tranquilo daqui para frente.

4

Sim, é um aplicativo Remix/React Router. Então React no frontend, Node no backend.

Tenho trabalhado com isso há anos. Me mande uma mensagem aqui se tiver alguma dúvida sobre isso.

Estou tentando fazer algo que funcione bem com os limites de taxa do site hospedado do Discourse. Essa tem sido a parte complicada. As chaves de API do usuário pareciam uma maneira possível de lidar com isso, mas também há um limite de taxa por endereço IP, então estou de volta a usar apenas uma única chave de API e enfileirar todas as solicitações de API.

1 curtida
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.