Grafana: Login automático por token url

seria muito inseguro, pois qualquer pessoa pode ver o token, você pode criar um instantâneo dos dados visíveis e incorporá-lo, seria mais seguro

Sim, mas usando instantâneos você não tem permissão para editá-lo ou existe alguma maneira de editar o painel por meio de instantâneos?

Isso é muito importante para a interoperabilidade com SaaS.
Temos nossa própria autenticação e painéis, queremos fornecer a capacidade de passar um usuário de nosso painel para o Grafana - de maneira semelhante à forma como o Heroku interopera com o New Relic e outros serviços sem senhas.

Fornecer um método de autenticação url + token é parte do curso.
Se alguém vai e incorpora isso em um site público, nenhuma quantidade de segurança salvará essa pessoa de si mesmo. Isso é culpa deles.
Fornecer avisos suficientes na documentação / interface do usuário deve ser suficiente para isso.

Sem esta funcionalidade, os usuários devem encontrar uma segunda tela de login, onde ficarão confusos quanto ao nome de usuário / senha a inserir.

Este é um grande bloqueador para nós.

Parece um bom recurso do Grafana. Gostaria de ajuda com RP, pois há tantas outras coisas que são de alta prioridade no momento

Bela explicação @adamlwgriffiths a mesma coisa acontece comigo.

Agora mesmo resolvemos esse problema com um pequeno hack, adicionando um javascript que faz o login automático na grafana, mas é uma solução temporal

+10 por isso !!
Para tornar isso seguro, deve haver um hash do nome de usuário + senha + data, contidos no token. Isso pode ser usado para expirar o token após x número de horas para melhorar a segurança.

Se eu tiver algum tempo, considerarei seriamente trabalhar nisso

Se você estiver armazenando a data de criação do token para que possa expirá-lo, também estará armazenando o hash e a conta associada, portanto, não acho que o hash precise ser gerado a partir de nenhum dado específico. Ele só precisa ser um espaço de busca suficientemente grande para tornar a adivinhação inviável.

@adamlwgriffiths , isso deve suportar algumas funções básicas também .. como visualizador, editor .. etc, semelhante ao que é feito com as chaves de API .. Talvez pudéssemos apenas estender isso para que pudéssemos passar uma chave de API via url?

Acho que - a longo prazo - o token user / org / api precisa ser consolidado, em vez de adicionar um novo método.
Se os tokens de API fossem expandidos para permitir o uso da interface HTML, isso não seria um problema.
Os tokens de API já têm funções e podem ser revogados, portanto, só precisam ser utilizáveis ​​para a visualização da web em vez de API pura.

Os tokens de API IMO devem funcionar da mesma forma que usuários normais. Há uma segregação arbitrária que não está documentada e considero contra-intuitiva. Ativar todas as verificações de login para verificar também as chaves de API seria o melhor, eu acho.

Este recurso foi implementado? Eu estava tentando fazer com que um usuário fosse redirecionado automaticamente para o painel da grafana do meu site.

@comcomservices Como um acompanhamento do próprio token, você definitivamente pode criptografar as informações dentro do token com o id do usuário e o tempo de expiração do token. Dessa forma, você pode apenas ler o próprio token e obter as informações sem exigir que os tokens sejam armazenados no banco de dados e executar 'varrer e limpar' os tokens antigos.

Hesito em recomendar tal coisa, acredito firmemente que a criptografia é difícil e, sem um entendimento completo do que você está fazendo, não é uma boa ideia tentar fazê-lo.

O outro problema com tokens criptografados é que eles são bastante grandes e, quanto mais informações, maiores eles se tornam.
Onde uma string aleatória pode ser feita em qualquer comprimento, desde que o espaço seja grande o suficiente para tornar a força bruta inviável.

@adamlwgriffiths no que diz respeito à criptografia, tenho um histórico formal e gosto disso, mas, neste caso, estou totalmente de acordo que um token seria o melhor. Só estou tentando descobrir isso, tenho feito c ++ e asm por muito tempo ... vou pegá-lo e este é o primeiro da minha lista

Estou ansioso por este recurso! Com relação ao comentário de o raven-js do Sentinela ; fará um URL público e, em seguida, restringirá por origem (veja abaixo). Isso atenuaria a preocupação com a segurança?

@ Germanaz0 seu JS de login automático está disponível publicamente? Estou tentando implementar algo semelhante no branch master e parece que o back-end redireciona para a tela de login antes de chegar à página do painel. Não estou muito familiarizado com a estrutura do projeto ainda, então posso não estar plugando na seção certa no código JS.

@rca sim, mas minha solução é super simples https://gist.github.com/Germanaz0/d41b5f60dd8097405b6b

Você recebe um parâmetro de entrada como? T = base64 de um json com {user: _USERNAME_, pass: _PASS_, redirect_to: _URL_TO_REDIRECT}

Você deve incluir esse script na página de login.

@ Germanaz0 , obrigado por compartilhar! Depois de enviar meu comentário, comecei a dar uma olhada e, como você apontou, descobri que precisava atualizar a página de login. Adotei uma abordagem um pouco diferente e atualizei o controlador de login em vez de fazer um script autônomo; minha mudança está aqui: https://github.com/zymbit/grafana/tree/auto-login-by-cookie-redirect

Isso é digno de uma solicitação de pull? Eu ficaria feliz em fazer os mods necessários para colocar isso em um estado fundível.

alguma atualização disso?
@rca Você criou um PR?

+1 para um PR da @rca

@ Germanaz0 , em qual arquivo você está incluindo seu arquivo .js?

@rca , você tem instruções sobre como usar o mod do controlador de login? Eu sou novo na grafana e estou tentando fazer isso funcionar para um quiosque autônomo.

BTW, se alguém precisa de uma maneira de fazer isso para quiosques, etc., verifique o authproxy de

@scottfuhrman Nada escrito formalmente, no entanto, aqui está meu caso de uso e implementação:

Eu não estava procurando o modo quiosque, mas sim uma maneira de incorporar um painel como um iframe em uma página externa. Os gráficos são incorporados de forma bastante limpa, por exemplo:

Na página em que deseja incorporar o painel, você precisa da seguinte marcação:

<div id='grafana-dashboard' class="col-lg-12"></div>


<script type="text/javascript">
    GrafanaEmbed = {
        grafanaUrl: 'https://your.grafana.example.com',
        dashboard: 'dashboad-name',
        queryParams: {
            dashnav: 0,
            // this is a base64-encoded string of username:password
            // for example on a *NIX machine (and Mac OS X):
            // $ echo "kiosk1:supersecret" | base64
            // a2lvc2sxOnN1cGVyc2VjcmV0Cg==
            auth: 'a2lvc2sxOnN1cGVyc2VjcmV0Cg==',
            theme: 'light'
        }
    };

    (function() {
        var d = document.createElement('script'); d.type = 'text/javascript'; d.async = true;
        d.src = GrafanaEmbed.grafanaUrl + '/public/app/features/dashboard/embed.js';
        (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(d);
    })();
</script>

Espero que isto ajude.

+1

Não tenho recursos de pessoal para isso, mas ficaria feliz em fazer um crowdfund do esforço para isso.

Pensei que tivesse resolvido isso até tentar usar uma lista de reprodução. Usar o authproxy funciona para um determinado painel, mas uma vez que tentei uma lista de reprodução com vários painéis, tive o mesmo problema. Não entendo o motivo de ter um modo quiosque quando é impossível implementar um aplicativo quiosque real a menos que desabilitemos completamente a segurança de visualização.

@torkelo, recrutei @ over64 para trabalhar nisso para mim.

Como você recomenda que isso seja implementado? Basicamente, o que eu preciso é ter um token na string da URL que ignore / resolva a autenticação. Qual é a melhor abordagem para isso?

não tenho certeza, teria que pesquisar como tal recurso deve ser implementado com segurança

Entendi. Estamos prontos assim que você tiver elaborado um plano :)

se você tiver uma ideia de como fazer por favor me avise e eu poderei avaliá-la

Tudo bem. @ over64 vai dar uma olhada e sugerir algo.

@torkelo Você pode dar uma olhada no PR de @ over64 no número 7431 para ver se isso faz sentido.

Alguma solução alternativa fácil? Estou tentando implementar a solução @ Germanaz0 , mas não está funcionando para mim :(

Isso é obrigatório, caso contrário, será bloqueado ao incorporar o instantâneo ao iframe. O url de instantâneo incorporado deve oferecer suporte a chave / token de login.

Olá a todos,

Comentários mais recentes neste tópico são a respeito de:

• segurança
• incorporação em um iframe

Com relação à segurança, por favor, considere meu antigo comentário acima: https://github.com/grafana/grafana/issues/3752#issuecomment -200874453

E com relação à incorporação em um iframe: https://github.com/grafana/grafana/issues/3752#issuecomment -267062843

Este branch (embora bastante antigo) contém código emprestado do Discourse que dimensiona muito bem um iframe, bem como autentica por meio de token, conforme descrito no comentário acima.

@torkelo Por favor, deixe-me saber se você consideraria uma solicitação pull incorporando os elementos acima.

@rca o que é embed.js no seu código acima?

@zoell são alguns js emprestados do projeto Discourse para dimensionar bem um iframe na página com base no conteúdo incorporado ao quadro.

@rca oh obrigado. Não consegui encontrar esse arquivo no branch que você mencionou. Isso está disponível em outro lugar?

@zoell , vou bifurcar esse repositório e incluir esse arquivo como deveria estar lá.

@rca obrigado, seria ótimo.

@rca desculpe, ainda não consigo encontrar o arquivo no branch que você mencionou antes.

@TinaRen @zoell Deixei cair a bola nisso, desculpas.

No entanto, depois de dar uma olhada agora, parece que o arquivo está lá o tempo todo! 😬

Farei qualquer trabalho adicional sobre isso em:

https://github.com/rca/grafana

E o arquivo está em:

https://github.com/rca/grafana/blob/embedding/public/app/features/dashboard/embed.js

Se este arquivo não estiver sendo compilado e acabando no diretório public_gen/ , por favor me avise.

Obrigado!

É possível limitar pelo menos a grafana aos acessos localhost? (para estreitar o compartilhamento do painel no mesmo servidor)

Eu adoraria ver alguém tentando fazer isso com uma implementação adequada que pode ir para cima. A solução que propusemos (# 7431), nunca foi aceita :(

Estou feliz por ter alguém do nosso lado dedicado a isso, mas precisamos de orientação sobre o que seria aceitável no upstream.

Conseguiu fazer isso com sucesso usando de Grafana auth.proxy e do Nginx ngx_http_secure_link_module

Os links que uso estão no formato http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Uma vez que o usuário clica nele, o cookie da sessão é definido e o usuário pode navegar pela grafana como se estivesse logado normalmente.

Vantagens:

• O link expira após algum tempo + segurança
• O link gera hash com ID do usuário, carimbo de data / hora e senha + segurança
• Não há necessidade de digitar a senha + comodidade

Minha conf nginx é assim

server {
    listen 3001 default_server;
#   listen [::]:3001 default_server;

    server_name _;

        location / {
        set $user "";
        set $state "";

        if ($args ~ "^user=(.+)&md5") {
                    set $user $1;
                    set $state "${state}U";
                }

        secure_link $arg_md5,$arg_expires;
                secure_link_md5 "$secure_link_expires$uri$user grafanarocks";

                if ($secure_link = "") { 
                    set $state "${state}S1";
                }

                if ($secure_link = "0") { 
                    set $state "${state}S2";
                }

                add_header X-uristate "$state";

                if ($state = "US1") { return 403; }
                if ($state = "US2") { return 410; }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://127.0.0.1:3000;
            }
    }

Sinta-se à vontade para entrar em contato comigo se precisar de ajuda com isso

Muito interessante, @Nayar. No entanto, minha preocupação com essa solução é que ela requer uma grande quantidade de personalizações. Eu preferiria algo que fosse integrado ao Grafana nativamente.

Eu usei um estoque Grafana. Só tive que recompilar um estoque nginx com o módulo habilitado e pronto.

Nayar, você pode me dizer se a solução que você implementou pode funcionar com todas as versões do grafana.Eu sou novo no Grafana. Na minha organização, eles já instalaram

Trazendo algumas idéias (e problemas) de como resolver isso.

Solução mais rápida:

1) adicione um tipo especial (sinalizador) em uma chave de API para que ela possa ser usada na url para fazer seu login.

Proos: as chaves de API só podem ser adicionadas por administradores da organização.

2) possibilitar que os usuários criem chaves de API e chaves de url (variante da chave de API).

Os problemas com isso serão configurações oauth, em que se um usuário puder criar uma chave de API ou url, ele poderá usá-la após ter removido o acesso do Grafana (do sistema oauth). Como a chave de API ou a chave de url não exigirá um login oauth. Isso será um grande problema para as chaves de API do usuário quando eventualmente as fizermos. Uma solução atenuante pode ser permitir que apenas os administradores da organização ou os administradores do servidor da grafana criem chaves de API do usuário.

Pensamentos @DanCech ? Continuar usando uma chave de API com um sinalizador AllowUrlLogin?

Não acho que usar a infraestrutura de chave de API seja o caminho certo, pois torna difícil adicionar mais funcionalidades posteriormente (por exemplo, limitar o url a um determinado conjunto de painéis, permitindo que não administradores criem links de login ) e pode ser confuso para os usuários. Certamente poderíamos usar os mesmos conceitos e ter uma estrutura de back-end semelhante, mas isso nos dá mais opções se separarmos, e acho que ficará mais claro para os usuários.

No que diz respeito à pergunta de login oauth, acho que temos que descobrir qual deve ser o escopo aqui. O mesmo problema existe para usuários oauth se você também tiver as senhas ativadas, uma vez que eles podem definir uma senha local e seriam capazes de fazer login dessa forma após a conta oauth ser desativada. A única solução real para esse problema é armazenar esse link na conta do usuário e sempre enviar um usuário oauth através do loop de redirecionamento oauth antes de aceitar seu login.

Também acho que precisamos encontrar um nome razoável para essa funcionalidade. "URL de login" pode ser muito amplo e não deixa espaço para uso no futuro como uma forma de, por exemplo, compartilhar um link ativo limitado a um painel específico.

@mattttt adoraria

uma vez que torna difícil adicionar mais funcionalidades posteriormente (por exemplo, limitar o url a um determinado conjunto de painéis, permitindo que não administradores criem links de login)

Hesito em vincular esse recurso de login a permissões ou restringi-lo a painéis específicos (exceto vinculá-lo a uma função organizacional ou usuário). Porque isso transformaria isso em um recurso de compartilhamento e definiria expectativas de segurança que não são atendidas (já que você pode consultar todos os dados de uma fonte de dados usada por uma organização).

A única solução real para esse problema é armazenar esse link na conta do usuário e sempre enviar um usuário oauth através do loop de redirecionamento oauth antes de aceitar seu login.

Não tenho certeza de como isso resolve a "revogação" do url de login / token de API do usuário. Se eles nunca tentassem fazer o login com oauth depois que seu acesso foi removido, Grafana nunca saberia.

@hemsush De acordo com esta postagem do blog, ele deve funcionar a partir do Grafana 2.0: https://grafana.com/blog/2015/12/07/grafana-authproxy-have-it-your-way/

Hesito em vincular esse recurso de login a permissões ou restringi-lo a painéis específicos (exceto vinculá-lo a uma função organizacional ou usuário). Porque isso transformaria isso em um recurso de compartilhamento e definiria expectativas de segurança que não são atendidas (já que você pode consultar todos os dados de uma fonte de dados usada por uma organização).

Esse é um problema que precisa ser resolvido, então minha sugestão é que este sistema seja projetado com esse caso de uso em mente para o futuro.

Não tenho certeza de como isso resolve a "revogação" do url de login / token de API do usuário. Se eles nunca tentassem fazer o login com oauth depois que seu acesso foi removido, Grafana nunca saberia.

Minha opinião é que a visão que o cliente obtém ao usar um desses links deve ser semelhante ao do usuário "anônimo", onde eles não estão magicamente logados como um usuário específico, mas sim obter uma conta de visualizador limitada, o que divorciaria totalmente esse recurso de contas de usuários individuais. Isso contornaria o problema das permissões de conta de usuário individual, reduziria o nível de risco, uma vez que um link não poderia ser usado para fazer alterações e permitiria o gerenciamento centralizado de todos os links de acesso ativos pelos administradores da organização.

Proposta de solução

1) Introduzir o novo conceito "Viewer URL Token", que você pode adicionar / remover da página API Keys (podemos fazer uma nova página para isso mais tarde). Armazene na nova tabela url_token e eles funcionarão de uma perspectiva de segurança muito semelhante às chaves de API. Ou seja, eles serão gerados e validados da mesma forma que as chaves de API são. O pode, entretanto, ser usado para fazer o seu login através do uso em url com "& url-auth-token ="
2) Opção de restringir o token para funcionar apenas com API de renderização PNG (será mais seguro, pois os usuários com token de URL não serão capazes de emitir qualquer consulta, apenas visualizar painéis / painéis existentes)
3) No futuro, teremos que encontrar uma maneira de vincular o token a grupos de usuários e permissões do painel, mas ainda não temos certeza de como isso funcionará. Acho que poderia ser bom criar um usuário fictício para isso, que pode ser usado para dar aos usuários do "Token de URL" permissões para painéis e fontes de dados específicos. Odiaria ter de verificações / junções explícitas para tokens de url em verificações de permissão.

4) Deixe claro que qualquer pessoa com um token de url terá acesso a todas as fontes de dados da organização (e pode tecnicamente emitir qualquer consulta) (a menos que a opção de API de restrição para renderização seja usada).

pensamentos @bergquist @DanCech

Opção de restringir o token para funcionar apenas com API de renderização PNG (será mais seguro, pois os usuários com token de URL não poderão emitir qualquer consulta, apenas visualizar painéis / painéis existentes)

Não acho que a renderização PNG seja uma boa solução. Ele piscará e não ficará tão bonito quanto o Grafana real.

Gosto da ideia de conectar o token a um usuário. A maneira mais fácil de conectar esse token / login a grupos de usuários e permissões de pasta do painel. Mas eu acho que o login usando o token (tv login / view mode / tv mode) deve forçar o usuário a estar na função Viewer .

Deixe claro que qualquer pessoa com um token de url terá acesso a todas as fontes de dados da organização (e pode tecnicamente emitir qualquer consulta) (a menos que a opção de API de restrição para renderização seja usada).

Adicionar informações e avisos ao criar novos tokens pode ajudar.

O problema de vincular um token a um usuário "normal" é que isso causa todos os tipos de problemas quando o usuário é modificado ou excluído. Se os tokens de url pudessem ser membros de um grupo da mesma forma que os usuários, haveria uma grande flexibilidade na configuração de urls individuais com acesso a painéis específicos etc.

Não tenho certeza se isso adicionaria muita complexidade às verificações de permissão, você usaria uma tabela diferente para os membros do grupo, dependendo se o visualizador é um usuário regular ou um token de url, mas as verificações de acesso em todo o sistema não deveriam precisa mudar.

No que diz respeito à aplicação efetiva do acesso às fontes de dados, não há diferença aqui do que com usuários regulares. A solução final para esse problema é mover os plug-ins da fonte de dados para o back-end e fazer com que o front-end despache as solicitações da fonte de dados especificando o painel, o painel, o intervalo de tempo e os valores de var do modelo e tendo as consultas reais criadas no back-end após validar que o usuário tem acesso e que os valores var do modelo são legítimos.

O problema de vincular um token a um usuário "normal" é que isso causa todos os tipos de problemas quando o usuário é modificado ou excluído

O problema de que qualquer pessoa que conheça um token (mesmo que a conta seja encerrada) possa ver os painéis é verdadeiro para ambas as soluções. A revogação do acesso pode ser feita excluindo o usuário ou token.

Não tenho certeza se isso adicionaria muita complexidade às verificações de permissão, você usaria uma tabela diferente para os membros do grupo, dependendo se o visualizador é um usuário regular ou um token de url, mas as verificações de acesso em todo o sistema não deveriam precisa mudar.

As verificações devem ter a mesma aparência, independentemente da autenticação. Então isso não será um grande problema. A IU para adicionar tokens / usuários a grupos, painéis, etc. pode ser confusa e só ajudará um número muito pequeno de usuários.

No que diz respeito à aplicação efetiva do acesso às fontes de dados, não há diferença aqui do que com usuários regulares. A solução final para esse problema é mover os plug-ins da fonte de dados para o back-end e fazer com que o front-end despache as solicitações da fonte de dados especificando o painel, o painel, o intervalo de tempo e os valores de var do modelo e tendo as consultas reais criadas no back-end após validar que o usuário tem acesso e que os valores var do modelo são legítimos.

É aqui que acho que devemos começar a trabalhar para fornecer uma boa experiência de compartilhamento de painéis de maneira segura. Sem isso, todas as soluções parecem negociações ruins. Acho que deve ser mantido no mínimo até que o acesso à fonte de dados seja resolvido.

Também encontrei este problema com o painel incorporado no modo username+passwd+ldap auth ...
Alguma atualização sobre isso?

Estou muito interessado na opção de token do visualizador. Se eu puder ajudar de alguma forma, ficaria feliz em ajudar.

Ola pessoal!
Estou tentando criar um link autenticado para um dashbord, tenho um backend em java e um front end em JSF, quero colocar um usuário na tela que, ao ser clicado, redirecionará o usuário diretamente para seu painel, eu não estou entendendo bem o conceito, alguem Você tem um exemplo de como posso fazer isso?

Oi,

Só uma ideia, tentando ajudar. Por que não adicionar uma nova API de usuário, usando a autenticação básica como esta
? curl https://admin:admin<strong i="7">@localhost</strong>:3000/api/user/cookie
e obter um resultado JSON como
{"user_name":"admin","cookie_name":"grafana_,session":"a0b1c2d3e4","remember":"da27ef425e9e0d"}

Seria seguro via https, e eu poderia usar essas informações para forjar cookies e autorizar os usuários a ver seus lindos gráficos.

Eu olho com atenção o seu código e acho (com muito respeito ) que não seria muito difícil.
Em vez de enviar:
user.Rands+user.Password, setting.CookieRememberName, user.Login, days, setting.AppSubUrl+"/"

para a função SetSuperSecureCookie, você pode criar uma nova função, inspirada em SetSuperSecureCookie, mais ou menos assim:

func (ctx *Context) NewFunc(secret, name, value string, others ...interface{}) {
   key := pbkdf2.Key([]byte(secret), []byte(secret), 1000, 16, sha256.New)
   text, err := com.AESGCMEncrypt(key, []byte(value))
   return hex.EncodeToString(text)
}

A resposta pode ser elaborada e enviada como em uma de suas funções como:

func getUserUserProfile(userId int64) Response {
    query := m.GetUserProfileQuery{UserId: userId}

    if err := bus.Dispatch(&query); err != nil {
        return ApiError(500, "Failed to get user", err)
    }

    cook:= array
    result := {
        user_name: user.name,
                cookie_name:   cookie.name,
        session: s.session,
                remember: cokie.remember

    }

    return Json(200, &result)
}

Eu sei que você não é um mágico e que programar não é jogar Lego, mas esta é uma função muito importante para mim. Eu tentaria ajudar.

Durante o GrafanaCon, @DanCech mencionou a ideia de criar listas de reprodução públicas com uma chave GUID. Semelhante a como os instantâneos funcionam hoje. Compartilhar / armazenar essa chave pode ser considerado tão seguro quanto um token de API, mas limitado à exibição de listas de reprodução. A lista de reprodução pode ser associada ao criador / atualizador para validar as permissões de visualização do painel.

O URL pode ser algo como https://play.grafana.com/playlists/public/<hash>

Uma coisa que eu gosto nessa solução é que ela restringe a funcionalidade apenas para a exibição de listas de reprodução (painel), que eu acho que é o maior caso de uso para tokens como este.

Mas ainda precisaríamos fazer o login do usuário de alguma forma, já que as acl / anotações do painel, etc., exigirão autenticação do lado do servidor.

Acho que podemos pensar mais sobre esse tipo de solução. Eu queria principalmente contar nossa conversa da GrafanaCon :)

Obrigado @bergquist , definitivamente é bom

A próxima evolução desse pensamento foi adicionar o conceito de uma "tela" para desacoplar ainda mais as coisas, de modo que o usuário pudesse criar uma "tela" que tinha um url secreto com hash ao qual se conectaria. Isso teria a mesma finalidade, mas permitiria o gerenciamento das telas de dentro do Grafana, para que o usuário pudesse controlar qual lista de reprodução era exibida, etc.

O objetivo final aqui seria oferecer suporte a um mecanismo para um usuário criar facilmente um cartão SD ou imagem usb que pudesse ser usado para inicializar um pi de framboesa dedicado e exibir a lista de reprodução desejada com segurança do Grafana sem ter que passar por obstáculos de autenticação.

O objetivo final aqui seria oferecer suporte a um mecanismo para um usuário criar facilmente um cartão SD ou imagem usb que pudesse ser usado para inicializar um pi de framboesa dedicado e exibir a lista de reprodução desejada com segurança do Grafana sem ter que passar por obstáculos de autenticação.

@DanCech Este é exatamente o caso de uso que estou procurando.

A próxima evolução desse pensamento foi adicionar o conceito de uma "tela" para desacoplar ainda mais as coisas, de modo que o usuário pudesse criar uma "tela" que tinha um url secreto com hash ao qual se conectaria.

@DanCech Isso parece perfeito!

Olá a todos,

Isso parece estar um pouco longe da edição original aberta por Germanaz0

Deve ser bom ter um login automático passando um token de usuário por meio de url, essa pode ser uma solução parcial para incorporar iframes em sites.

e explicado por adamlwgriffiths

Temos nossa própria autenticação e painéis, queremos fornecer a capacidade de passar um usuário de nosso painel para o Grafana - de maneira semelhante à forma como o Heroku interopera com o New Relic e outros serviços sem senhas. Fornecer um método de autenticação url + token é parte do curso.

Germanaz0 desenvolve um script js

Agora mesmo resolvemos esse problema com um pequeno hack, adicionando um javascript que faz o login automático na grafana, mas é uma solução temporal

Eu entendo que eles precisam de um login automático para usar o gráfico grafana em seu próprio site. É disso que eu preciso também sem usar playlist ... Seria possível?

Se você deseja apenas registrar automaticamente um usuário, sua melhor aposta é usar http://docs.grafana.org/tutorials/authproxy/

@DanCech, o problema é que permitiria que todos os usuários se

@gzzo que depende do design do proxy

Também estou procurando esse recurso no Grafana.
Acho que o Microsoft Power BI embed é a boa solução. Veja os links abaixo.
https://github.com/Microsoft/PowerBI-JavaScript/wiki/Embedding-Basics
https://microsoft.github.io/PowerBI-JavaScript/demo/v2-demo/index.html

Acho que a solução PowerBi acima é baseada em OAuth2.
O lado do servidor Grafana deve suportar OAuth2 e habilitar CORS.

@Nayar Sou novo no Grafana. O que você quer dizer com estoque Grafana e estoque Nginx que você comentou em 14 de setembro de 2017? Você tem algum link de ambos?

Esperando ansiosamente pela versão 5.4, eu acho.

Conseguiu fazer isso com sucesso usando de Grafana auth.proxy e do Nginx ngx_http_secure_link_module

Os links que uso estão no formato http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Uma vez que o usuário clica nele, o cookie da sessão é definido e o usuário pode navegar pela grafana como se estivesse logado normalmente.

Vantagens:

• O link expira após algum tempo + segurança
• O link gera hash com ID do usuário, carimbo de data / hora e senha + segurança
• Não há necessidade de digitar a senha + comodidade

Minha conf nginx é assim

server {
  listen 3001 default_server;
#     listen [::]:3001 default_server;

  server_name _;

        location / {
      set $user "";
      set $state "";

      if ($args ~ "^user=(.+)&md5") {
                    set $user $1;
                    set $state "${state}U";
                }

      secure_link $arg_md5,$arg_expires;
                secure_link_md5 "$secure_link_expires$uri$user grafanarocks";

                if ($secure_link = "") { 
                    set $state "${state}S1";
                }

                if ($secure_link = "0") { 
                    set $state "${state}S2";
                }

                add_header X-uristate "$state";

                if ($state = "US1") { return 403; }
                if ($state = "US2") { return 410; }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://127.0.0.1:3000;
            }
    }

Sinta-se à vontade para entrar em contato comigo se precisar de ajuda com isso

Oi Nayar,
Estou tentando fazer a integração grafana com o SaaS.
O requisito é após o login do usuário no meu aplicativo web e clicar no link 'grafana' na minha página, ele irá redirecionar para o painel da grafana sem inserir nome de usuário e senha.

Seu comentário parece atender ao meu requisito. Mas ainda não estou certo sobre o processo de autenticação.
Quando proxy_pass to grafana, como verificar se o usuário é autenticado pelo meu próprio aplicativo.

Meu aplicativo da web é via X-XSRF-TOKEN para verificar a autoridade do usuário.

Sou novo na configuração do servidor. Agradecemos sua ajuda.

@torkelo / @bergquist Apenas um é assim que resolvemos isso no Screenly . É ao vivo e funciona muito bem! Obrigado pelo trabalho duro, pessoal!

@torkelo / @bergquist Apenas um é assim que resolvemos isso no Screenly . É ao vivo e funciona muito bem! Obrigado pelo trabalho duro, pessoal!

@vpetersson Não estou usando screenly, mas estou curioso para saber como você conseguiu implementar isso. Eu entendo a geração de um token de API. Você ainda fez iframe no URL? Como você anexou o token de autenticação aos cabeçalhos da solicitação?

@GimpMaster Nós apenas usamos o cabeçalho auth, então não há necessidade de iframes. Desde que escrevemos o player / navegador, fomos capazes de injetar o cabeçalho de autenticação no carregamento da página.

Acabei de fazer meu modo Kiosk funcionar usando a abordagem do Screenly que o @GimpMaster vinculou. Eu usei o Chrome Extension ModHeader onde adicionei o cabeçalho Authorization com a Bearer API Key. Mas, como as extensões precisam de algum tempo para carregar os 10s de sono de Configurar um quiosque no raspberry pi, o truque funcionou. Essa solução também funcionaria para iframes, mas deve ser configurada em cada cliente.

@Nayar Eu adaptei com sucesso sua configuração ngnix sugerida para usar o acesso _unsecure_. Ou seja, ele apenas pega o nome de usuário da string de consulta e o coloca no X-WEBAUTH-USER. Isso então obtém a id de sessão grafana e estamos fora. Obrigado!

Não consigo fazer o método md5 funcionar. Não estou certo sobre o que exatamente preciso fazer uma impressão digital MD5. Você poderia elaborar? Existem truques para fazer o md5?

É possível implementar alguma solução de login por token / cookie / header / ... na grafana 6. *?

Não consigo fazer isso com um painel de link simples em um PHP em branco

index.php

<html>
<body>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js" type="text/javascript"></script>
<script language="javaScript">
$( document ).ready(function() {
$.ajax({
        type: "GET",
        //url: "http://page.test;/grafana/",
        url: "http://page.test;/grafana/d/o24Tt1Cik/dashboard-test?orgId=1",
        contentType: "application/json",
        xhrFields: {
            withCredentials: false
        },
        beforeSend: function(request) {
                     request.setRequestHeader("X-WEBAUTH-USER", "admin");
                },
        headers: {
            // Set any custom headers here.
        "X-WEBAUTH-USER" : "admin"
        },
        success: function(data){
                var iframeDoc = $("#monitoringframe").get(0).contentDocument;
                iframeDoc.open();
                iframeDoc.write(data);
                iframeDoc.close();
//$("#monitoringframe").attr('srcdoc',data)
        },
        error : function(err) {
            console.log('Error!', err)
        }
    });
});

</script>
<iframe name="monitoringframe" id="monitoringframe" src="about:blank" sandbox="allow-forms allow-popups allow-same-origin allow-scripts" width=100% height=600 border="0" frameborder="0" />
</body>
</html>

nginx

 server {
  listen 80;
  server_name page.test;
  root /var/www/page;
  index index.html index.htm index.php;

        location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
        location /grafana/ {

                proxy_pass http://localhost:3000/;

       }

}

grafana.ini

[auth.proxy]
# Defaults to false, but set to true to enable this feature
enabled = true
# HTTP Header name that will contain the username or email
header_name = X-WEBAUTH-USER
# HTTP Header property, defaults to `username` but can also be `email`
header_property = username
# Set to `true` to enable auto sign up of users who do not exist in Grafana DB. Defaults to `true`.
auto_sign_up = true
# If combined with Grafana LDAP integration define sync interval
ldap_sync_ttl = 60
# Limit where auth proxy requests come from by configuring a list of IP addresses.
# This can be used to prevent users spoofing the X-WEBAUTH-USER header.
# Example `whitelist = 192.168.1.1, 192.168.1.0/24, 2001::23, 2001::0/120`
whitelist = 127.0.0.1, ::1/120
# Optionally define more headers to sync other user attributes
# Example `headers = Name:X-WEBAUTH-NAME Email:X-WEBAUTH-EMAIL`
headers =

[auth.basic]
;enabled = true

Eu testei alterar minha configuração nginx para isso e definir "? User = myUser" no url, mas só obtive uma resposta não autorizada

location /grafana/ {

                error_log /var/www/grafana/error.log;
                access_log /var/www/grafana/access.log;

                set $user "";

                if ($args ~ "^user=(.+)") {
                    set $user $1;
                }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://localhost:3000/;

       }

@ mr0bles Tudo sobre o proxy auth é explicado na documentação . Não vi uma solução anterior onde você chama o proxy com "X-WEBAUTH-USER - normalmente você autentica em seu proxy que por sua vez preenche e fornece X-WEBAUTH-USER para grafana.

@marefr obrigado pela resposta.
Eu li a documentação e minha API funciona, mas preciso de autenticação dinâmica do usuário (não a mesma permissão para todos os usuários da página)

Esta solução de @Nayar inclui o X-WEBAUTH-USER no cabeçalho sem codificá-lo, mas não consigo fazer funcionar

Acho que algo quebrou em 6.0 ou 6.1.
Atualizei uma instalação totalmente funcional usando o auth proxy no Apache2 para 6.1 ontem (de 5.3) e estou recebendo exatamente as mesmas telas que @ mr0bles

Observe que Grafana parece entender o cabeçalho do proxy: ele inicialmente faz o login do usuário, mas as solicitações subsequentes obtêm uma resposta 401.

@Bitblade , não recebemos nenhum outro relatório semelhante ao seu. Abra um novo relatório de bug, pois este problema está relacionado a uma solicitação de recurso.

Conseguiu fazer isso com sucesso usando de Grafana auth.proxy e do Nginx ngx_http_secure_link_module

Os links que uso estão no formato http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Uma vez que o usuário clica nele, o cookie da sessão é definido e o usuário pode navegar pela grafana como se estivesse logado normalmente.

Vantagens:

• O link expira após algum tempo + segurança
• O link gera hash com ID do usuário, carimbo de data / hora e senha + segurança
• Não há necessidade de digitar a senha + comodidade

Minha conf nginx é assim

server {
  listen 3001 default_server;
#     listen [::]:3001 default_server;

  server_name _;

        location / {
      set $user "";
      set $state "";

      if ($args ~ "^user=(.+)&md5") {
                    set $user $1;
                    set $state "${state}U";
                }

      secure_link $arg_md5,$arg_expires;
                secure_link_md5 "$secure_link_expires$uri$user grafanarocks";

                if ($secure_link = "") { 
                    set $state "${state}S1";
                }

                if ($secure_link = "0") { 
                    set $state "${state}S2";
                }

                add_header X-uristate "$state";

                if ($state = "US1") { return 403; }
                if ($state = "US2") { return 410; }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://127.0.0.1:3000;
            }
    }

Sinta-se à vontade para entrar em contato comigo se precisar de ajuda com isso

Esta solução não funciona para mim. Porque acho que cada solicitação deve conter um cabeçalho X-WEBAUTH-USER válido. Não funciona se você preencher o cabeçalho na primeira solicitação, pegar os cookies e ir com eles.

Terminei com a próxima solução:

server {
  listen 80 default_server;
  listen [::]:80 default_server;

  client_max_body_size 10m;
  root /foo/public;

  location /grafana/ {
    auth_request /gauth;
    auth_request_set $user $upstream_http_user;

    proxy_set_header X-WEBAUTH-USER $user;
    proxy_pass http://localhost:4000/;
  }

  location / {
    try_files $uri @app;
  }

  location <strong i="23">@app</strong> {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-SSL-Client-Cert $ssl_client_cert;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_redirect  off;
  }
}

Portanto, a solução usa o módulo auth_request nginx. Meu aplicativo é responsável pelo controle de acesso (solicitação / gauth) e retorna o nome de usuário no cabeçalho de resposta User .

Olá, enquanto isso, você pode usar minha solução descrita aqui: https://github.com/guysoft/FullPageOS/issues/175

Aqui está minha solução alternativa usando a autenticação OAuth genérica da Grafana e PHP: https://github.com/nbayramberdiyev/grafana-generic-oauth

Espero que isso ajude você.

só queria comentar como resolvi isso usando http auth basic https://github.com/grafana/grafana/issues/13706#issuecomment -540958284

Deve ser bom ter um login automático passando um token de usuário por meio de url, essa pode ser uma solução parcial para incorporar iframes em sites.

@rca você pode dar um exemplo com seu código? Eu copio seu código e embed.js, mas não funcionou.

Se você estiver usando oauth, há uma maneira de obter um grafana incorporado sem um login duplo

1. Configurar grafana com um único provedor de oauth e nenhum outro mecanismo de login
2. Defina GF_AUTH_OAUTH_AUTO_LOGIN como verdadeiro
3. Hospede grafana em um subcaminho e use um proxy reverso para que grafana seja servido no mesmo host que seu aplicativo principal
4. Conecte seu aplicativo principal e grafana ao mesmo provedor oauth (para o provedor oauth, eles serão o mesmo "aplicativo")
5. Grafana incorporada
6. Quando o iframe for carregado, grafana tentará fazer o login automaticamente com oauth (que deve funcionar, pois está no mesmo domínio de seu aplicativo principal, compartilhando assim o mesmo cookie de autenticação)

EDITAR: Você pode precisar definir security.cookie_samesite=none em grafana para que funcione corretamente em alguns navegadores (isso ocorre porque no iframe, um redirecionamento para o provedor de oauth (domínio diferente) está acontecendo e, em seguida, um redirecionamento de volta para o seu domínio grafana. Atualmente, o firefox não permite que um cookie do mesmo site definido como lax persista dessa forma. https://bugzilla.mozilla.org/show_bug.cgi?id=1454027 o que significa que a grafana perde seu oauth_state cookie se cookie_samesite não estiver definido como none )

@seanlaff Tentei sua solução com AWS Cognito mas ela retorna um cabeçalho que não permite colocá-lo em um iframe (X-Frame-Options: deny), alguma dica sobre isso?

Conseguiu fazer isso com sucesso usando de Grafana auth.proxy e do Nginx ngx_http_secure_link_module
Os links que uso estão no formato http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800
Uma vez que o usuário clica nele, o cookie da sessão é definido e o usuário pode navegar pela grafana como se estivesse logado normalmente.
Vantagens:

• O link expira após algum tempo + segurança
• O link gera hash com ID do usuário, carimbo de data / hora e senha + segurança
• Não há necessidade de digitar a senha + comodidade

Minha conf nginx é assim

server {
    listen 3001 default_server;
#   listen [::]:3001 default_server;

    server_name _;

        location / {
        set $user "";
        set $state "";

        if ($args ~ "^user=(.+)&md5") {
                    set $user $1;
                    set $state "${state}U";
                }

        secure_link $arg_md5,$arg_expires;
                secure_link_md5 "$secure_link_expires$uri$user grafanarocks";

                if ($secure_link = "") { 
                    set $state "${state}S1";
                }

                if ($secure_link = "0") { 
                    set $state "${state}S2";
                }

                add_header X-uristate "$state";

                if ($state = "US1") { return 403; }
                if ($state = "US2") { return 410; }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://127.0.0.1:3000;
            }
    }

Sinta-se à vontade para entrar em contato comigo se precisar de ajuda com isso

Esta solução não funciona para mim. Porque acho que cada solicitação deve conter um cabeçalho X-WEBAUTH-USER válido. Não funciona se você preencher o cabeçalho na primeira solicitação, pegar os cookies e ir com eles.

Terminei com a próxima solução:

server {
  listen 80 default_server;
  listen [::]:80 default_server;

  client_max_body_size 10m;
  root /foo/public;

  location /grafana/ {
    auth_request /gauth;
    auth_request_set $user $upstream_http_user;

    proxy_set_header X-WEBAUTH-USER $user;
    proxy_pass http://localhost:4000/;
  }

  location / {
    try_files $uri @app;
  }

  location <strong i="24">@app</strong> {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-SSL-Client-Cert $ssl_client_cert;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_redirect  off;
  }
}

Portanto, a solução usa o módulo auth_request nginx. Meu aplicativo é responsável pelo controle de acesso (solicitação / gauth) e retorna o nome de usuário no cabeçalho de resposta User .

como usar com iframe?
eu sou novo no Grafana e no NGINX
então, por favor, compartilhe os detalhes máximos agora para modificar

como usar com iframe?

@pgsekaran esta solução não é para iframe, mas para obter a interface de usuário grafana sem login grafana explícito para usuários de seu aplicativo. O aplicativo, neste caso, é um proxy que sabe como fazer o login no grafana.

Oi,
Obrigado pela resposta rápida. você tem algum link com referência para adicionar o Grafana com outro aplicativo usando iframe.i adicionar Grafana ao meu aplicativo, mas não consigo definir o gerenciamento de uso.
RegardsGuna
Na terça-feira, 23 de junho de 2020, 21:54:57 GMT + 5: 30, Konstantin Kolotyuk [email protected] escreveu:

como usar com iframe?

@pgsekaran esta solução não é para iframe, mas para obter a interface de usuário grafana sem login grafana explícito para usuários de seu aplicativo. O aplicativo, neste caso, é um proxy que sabe como fazer o login no grafana.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou cancele a inscrição.

Ainda não foi implementado? Sério, esse é um bom recurso.

@pgsekaran eu tenho uma solução para iframe, que não é muito segura porque usa login baseado em nome de usuário e depende de nomes de usuário que não são facilmente adivinhados. basicamente, o nome de usuário é o token.
Eu escrevi sobre isso aqui, não com muitos detalhes, mas eouhg para você começar
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

@pgsekaran eu tenho uma solução para iframe, que não é muito segura porque usa login baseado em nome de usuário e depende de nomes de usuário que não são facilmente adivinhados. basicamente, o nome de usuário é o token.
Eu escrevi sobre isso aqui, não com muitos detalhes, mas eouhg para você começar
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

Oi,

Preciso configurar com NGINX e iframe com login automático

O problema exato foi explicado em https://github.com/grafana/grafana/issues/16319#issuecomment -483272921: O ID da sessão não é retornado com a primeira resposta que contém o "esqueleto" da página. As solicitações subsequentes não contêm o token de login automático, portanto, elas falham.

Usamos cromo no modo quiosque para exibir os painéis do Grafana em vários lugares. Como a mesma instância Grafana também está disponível para usuários, usamos auth.generic_oauth ( auth.basic até 5.x) para fazer login de humanos e auth.proxy para fazer login em máquinas em modo quiosque:

/usr/bin/chromium --app="https://server.localdomain/grafana/d/000000004/002-the-big-picture?orgId=1&refresh=5m&autologin=lHOrdypkhxzNYb2lRaIjbNPlOCZw9gWE"

Como outros notaram, isso não funciona simplesmente. O que funcionaria é primeiro chamar a url http://prometheus.localdomain/grafana/login?autologin=lHOrdypkhxzNYb2lRaIjbNPlOCZw9gWE (que agora define o cookie grafana_session ) e, em seguida, redirecionar para o painel real. Mas ... modo quiosque 🤷 e iframes 🤦‍♂️

Nossa solução final de trabalho é combinar o parâmetro de consulta autologin com um cookie personalizado. Sim, você não pode fazer logout por meio da GUI, pois o cookie personalizado não é excluído, mas como esse mecanismo só é usado nas máquinas em modo quiosque, não há necessidade disso.

Então, aqui está a configuração do nginx para o Grafana Server:

# this maps tokens to grafana users
map $arg_autologin $autologin {
    lHOrdypkhxzNYb2lRaIjbNPlOCZw9gWE "display-1";
    default "";
}

server {
    listen 80;

    server_name server.localdomain;

    # add_header cannot be used in an "if"-context
    # so we set it to an empty string here as 
    # `add_header Set-Cookie "";` just removes the complete
    # header from the response
    set $setCookieHeader "";

    # when the autologin query param is not set, use
    # the value from the cookie named `grafana_autologin`
    if ($arg_autologin = "") {
        set $arg_autologin $cookie_grafana_autologin;
    }

    # when either the autologin query param or the `grafana_autologin`
    # cookie was set, place the autologin token and the cookie path
    # in the variable. `path=/` is needed to allow deeplinking
    if ($arg_autologin != "") {
        set $setCookieHeader "grafana_autologin=$arg_autologin;path=/";
    }

    location /grafana/ {
        rewrite  ^/grafana/(.*)  /$1 break;

        # now send the Set-Cookie header when an autologin token was provided
        add_header Set-Cookie $setCookieHeader;

        # look up the autologin token in the map above and set the grafana user
        proxy_set_header X-WEBAUTH-USER $autologin;
        proxy_pass http://localhost:3000;
    }
}