Problemas com SSO e caractere '~'

Olá a todos,

Recentemente descobri que, se eu incluir ‘~’ na biografia de um usuário, recebo um erro de base64decode do Discourse. Ele consegue lidar com todos os outros caracteres problemáticos sem problemas (espaços, =, %, &), mas não com ‘~’ por algum motivo.

Mais alguém encontrou este problema?

Meu primeiro pensamento é que talvez minha codificação esteja errada, mas ainda não consegui descobrir.

Aqui está minha implementação em Python da codificação:

return_payload = base64.urlsafe_b64encode(parse.urlencode(params).encode())

que é então colocado diretamente em ‘sso’ nas requisições (junto com todas as outras informações necessárias)

resp = requests.post(
       ".../admin/users/sync_sso",
        data={'sso': return_payload, ...}
        headers={...}
)

Atualizei meu Discourse para a versão mais recente (3.5.0.beta1-dev), mas o problema persiste.

Obrigado por qualquer ajuda!

2 curtidas

Provavelmente deveria ser corrigido, mas essa pergunta está acima do meu nível e das minhas habilidades. Mas por pura curiosidade prática: por que alguém usaria um til na bio?

1 curtida

Heh, acho que essa é uma pergunta razoável.

Eu administro um fórum multilíngue e em outras culturas o ‘~’ é frequentemente usado. Como exemplo, em coreano, ele é frequentemente usado no final para suavizar o tom, como ‘Se tiver alguma dúvida, me avise~’.

2 curtidas

Então este é um relatório de bug e não uma solicitação de suporte?

1 curtida

É? Um bug é algo que é feito, mas não funciona. Isso é mais como a pergunta “está feito ou não” e então é mais Feature se não for uma pergunta de suporte.

Sim, acho que Bug é apropriado. Acredito que estou codificando em base64 corretamente, então o Discourse também deve decodificar corretamente.

Acho que é um bug (desde que possamos reproduzi-lo)

2 curtidas

Parece que urlsafe_b64encode substitui alguns caracteres na codificação base64. Da documentação:

Codifica o objeto s semelhante a bytes usando o alfabeto seguro para URL e sistema de arquivos, que substitui - em vez de + e _ em vez de / no alfabeto Base64 padrão, e retorna os bytes codificados. O resultado ainda pode conter =.

Isso significa que o resultado não é base64 padrão e não será compatível com a decodificação do Discourse.

Eu recomendaria usar a função b64encode normal em vez disso. Sua biblioteca HTTP cuidará do escape de URL, se necessário.

5 curtidas

Após mais investigações, eu estava de fato codificando incorretamente.

Aqui está o que eu acabei tendo, para posteridade:

return_payload = base64.b64encode(parse.urlencode(kwargs).encode("utf-8"))
h = hmac.new(secret.encode("utf-8"), return_payload, digestmod=hashlib.sha256)
resp = requests.post(
       ".../admin/users/sync_sso",
        data={"sso": return_payload, "sig": h.hexdigest()}
        headers={...}
)

E se você estiver fazendo o redirecionamento, certifique-se de usar parse.urlencode para isso {“sso”…}.

Obrigado pela ajuda @sam e @david!

3 curtidas

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