Este projeto fornece suporte para usar o Spring Security com OAuth (1a) e OAuth2. Ele fornece recursos para implementar tanto consumidores quanto provedores desses protocolos usando modelos de programação e expressões de configuração padrão do Spring e Spring Security.

Código de Conduta

Este projeto adere ao código de conduta do Contributor Covenant. Ao participar, espera-se que você mantenha este código. Por favor, reporte comportamentos inaceitáveis para [email protected].

Primeiros Passos

Baixe ou clone do GIT e então use Maven (3.0.*) e Java (1.6 ou superior):

$ git clone ...
$ mvn install -P bootstrap

Use o perfil bootstrap apenas na primeira vez - ele habilita alguns repositórios que não podem ser expostos nos poms por padrão. Você pode achar útil adicionar este perfil ao seu settings.xml local.

Você precisa executar o Redis para que a compilação funcione. Você pode instalá-lo usando o homebrew. Sem o Redis em execução, a compilação terá muitas exceções de conexão Jedis.

Usuários do SpringSource ToolSuite (ou usuários do Eclipse com o plugin m2eclipse mais recente) podem importar os projetos como projetos Maven existentes.

O Spring Security OAuth é distribuído sob os termos da Licença Apache Versão 2.0 (veja license.txt).

Exemplos

Os exemplos e testes de integração estão em um subdiretório. Há um README separado lá para orientação e informação. Depois de instalar os artefatos localmente (conforme as instruções de início acima), você deve ser capaz de

$ cd samples/oauth2/tonr
$ mvn tomcat7:run

e visite o aplicativo em seu navegador em http://localhost:8080/tonr2/ para verificar se funciona. (Isso é para o exemplo OAuth 2.0, para o exemplo OAuth 1.0a basta remover o "2" do caminho do diretório.) Os testes de integração exigem configurações ligeiramente diferentes para o Tomcat, então você precisa adicionar um perfil:

$ cd samples/oauth2/tonr
$ mvn integration-test -P integration

Changelog

Listas de problemas abordados por versão podem ser encontradas no github (versões mais antigas estão no JIRA).

Recursos Adicionais

• Guia do Usuário do Spring Security OAuth
• Código Fonte do Spring Security OAuth
• Stackoverflow

Contribuindo para o Spring Security OAuth

Aqui estão algumas maneiras de você se envolver na comunidade:

• Envolva-se com a comunidade Spring nos Fóruns da Comunidade Spring. Por favor, ajude no fórum respondendo a perguntas e participando do debate.
• Crie issues no github para bugs e novos recursos e comente e vote naqueles que lhe interessam.
• Github é para codificação social: se você quiser escrever código, incentivamos contribuições através de pull requests de forks deste repositório. Se você quiser contribuir com código dessa forma, por favor, referencie também uma issue do github cobrindo o problema específico que você está abordando.
• Fique atento a artigos futuros sobre o Spring assinando o springframework.org

Antes de aceitarmos um patch ou pull request não trivial, precisaremos que você assine o acordo do contribuidor. Assinar o acordo do contribuidor não concede a ninguém direitos de commit no repositório principal, mas significa que podemos aceitar suas contribuições, e você receberá crédito de autor se o fizermos. Contribuidores ativos podem ser convidados a se juntar à equipe principal e receber a capacidade de mesclar pull requests.

Convenções de Código e Organização

Nenhum destes é essencial para um pull request, mas todos ajudam. Eles também podem ser adicionados após o pull request original, mas antes de uma mesclagem.

• Use as convenções de formatação de código do Spring Framework. Importe o eclipse-code-formatter.xml da raiz do projeto se estiver usando Eclipse. Se estiver usando IntelliJ, copie o spring-intellij-code-style.xml para ~/.IntelliJIdea*/config/codestyles e selecione spring-intellij-code-style em Configurações -> Estilos de Código.
• Certifique-se de que todos os novos arquivos .java tenham um comentário de classe Javadoc simples com pelo menos uma tag @author identificando você, e de preferência pelo menos um parágrafo sobre para que serve a classe.
• Adicione o comentário de cabeçalho de licença ASF a todos os novos arquivos .java (copie de arquivos existentes no projeto)
• Adicione-se como @author nos arquivos .java que você modificar substancialmente (mais que mudanças cosméticas).
• Adicione alguns Javadocs e, se você mudar o namespace, alguns elementos de documentação XSD.
• Alguns testes unitários também ajudariam muito - alguém tem que fazê-lo.
• Se mais ninguém estiver usando seu branch, por favor, faça rebase dele contra o master atual (ou outro branch alvo no projeto principal).