Git push via HTTP
-
10 de Novembro de 2015 às 14:36Ola seocam, terceiro,
Segue um descritivo do que fiz acerca do push via HTTP(S):
A ideia era fazer o colab interceptar as requisicoes do tipo 'git push
(repositorio http)', digamos assim. Pra isso, o plugin do Colab,
responsavel por encaminhar requisicoes ao Gitlab, teve o metodo 'dispatch'
sobrescrito pra detectar o cabecalho 'HTTP_AUTHORIZATION', requisitado pelo
Gitlab pra que o cliente envie login:password. Assim eh possivel receber as
credenciais que o usuario digita e usa-las pra logar no Colab. Commit:
https://github.com/colab/colab-gitlab-plugin/commit/2dd113ae55933470948adbabbe1dfcf3e2fe731f
Na outra ponta foi necessario customizar o Gitlab pra nao precisar de senha
para requisicoes do tipo 'git push (repositorio http)', igual acontece com
o RemoteUser. A parte do codigo onde essa autenticacao acontece ta aqui
https://github.com/gitlabhq/gitlabhq/blob/v7.6.2/lib/gitlab/backend/grack_auth.rb#L75.
O patch que fiz pra autenticar o usuario somente com login esta em anexo em
'http_push.patch'.
Eu testei num ambiente com Colab + Gitlab numa VM na DO e funcionou,
qualquer coisa me avisem que eu dou acesso lah pra validacao de conceitos...
Charles -
10 de Novembro de 2015 às 17:17Oi Charles,
On Tue, Nov 10, 2015 at 09:35:50AM -0500, Charles Oliveira wrote:> Ola seocam, terceiro,
>
> Segue um descritivo do que fiz acerca do push via HTTP(S):
>
> A ideia era fazer o colab interceptar as requisicoes do tipo 'git push
> (repositorio http)', digamos assim. Pra isso, o plugin do Colab,
> responsavel por encaminhar requisicoes ao Gitlab, teve o metodo 'dispatch'
> sobrescrito pra detectar o cabecalho 'HTTP_AUTHORIZATION', requisitado pelo
> Gitlab pra que o cliente envie login:password. Assim eh possivel receber as
> credenciais que o usuario digita e usa-las pra logar no Colab. Commit:
>https://github.com/colab/colab-gitlab-plugin/commit/2dd113ae55933470948adbabbe1dfcf3e2fe731f
>
> Na outra ponta foi necessario customizar o Gitlab pra nao precisar de senha
> para requisicoes do tipo 'git push (repositorio http)', igual acontece com
> o RemoteUser. A parte do codigo onde essa autenticacao acontece ta aqui
>https://github.com/gitlabhq/gitlabhq/blob/v7.6.2/lib/gitlab/backend/grack_auth.rb#L75.
> O patch que fiz pra autenticar o usuario somente com login esta em anexo em
> 'http_push.patch'.
>
> Eu testei num ambiente com Colab + Gitlab numa VM na DO e funcionou,
> qualquer coisa me avisem que eu dou acesso lah pra validacao de conceitos...muito legal!> diff -Nru gitlab-7.6.2/lib/gitlab/backend/grack_auth.rb gitlab/lib/gitlab/backend/grack_auth.rb
> --- gitlab-7.6.2/lib/gitlab/backend/grack_auth.rb 2014-12-30 17:51:58.000000000 -0500
> +++ gitlab/lib/gitlab/backend/grack_auth.rb 2015-11-09 17:20:23.249000000 -0500
> @@ -72,8 +72,7 @@
> end
>
> def authenticate_user(login, password)
> - auth = Gitlab::Auth.new
> - auth.find(login, password)
> + User.find_by_email(login) || User.find_by_username(login)
> endeu acho que vc teria que buscar uma forma que o patch possa ser aceito
no gitlab upstream (claramente esse nunca seria), senão a gente vai ter
que carregar esse patch pra sempre.
pode ser por exemplo um item na configuração dizendo pro gitlab não
validar a senha neste ponto porquê alguém na frente dele (um servidor
web) estaria fazendo isso.
além disso, eu acho que isso é tratado diferente no gitlab mais novo, e
a gente não pode ficar pra sempre no gitlab antigo.
--
Antonio Terceiro
http://softwarelivre.org/terceiro -
10 de Novembro de 2015 às 21:44Em 10 de novembro de 2015 15:13, Antonio Terceiro <
terceiro@softwarelivre.org> escreveu:> Oi Charles,
>
> On Tue, Nov 10, 2015 at 09:35:50AM -0500, Charles Oliveira wrote:
> > Ola seocam, terceiro,
> >
> > Segue um descritivo do que fiz acerca do push via HTTP(S):
> >
> > A ideia era fazer o colab interceptar as requisicoes do tipo 'git push
> > (repositorio http)', digamos assim. Pra isso, o plugin do Colab,
> > responsavel por encaminhar requisicoes ao Gitlab, teve o metodo
> 'dispatch'
> > sobrescrito pra detectar o cabecalho 'HTTP_AUTHORIZATION', requisitado
> pelo
> > Gitlab pra que o cliente envie login:password. Assim eh possivel receber
> as
> > credenciais que o usuario digita e usa-las pra logar no Colab. Commit:
> >
>https://github.com/colab/colab-gitlab-plugin/commit/2dd113ae55933470948adbabbe1dfcf3e2fe731f
> >
> > Na outra ponta foi necessario customizar o Gitlab pra nao precisar de
> senha
> > para requisicoes do tipo 'git push (repositorio http)', igual acontece
> com
> > o RemoteUser. A parte do codigo onde essa autenticacao acontece ta aqui
> >
>https://github.com/gitlabhq/gitlabhq/blob/v7.6.2/lib/gitlab/backend/grack_auth.rb#L75
> .
> > O patch que fiz pra autenticar o usuario somente com login esta em anexo
> em
> > 'http_push.patch'.
> >
> > Eu testei num ambiente com Colab + Gitlab numa VM na DO e funcionou,
> > qualquer coisa me avisem que eu dou acesso lah pra validacao de
> conceitos...
>
> muito legal!
>
> > diff -Nru gitlab-7.6.2/lib/gitlab/backend/grack_auth.rb
> gitlab/lib/gitlab/backend/grack_auth.rb
> > --- gitlab-7.6.2/lib/gitlab/backend/grack_auth.rb 2014-12-30
> 17:51:58.000000000 -0500
> > +++ gitlab/lib/gitlab/backend/grack_auth.rb 2015-11-09
> 17:20:23.249000000 -0500
> > @@ -72,8 +72,7 @@
> > end
> >
> > def authenticate_user(login, password)
> > - auth = Gitlab::Auth.new
> > - auth.find(login, password)
> > + User.find_by_email(login) || User.find_by_username(login)
> > end
>
> eu acho que vc teria que buscar uma forma que o patch possa ser aceito
> no gitlab upstream (claramente esse nunca seria), senão a gente vai ter
> que carregar esse patch pra sempre.
>
> pode ser por exemplo um item na configuração dizendo pro gitlab não
> validar a senha neste ponto porquê alguém na frente dele (um servidor
> web) estaria fazendo isso.
>
> além disso, eu acho que isso é tratado diferente no gitlab mais novo, e
> a gente não pode ficar pra sempre no gitlab antigo.
>
>Pelo o que foi investigado, ainda podemos tentar pensar em uma solução que
não tenha que, necessariamente, mexer em algo no GitLab em si, ou não tem
como fazer de forma "certa" sem isso?
Muito bom, Charles! Contamos com esse seu gás para acharmos uma solução
para este problema ;)
obrigado,
--
Paulo Meirelles
FGA-UnB (http://fga.unb.br)
CCSL-IME/USP (http://ccsl.ime.usp.br) -
11 de Novembro de 2015 às 13:00On Tue, Nov 10, 2015 at 07:44:38PM -0200, Paulo Meirelles wrote:> Em 10 de novembro de 2015 15:13, Antonio Terceiro
escreveu:
>
> > Oi Charles,
> >
> > On Tue, Nov 10, 2015 at 09:35:50AM -0500, Charles Oliveira wrote:
> > > diff -Nru gitlab-7.6.2/lib/gitlab/backend/grack_auth.rb
> > gitlab/lib/gitlab/backend/grack_auth.rb
> > > --- gitlab-7.6.2/lib/gitlab/backend/grack_auth.rb 2014-12-30
> > 17:51:58.000000000 -0500
> > > +++ gitlab/lib/gitlab/backend/grack_auth.rb 2015-11-09
> > 17:20:23.249000000 -0500
> > > @@ -72,8 +72,7 @@
> > > end
> > >
> > > def authenticate_user(login, password)
> > > - auth = Gitlab::Auth.new
> > > - auth.find(login, password)
> > > + User.find_by_email(login) || User.find_by_username(login)
> > > end
> >
> > eu acho que vc teria que buscar uma forma que o patch possa ser aceito
> > no gitlab upstream (claramente esse nunca seria), senão a gente vai ter
> > que carregar esse patch pra sempre.
> >
> > pode ser por exemplo um item na configuração dizendo pro gitlab não
> > validar a senha neste ponto porquê alguém na frente dele (um servidor
> > web) estaria fazendo isso.
> >
> > além disso, eu acho que isso é tratado diferente no gitlab mais novo, e
> > a gente não pode ficar pra sempre no gitlab antigo.
> >
> >
> Pelo o que foi investigado, ainda podemos tentar pensar em uma solução que
> não tenha que, necessariamente, mexer em algo no GitLab em si, ou não tem
> como fazer de forma "certa" sem isso?Uma forma "simples" de fazer seria no plugin do colab para gitlab,
implementar um hook que atualize a senha no banco do gitlab toda vez que
atualizar no banco do colab. Assim, a senha que estiver valendo no colab
vai ser a mesma senha que está valendo no gitlab, e tudo vai
"simplesmente funcionar". Pra isso a gente provavelmente precisaria ver
como o gitlab cifra a senha no banco de dados, e fazer igual no plugin
no colab. -
11 de Novembro de 2015 às 14:07Em 11 de novembro de 2015 11:00, Antonio Terceiro <terceiro@softwarelivre.org> escreveu:
> On Tue, Nov 10, 2015 at 07:44:38PM -0200, Paulo Meirelles wrote:
> > Em 10 de novembro de 2015 15:13, Antonio Terceiro <
> terceiro@softwarelivre.org> escreveu:
> >
> > > Oi Charles,
> > >
> > > On Tue, Nov 10, 2015 at 09:35:50AM -0500, Charles Oliveira wrote:
> > > > diff -Nru gitlab-7.6.2/lib/gitlab/backend/grack_auth.rb
> > > gitlab/lib/gitlab/backend/grack_auth.rb
> > > > --- gitlab-7.6.2/lib/gitlab/backend/grack_auth.rb 2014-12-30
> > > 17:51:58.000000000 -0500
> > > > +++ gitlab/lib/gitlab/backend/grack_auth.rb 2015-11-09
> > > 17:20:23.249000000 -0500
> > > > @@ -72,8 +72,7 @@
> > > > end
> > > >
> > > > def authenticate_user(login, password)
> > > > - auth = Gitlab::Auth.new
> > > > - auth.find(login, password)
> > > > + User.find_by_email(login) || User.find_by_username(login)
> > > > end
> > >
> > > eu acho que vc teria que buscar uma forma que o patch possa ser aceito
> > > no gitlab upstream (claramente esse nunca seria), senão a gente vai ter
> > > que carregar esse patch pra sempre.
> > >
> > > pode ser por exemplo um item na configuração dizendo pro gitlab não
> > > validar a senha neste ponto porquê alguém na frente dele (um servidor
> > > web) estaria fazendo isso.
> > >
> > > além disso, eu acho que isso é tratado diferente no gitlab mais novo, e
> > > a gente não pode ficar pra sempre no gitlab antigo.
> > >
> > >
> > Pelo o que foi investigado, ainda podemos tentar pensar em uma solução
> que
> > não tenha que, necessariamente, mexer em algo no GitLab em si, ou não tem
> > como fazer de forma "certa" sem isso?
>
> Uma forma "simples" de fazer seria no plugin do colab para gitlab,
> implementar um hook que atualize a senha no banco do gitlab toda vez que
> atualizar no banco do colab. Assim, a senha que estiver valendo no colab
> vai ser a mesma senha que está valendo no gitlab, e tudo vai
> "simplesmente funcionar". Pra isso a gente provavelmente precisaria ver
> como o gitlab cifra a senha no banco de dados, e fazer igual no plugin
> no colab.
>Parece-me, bom e melhor =) -
12 de Novembro de 2015 às 14:43Desculpa a demora na resposta, tirei uma folga ontem.TerceiroAcho boa a ideia tambem, beeeem mais simples.
Uma alternativa seria manter a senha usando a API do gitlab (
https://github.com/gitlabhq/gitlabhq/blob/master/doc/api/users.md#user-modification
).
Dai entao precisariamos de um token de algum usuario admin no Gitlab (acho
que ja temos um) e invocar a mudanca de senha via API, que ja evita
problemas de validacao no Gitlab.
No colab seria colocar o hook aqui:
https://github.com/colab/colab/blob/master/colab/accounts/views.py#L185 e
eh pra funcionar =)
Paulo,
Isso eh pra a proxima atualizacao?Charles2015-11-11 9:07 GMT-05:00 Paulo Meirelles: > Em 11 de novembro de 2015 11:00, Antonio Terceiro <
> terceiro@softwarelivre.org> escreveu:
>
>> On Tue, Nov 10, 2015 at 07:44:38PM -0200, Paulo Meirelles wrote:
>> > Em 10 de novembro de 2015 15:13, Antonio Terceiro <
>> terceiro@softwarelivre.org> escreveu:
>> >
>> > > Oi Charles,
>> > >
>> > > On Tue, Nov 10, 2015 at 09:35:50AM -0500, Charles Oliveira wrote:
>> > > > diff -Nru gitlab-7.6.2/lib/gitlab/backend/grack_auth.rb
>> > > gitlab/lib/gitlab/backend/grack_auth.rb
>> > > > --- gitlab-7.6.2/lib/gitlab/backend/grack_auth.rb 2014-12-30
>> > > 17:51:58.000000000 -0500
>> > > > +++ gitlab/lib/gitlab/backend/grack_auth.rb 2015-11-09
>> > > 17:20:23.249000000 -0500
>> > > > @@ -72,8 +72,7 @@
>> > > > end
>> > > >
>> > > > def authenticate_user(login, password)
>> > > > - auth = Gitlab::Auth.new
>> > > > - auth.find(login, password)
>> > > > + User.find_by_email(login) || User.find_by_username(login)
>> > > > end
>> > >
>> > > eu acho que vc teria que buscar uma forma que o patch possa ser aceito
>> > > no gitlab upstream (claramente esse nunca seria), senão a gente vai
>> ter
>> > > que carregar esse patch pra sempre.
>> > >
>> > > pode ser por exemplo um item na configuração dizendo pro gitlab não
>> > > validar a senha neste ponto porquê alguém na frente dele (um servidor
>> > > web) estaria fazendo isso.
>> > >
>> > > além disso, eu acho que isso é tratado diferente no gitlab mais novo,
>> e
>> > > a gente não pode ficar pra sempre no gitlab antigo.
>> > >
>> > >
>> > Pelo o que foi investigado, ainda podemos tentar pensar em uma solução
>> que
>> > não tenha que, necessariamente, mexer em algo no GitLab em si, ou não
>> tem
>> > como fazer de forma "certa" sem isso?
>>
>> Uma forma "simples" de fazer seria no plugin do colab para gitlab,
>> implementar um hook que atualize a senha no banco do gitlab toda vez que
>> atualizar no banco do colab. Assim, a senha que estiver valendo no colab
>> vai ser a mesma senha que está valendo no gitlab, e tudo vai
>> "simplesmente funcionar". Pra isso a gente provavelmente precisaria ver
>> como o gitlab cifra a senha no banco de dados, e fazer igual no plugin
>> no colab.
>>
>
> Parece-me, bom e melhor =)
>
> obrigado,
> --
> Paulo Meirelles
> FGA-UnB (http://fga.unb.br)
> CCSL-IME/USP (http://ccsl.ime.usp.br)
>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
>
--
Charles OliveiraJunior Software Engineer -
12 de Novembro de 2015 às 16:05On Thu, Nov 12, 2015 at 09:43:21AM -0500, Charles Oliveira wrote:> Desculpa a demora na resposta, tirei uma folga ontem.
>
> Terceiro
> Acho boa a ideia tambem, beeeem mais simples.
> Uma alternativa seria manter a senha usando a API do gitlab (
>https://github.com/gitlabhq/gitlabhq/blob/master/doc/api/users.md#user-modification
> ).
> Dai entao precisariamos de um token de algum usuario admin no Gitlab (acho
> que ja temos um)sim, temos. o plugin para gitlab do colab já usa inclusive pra fazer
outras coisas.> e invocar a mudanca de senha via API, que ja evita
> problemas de validacao no Gitlab.sim, porque o gitlab também tem controle de acesso configurado por
repositório né.> No colab seria colocar o hook aqui:
>https://github.com/colab/colab/blob/master/colab/accounts/views.py#L185 e
> eh pra funcionar =)yep, mande ver> Paulo,
> Isso eh pra a proxima atualizacao?isso é uma pendência desde o início do projeto, então é pra "ontem".
acho que isso é importante o suficiente pra gente fazer uma atualização
só pra isso se for o caso.
--Antonio Terceiro
http://softwarelivre.org/terceiro -
12 de Novembro de 2015 às 16:20Em 12 de novembro de 2015 12:43, Charles Oliveira <
18oliveira.charles@gmail.com> escreveu:> Desculpa a demora na resposta, tirei uma folga ontem.
>
> Terceiro
> Acho boa a ideia tambem, beeeem mais simples.
> Uma alternativa seria manter a senha usando a API do gitlab (
>https://github.com/gitlabhq/gitlabhq/blob/master/doc/api/users.md#user-modification
> ).
> Dai entao precisariamos de um token de algum usuario admin no Gitlab (acho
> que ja temos um) e invocar a mudanca de senha via API, que ja evita
> problemas de validacao no Gitlab.
> No colab seria colocar o hook aqui:
>https://github.com/colab/colab/blob/master/colab/accounts/views.py#L185 e
> eh pra funcionar =)
>
> Paulo,
> Isso eh pra a proxima atualizacao?
>Trataremos em uma de nossas reuniões, em voz.
abraços!
--
Ordenar por:
Relacionado:
- e-sic-livre Inauguração da Lista e-sic-livre
- i-educar Instalação do i-Educar
- e-sic-livre Nova versão do e-SIC Livre!
- spb-dev Kanboard - Kanban com suporte integração ao Gitlab
- e-sic-livre Erro no envio de solicitação
- spb-dev Recuperação de senha do novo portal
- i-educar Guia de instalação do i-Educar atualizado para...
- gsan Dúvidas relacionadas ao Software Gsan
- spb-dev Status do dia
- spb-dev Revisão das funcionalidades da R1
Estatísticas:
-
iniciada em
8 anos, 6 meses atrás
-
vizualizada
1731 vezes
-
respondida
8 vezes
-
votada
0 vezes