refined-github/refined-github

Person Access Token can't be set for multiple GHES

Fechada

#8.428 aberto em 2 de mai. de 2025

Ver no GitHub
 (0 comentário) (0 reação) (0 responsável)TypeScript (1.423 forks)batch import
bugenterprisehelp wanted

Métricas do repositório

Stars
 (22.918 estrelas)
Métricas de merge de PR
 (Mesclagem média 1d 18h) (44 fundiu PRs em 30d)

Description

Description

I've registered Refined Github with two GHES environments.

When I set the Personal Access Token for one GHES environment, it also sets the same value for the second GHES environment.

My Personal Access Token for Github.com is not affected by this.

How to replicate the issue + URL

  1. Using the instructions at https://fregante.github.io/webext-permission-toggle
    1. Register the first GHES instance
    2. Register the second GHES instance
  2. Open the Options page for Refined GitHub
  3. In the Domain Selector, choose the first GHES instance
  4. Enter the token
    • Notice that it works
  5. In the Domain Selector, choose the second GHES instance
    • Notice that the token is already filled in, but it's from the first instance

Extension version

25.4.8

Browser(s) used

Google Chrome 136.0.7103.49 (Official Build) (64-bit) (cohort: Stable Installs & Version Pins)

Token ⚠️

  • I set a token in the options page. I understand that some features require a token to work.

Guia do colaborador

Direção de pesquisa
Investigue o código da página de opções em `source/options/` para entender como os tokens são armazenados. Procure pelas chaves de armazenamento e verifique se elas são escopadas por domínio. O bug provavelmente se deve ao uso de uma única chave para todas as instâncias GHES; a correção envolveria separar o armazenamento de tokens por URL da instância.
Pilha de tecnologia
typescriptjavascript
Domain
frontendauthenticationdeveloper experience
Tipo Issue
Bug
DifficultyDificuldade de implementação estimada para um novo contribuidor, de 1 para alterações muito pequenas a 5 para trabalho de nível especializado.
2
Tempo estimadoUm intervalo de tempo aproximado para um colaborador experiente investigar, implementar, testar e preparar um pull request.
1-3 horas
Status da atividadeQuão disponível o issue aparece agora: novo, ativo, obsoleto, bloqueado ou aguardando entrada do mantenedor.
Recente
ClarityCom que clareza o issue explica a mudança esperada, os critérios de aceitação e a próxima etapa.
Claro
Prerequisites
Understanding of browser extension storageFamiliarity with Refined GitHub codebase
Simpatia para novatosUma pontuação de 1 a 100 que estima o quão acessível este issue é para colaboradores iniciantes.
75