produtos.json. O mesmo vale para HTMLe outros formatos que você queira suportar.
10.3
Curiosidade sobre o objeto a ser seriali-
zado
O nosso método de listagem retorna um objeto do tipo ModelAndView, dentro do qual podemos adicionar quantos objetos quisermos para que sejam usados na view. Como que o serializador de JSONsabe qual destes objetos escolher?
A maneira padrão é iterar por todas as chaves do ModelAndViewe gerar o JSONpara cada um dos objetos encontrados. Caso você queira mudar isso, especificando uma determinada chave, é possível invocar um método de configuração.
@Override
public View resolveViewName(String viewName, Locale locale) throws Exception {
MappingJackson2JsonView view = new MappingJackson2JsonView(); view.setPrettyPrint(true);
//define a chave
view.setModelKey("products"); return view;
}
Dessa forma, estamos forçando o MappingJackson2JsonViewa igno- rar as outras chaves. É importante notar que esse comportamento de analisar todos os objetos do ModelAndViewnão é o padrão. O serializador de XML, baseado na especificação do JAX-B, busca pelo primeiro objeto compatível!
10.4
Conclusão
Neste capítulo, foi abordado um tema que está em evidência: integração de sistemas via REST. Suportar o Content Negotiation é fundamental para você dar flexibilidade às aplicações clientes sobre qual formato elas preferem. Um 148
Casa do Código Capítulo 10. Respondendo mais de um formato outro ponto importante foi o uso da annotation @ResponseBody, ela é muito útil quando você quiser que o retorno do método já seja o corpo da resposta. Só não ficamos com ela porque queríamos suportar o retorno em HTMLe, para isso, tivemos que user o ModelAndViewpara indicar a página que deveria ser usada.
Uma annotation que não abordamos, mas que também pode ser útil, é @RestController. Basta você colocar em cima do seu controller sempre que tiver uma classe onde todos os métodos devem usar o retorno direta- mente como corpo da resposta. Caso o nosso controller só retornasse JSON ou XML, podíamos ter feito isso e nos poupado de escrever @ResponseBody em todos métodos.
Capítulo 11
Protegendo a aplicação
Até agora, todas as URLs do nosso sistema estão acessíveis por todos os usuá- rios. Algumas até são liberadas, como a que leva para página inicial, que deve exibir todos os livros. Só que temos algumas URLs que necessitam de um usuário logado, como a que cadastra os novos livros e a de checkout.
Podemos até implementar toda essa parte de segurança na mão, mas como já vem sendo feito no decorrer do livro, vamos usar um módulo do Spring que implementa boa parte do que a gente precisa. É bom sempre lem- brar que implementar uma estratégia de segurança não é trivial. Além de for- çar o login para algumas URLs, é necessário ter preocupação com pelo menos mais alguns itens.
• Quais perfis podem acessar as URLs, também conhecido como autori- zação;
11.1. Configurando o Spring Security Casa do Código • Fontes de dados diferentes para realização de login.
11.1
Configurando o Spring Security
Para conseguirmos usar as classes do Spring Security, precisamos adicionar mais algumas dependências ao nosso projeto. Por isso, vamos alterar o ar- quivo pom.xmlde novo.
... <dependencies> <!-- Spring security --> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-config</artifactId> <version>4.0.0.M2</version> </dependency> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-taglibs</artifactId> <version>4.0.0.M2</version> </dependency> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-web</artifactId> <version>4.0.0.M2</version> </dependency> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-core</artifactId> <version>4.0.0.M2</version> </dependency> </dependencies> <repositories> <repository> <id>spring-milestones</id> <name>Spring Milestones</name> <url>http://repo.spring.io/milestone</url> 152
Casa do Código Capítulo 11. Protegendo a aplicação <snapshots> <enabled>false</enabled> </snapshots> </repository> </repositories>
A versão estável do Spring Security ainda é a 3, mas já vamos usar a 4 para garantir compatibilidade com os outros módulos que já estamos uti- lizando. Como a versão 4 ainda está em fase de construção, temos apenas acesso aos milestones. Por conta disso, fomos obrigados a adicionar mais um repositório, para que o Maven consiga buscar todos os jarsnecessários. Como o nosso projeto foi importado como Maven project, o classpath já é atualizado em função de cada alteração que fazemos no arquivo. Caso você tenha importado como projeto normal, lembre-se sempre de fazer um mvn eclipse:eclipse.
Configuração do filtro
Toda lógica de segurança do Spring Security é iniciada na classe FilterSecurityInterceptor, que é um filtro da especificação de Ser- vlets. Precisamos apenas configurar para que este filtro seja carregado. package br.com.casadocodigo.loja.conf;
//imports
public class SpringSecurityFilterConfiguration
extends AbstractSecurityWebApplicationInitializer{ }
Aqui usamos a mesma estratégia da classe ServletSpringMVC. As duas, no fim, implementam a interface WebApplicationInitializer, que é carregada pelo Spring para fazer o registro dos Servlets, filtros e tudo relativo à especificação de Servlets. Caso não se lembre, já comentamos sobre ela no segundo capítulo do livro.
Só que, em vez de implementar diretamente a interface, herdamos da classe AbstractSecurityWebApplicationInitializer, que já vem 153
11.2. Garantindo a autenticação Casa do Código