<p>Brightproxy gera uri de redirecionamento incorreto ao usar keycloak</p>

Você definiu isso em application.yml?

server:
  useForwardHeaders: true

A partir daqui: https://www.shinyproxy.io/security/#https -ssl-tls

Não tenho certeza de qual é o equivalente do Apache, mas no nginx isso é provavelmente o que corrige seu problema:

    proxy_set_header  Host    $http_host;

@aiham Obrigado.

Eu tenho isso funcionando. É devido à falta de useForwardHeaders: true

estou usando useForwardHeaders: true, mas ainda estou tendo o problema

@ danielfm123

estou usando useForwardHeaders: true, mas ainda estou tendo o problema

Existe outra possibilidade relacionada a certificados SSL. Se seus certificados instalados no Keycloak não forem de confiança pública (a CA raiz e intermediária não estão na lista de confiança padrão do Java), você precisa adicioná-los à CA confiável padrão do JRE. O JRE é aquele que executa seu Shinyproxy.

o local padrão é JAVA_HOME ---> JRE -> lib ---> segurança -> cacerts JAVA_HOME ---> JRE -> lib ---> segurança -> cacerts

comandos para importar assim.

keytool -import -noprompt -alias -your-root -file /opt/jboss/your-root.crt -keystore / etc / pki / java / cacerts -storepass changeit

Eu fiz isso, não funciona, eu tentei o brightproxy 2.3.1 ao invés do 2.4.1 e ele manda o redirect_uri correto, mas só funciona em alguns navegadores, no resto eu recebo err_too_many_redirects

Seus certs são públicos de confiança? Eu encontrei isso durante a fase de teste, os certificados não são de confiança pública. Você precisa importar a CA raiz e a CA intermediária para o armazenamento confiável do navegador. Cada navegador é diferente, depende do seu sistema operacional e navegador. No meu caso, estou usando o Windows, depois de importar Certs para a zona confiável e ambos o IE e o Chrome funcionam bem depois disso.

Aqui está minha sugestão,

1. durante a fase de teste, contanto que você tenha um navegador funcionando, será bom o suficiente.
2. para implantação de produção, adicione proxy da web seguro antes de GlossProxy e keycloak. Configure-o para usar o SSL do proxy da web e usar certificados públicos confiáveis. Esta é uma estrutura de implantação mais segura. Se sua organização não tiver um proxy da web seguro de hardware, você pode usar o Apache HTTPD como um proxy reverso da web e também um balanceador de carga.

Ele é validado com certbot .... Consegui fazê-lo funcionar com brilhanteproxy 2.3.1 e uma conta de diretório ativo diferente ...

Mas há um bug no Glossproxy 2.4.1 e 2.4.0

Olá @ danielfm123 , Verifiquei algumas coisas aqui e não consigo reproduzir nenhum problema com redirect_uri no ShinyProxy 2.4.0 / 1.
Você pode abrir um novo problema com as seguintes informações? Assim, posso analisar e ver se há um bug.

• como você está executando o ShinyProxy (usando o jar, Docker, Kubernetes etc.)
• forneça seu arquivo application.yaml (remova os valores confidenciais) Veja aqui como você pode postar o código
  
  
  
  • você está usando um balanceador de carga ou proxy reverso? qual, como está configurado (por exemplo, está passando os cabeçalhos X-Forwarded) etc
  
  
  • qual provedor openid você está usando? Os urls de retorno de chamada estão configurados corretamente?
  
  
  • o Brightproxy registra algum erro? Forneça o rastreamento de pilha completo.
  
  

Eu tenho o mesmo problema.

A configuração com keycloak, proxy reverso apache2 e shineproxy 2.3.1 funciona bem. Eu executo o brightproxy via Docker Shinyproxy redireciona corretamente para https://testauth.example.com.

Quando eu mudo para o Glossproxy 2.4.1, o redirect_uri contém o IP interno (http://192.168.51.27:8082) em vez do endereço que é acessível de fora e recebo um erro: "Parâmetro inválido: redirect_uri".

Esta é a parte relevante do meu application.yml:

proxy:
  title: AUTHTEST
  hide-navbar: false
  template-path: /templates
  favicon-path: /www/favicon.png
  heartbeat-rate: 10000
  heartbeat-timeout: 600000
  port: 8080
  admin-groups: admin
  container-wait-time: 30000
  authentication: keycloak
  keycloak:
    realm: shinyr
    auth-server-url: http://192.168.51.122:8080/auth
    resource: shinyr
    credentials-secret: <secret>
  docker:
    internal-networking: true
  specs:
  - id: test
    display-name: Euler App
    description: Test App
    container-cmd: ["R", "-e", "shiny::runApp('/root/euler')"]
    container-image: saletelligence/test
    container-network: authtest_authtest_net
    access-groups: [admin, pm]
logging:
  file:
    shinyproxy.log
server:
  useForwardHeaders: true

Esta é a configuração do apache:

<VirtualHost *:443>
        RequestHeader set X-Forwarded-Proto "https"
        RequestHeader set X-Forwarded-Port "443"
        ServerName testauth.example.com

        RewriteEngine On
        RewriteCond %{HTTP:Upgrade} =websocket
        RewriteRule /(.*) ws://192.168.51.27:8082/$1 [P,L]
        RewriteCond %{HTTP:Upgrade} !=websocket
        RewriteRule /(.*) http://192.168.51.27:8082/$1 [P,L]
        ProxyRequests Off

        ProxyPass "/" "http://192.168.51.27:8082/"
        ProxyPassReverse "/" "http://192.168.51.27:8082/"

        SSLProxyEngine On
        SSLEngine On
        SSLCertificateFile /etc/apache2/sslcert/example.crt
        SSLCertificateKeyFile /etc/apache2/sslcert/example_pem.key
        SSLCACertificateFile /etc/apache2/sslcert/example_bundle.pem
</VirtualHost>

Olá @ eastclintw00d

Por favor, tente usar:

server:
  forward-headers-strategy: "native"

Ao invés de

server:
  useForwardHeaders: true

Obrigado!

Olá @LEDfan

Isso resolveu o problema.

Obrigado pela resposta rápida!

Isso funciona, mas mata o pacote DT

@ danielfm123 Tem certeza de que está executando o GlossProxy 2.4.1? DT está funcionando bem para mim.

@ danielfm123 @ eastclintw00d Solicitações POST (como feitas, por exemplo, pelo DT) não funcionam ao usar OIDC com o ShinyProxy atual (2.4.1). Uma correção de @LEDfan fará parte de um próximo lançamento, mas este não é o tópico deste tópico.

O problema com a solicitação POST foi corrigido na versão 2.4.2

A documentação relacionada ao problema original é atualizada.

Bloquearei esse problema para que possamos mantê-lo.
Claro, como sempre, não hesite em abrir uma nova edição se você encontrar qualquer problema!