Login via Linkedin #7
Comments
|
O ideal seria logar via N redes sociais (fb, twitter, ...) |
|
Não concordo, é um site profissional, se fosse um site de entretenimento tudo bem, mas não é o foco. Estou partindo do pressuposto de que um "desenvolvedor" sem linkedin não está a fim de entrar no mercado ou sequer de trabalhar. É quase um medico querendo ser medico sem um CRM. |
|
Então o ideal seria logar via github, que é onde dá pra falar que o cara é realmente um dev. |
|
Concordo com @caferrari, mas eu também incluiria o Google. Caso seja aprovado as 3 redes social, eu acho que a gente tem que quebrar em 3 tarefas. |
|
Nesse caso, acho importante o incluir o Google também, como @robsonpeixoto comentou. |
|
não acho interessante login obrigatório apenas por linkedin... podemos ter autenticação do Linkedin, github e google e permitir no perfil ainda colocar o user do stackoverflow ou outros |
|
Boa observação @kinncj, eu não tinha focado direito na citação de obrigatoriedade, isso chegaria a ser absurdo. Alternativa sim, agora obrigatoriedade não seria algo bom. |
|
Acho que deveria ter login via Facebook, mano. Facebook já deixou de ser uma rede de entretenimento, como falado anteriormente, há muito tempo... |
|
Talvez para um segundo milestone seja muito legal, não apenas 1, mas permitir login com vários serviços. Mas não vejo esse recurso como essencial nessa primeira versão. |
|
Verdade @netojoaobatista |
|
Poderia ter botão de like para comentários das issues do github haha |
|
Acho importante, ainda que futuramente, ter login com multiplos providers. |
|
Pensando em uma versão futura, dois serviços que acho fundamentais que tenhamos integração:
Github pois, como é um projeto voltado para devs, nada melhor projetos em que o usuário colabora, para saber mais sobre ele. Linked-in pois, como é um projeto voltado para oportunidades de trabalho, nada melhor que uma outra rede focada nisso. |
|
como o @netojoaobatista comentou, precisamos reduzir o escopo desse primeiro sprint, afinal, o tempo é reduzido. |
|
kkkk doce é? Twitter ou facebook |
|
@iannsp, penso que nessa primeira entrega não deveríamos ter integração com nenhuma rede social. Acho melhor focar em uma identificação e autenticação simples, feita dentro da própria app, do que lidar com esse tipo de integração na primeira entrega. Digo isso porque acredito, veementemente, que se envolvermos essa integração agora, não conseguiremos entregar o produto no prazo. |
|
como o @netojoaobatista comentou acho que isso pode ficar pra proxima sprint. |
|
Pensando bem, acho que o primeiro sprint nem precisaria de autenticação. Ainda não faremos nada com os dados de quem tá autenticado e certamente reduzir o escopo pra conseguir entregar algo funcionando durante o Hangout seria maneiro. Que acham? |
|
+1 @alganet |
|
Concordo com o @netojoaobatista. Não vai rolar essas autenticações agora. Vamos ser simples. Estava conversando com o @alganet e ele sugeriu algumas opções, uma delas é: O produto pode se basear apenas em uma listagem simples de oportunidades, e um cadastro da mesma. Devs que irão atrás das oportunidades não precisa de autenticação, ele pode simplesmente visualizar a oportunidade. |
|
Perfeito @wesleyvicthor e @alganet, podemos fechar a questão de identificação dessa forma.
|
|
Pra mim faz sentido @netojoaobatista, o único problema é termos que guardar senha para a identificação por email. |
|
@henriquemoody pra que senha ? Não vejo a necessidade de senha. apenas de email. Caso seja o primeiro cadastro de oportunidade o usuário confirma o cadastro por email, uma vez confirmado aquele email pode cadastrar oportunidades(com um limite ou não...) |
|
Sei lá @henriquemoody, acho mais barato trabalharmos com email e senha, do que implementar um client OAuth. Mesmo que ainda não tenhamos Password Hashing no PHP, acho que simplificamos as coisas com um SHA-2 para a senha. @wesleyvicthor, acho a senha importante para não haver problemas com "trolls". Se não for necessário uma senha, qualquer pessoa poderá cadastrar uma oferta "besta", como sendo qualquer outra pessoa. Se formos pedir a confirmação do email toda vez, o processo ficará burocrático para o usuário. Por isso, acho importante a identificação por email e autenticação por senha. |
|
Concoro @netojoaobatista um ponto importante, http basic, certo? |
|
Concordo @henriquemoody, nessa primeira versão, HTTP Basic resolve o problema. |
|
Também acho a ideia de logar com Github e Linkedin show de bola. Mas realmente é melhor para os próximos sprints. Creio que nesse sprint deva ser tratado apenas a Oportunidade em si. |
|
Pô, a gente não precisa de senha agora. Seria bacana ter, mas não precisa. Nosso Minimum Viable Product é um formulário para novas oportunidades e uma lista com todas elas listadas em ordem cronológica decrescente. As pessoas vão ao Facebook postar freelas porque querem isso. Pra isso, ninguém precisa se autenticar pra nada. Podemos tentar prever alguns problemas com esse MVP, como flood de vagas e pessoas que querem remover ou alterar vagas já publicadas, mas essas são áreas cinza e não sabemos como o usuário realmente quer interagir com o produto, quanto menos fizermos melhor. Um problema clássico em autenticação precoce é o conceito de identidade pessoal vs. identidade corporativa. Com login via LinkedIn ou GitHub, teremos apenas identidade pessoal (pessoas postando vagas) e não corporativa (empresas postando vagas). Eu usaria o HTTP basic só pra moderação e/ou administração, e deixaria o site público nessa primeira versão. O primeiro sprint também não significa que publicaremos esse código logo que terminarmos, é mais sobre tentar separar grandes tarefas em coisas menores e ainda entregáveis (le alma do scrum). Se conseguirmos a versão "mural basicão" em 2h do Hangout, temos tempo suficiente depois pra iterar novamente sobre a base que já estaria construída. Fazer dois sprints (obviamente ajustados e simplificados pra velocidade de um Hangout) seria até uma boa idéia pra mostrar pra galera. E também acho que deveríamos sempre lembrar que o objetivo principal é ensinar o povo a praticar TDD e demais metodologias ágeis relacionadas, não criar uma startup =D (embora uma startup nascendo dessa idéia seja tentador) |
|
@alganet Não publicar parte desse código ao meu ver foge de todo o propósito, daí a necessidade de autenticação. |
|
Alguém mais insiste na senha ? |
|
Meu ponto de vista para essa primeira versão:
|
|
@henriquemoody publicar é um objetivo do hangout, claro que iremos fazer isso. Publicar o código também é inevitável, já que trabalharemos remotamente. O que eu dizia é que teremos 4h de hangout, e podemos fazer um sprint menor pra pegar o jeito, e assim que tivermos pego o jeito e feito a primeira entrega, talvez ainda sobre um tempo nessas 4h pra fazer um segundo sprint que melhora o projeto inicial. Esse primeiro antes das 4h não precisa ir ao ar definitivamente, pode entrar num beta.oportunidades.blabalbal temporariamente. Login é uma grande piça no rabo pra qualquer produto novo. Se cadastrarmos a senha agora e migrarmos pra OAuth no futuro, o que fazemos pra migrar os caras? Manteríamos dois modos de autenticação? Gastaríamos mais esforço pra criar uma tela de migração? OAuth define público alvo também, estamos certos de que o público alvo que posta freelas no Facebook tem LinkedIn ou qualquer outro serviço? É uma área bastante cinza da aplicação ainda. Quando eu mencionei o email, eu pensei em algo bem mais simples. O cara preenche o email dele quando for publicar a vaga e assim que ele enviar ele recebe um email do sistema com dois links: um pra publicar a vaga efetivamente e um pra excluir a vaga, caso ela esteja com algum problema. Esses dois mecanismos podem facilmente sobreviver compatíveis com as próximas features do sistema, ao contrário do OAuth e user/pass que limitam nossa extensibilidade no futuro. |
|
Penso que OAuth deve sempre ser uma opção, não um requisito. Dessa forma, sempre teremos os dois tipos de autenticação. btw, nada que um Decorator não resolva no futuro, quando tivermos que lidar com os dois modos de autenticação. |
|
@netojoaobatista a parte de código tranquilo, confio que todo mundo aqui conseguiria implementar autenticação múltipla. Minha principal preocupação é se os nossos usuários realmente precisam de autenticação pra essa primeira versão, e se o esforço de implementá-la agora traria algum valor (ou algum incômodo) pro usuário. |
|
A ideia do @alganet é bacana, assim quem posta não precisa se preocupar com autenticação (só gera uma tarefa a mais no fluxo de cadastro da proposta). |
|
Só queria saber em que a senha iria agregar agora. |
|
Okay @alganet, podemos fazer o seguinte:
Implementamos a ferramenta de forma simples e deixamos questões de identificação, autenticação e autorização para um segundo milestone. A autorização, no próximo milestone, será fundamental para a administração da plataforma, uma vez que a publicação de oportunidades será aberta, precisaremos ter uma estrutura de moderação para evitar SPAM e flood. Após termos a estrutura administrativa, vemos sobre a questão de integração com outras plataformas. |
|
+1 |
1 similar comment
|
+1 |
|
+1 @iannsp Precisamos agora quebrar essa issue nas devidas partes citando essa issue. Assim conseguimos ter um histórico bacana =D |
|
+1 |
Considerando a importância que o Linkedin vem tendo, principalmente na nossa área, ter uma conta lá é essencial, por isso acho mais do que interessante ser obrigatório o Login via a API deles.
http://developer.linkedin.com/documents/sign-linkedin
The text was updated successfully, but these errors were encountered: