Search

Marcelo Lecar

@WebMvcTest Spring Tests with CSRF

References:

To test your controllers without disabling CSRF, you can do the following:

1. First import statically the package bellow:

import static org.springframework.security.test.web.servlet.request.SecurityMockMvcRequestPostProcessors.*;

2. Then in your MockMvc request:

with(csrf())

3. And last:

this.mockMvc
            .perform(post("/users").with(csrf())
                    .content(objectMapper.writeValueAsString(createUserDto))
                    .header(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE))
            .andExpect(status().isCreated());

The recomendation from Spring, says the following:

When should you use CSRF protection? Our recommendation is to use CSRF protection for any request that could be processed by a browser by normal users. If you are only creating a service that is used by non-browser clients, you will likely want to disable CSRF protection.

Error: ENOSPC: System limit for number of file watchers reached

For everyone facing an issue like this one, starting a React application:

Error: ENOSPC: System limit for number of file watchers reached, watch

At first I wanted to disable this file watching, but I realized it was not an easy thing to do, so I followed this approach on https://confluence.jetbrains.com/display/IDEADEV/Inotify+Watches+Limit

More details can be found at https://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limit-reached

As I am using linux, I did was the following:

  1. Add a new .conf file under /etc/sysctl.d and add the following line
fs.inotify.max_user_watches = 524288

2. Then you just need to execute the following command line:

sudo sysctl -p --system

ArrayList vs LinkedList vs Vector

Sometimes people ask me the difference between java.util.ArrayList, java.util.LinkedList and java.util.Vector.

Well, if it is important to you I will tell you the basic stuff about them:

ArrayList: It is an implementation of an array, simple as that.

LinkedList: It is an implementation of an doubly-linked list, attention, doubly-linked list, so each node is linked to the next node and linked to the previous node at the same time.

Vector: It is like an ArrayList, but it is synchronized.

So, add and remove are slower in ArrayList because it generates another array and copy values to it.

But LinkedList is slower in get and set methods, because you have to pass through the list to find the element.

 

But you can check more information about them at:

https://docs.oracle.com/javase/8/docs/api/java/util/ArrayList.html

https://docs.oracle.com/javase/8/docs/api/java/util/LinkedList.html

https://docs.oracle.com/javase/8/docs/api/java/util/Vector.html

And DZone written a post about it in https://dzone.com/articles/arraylist-vs-linkedlist-vs.

 

maven-shade-plugin e maven-jarsigner-plugin juntos

Trabalhando com os plugins:

maven-shade-plugin e maven-jarsigner-plugin

eu estava recebendo o seguinte erro ao executar o jar gerado com “maven clean install”:

java.lang.SecurityException: Invalid signature file digest for Manifest main attributes

Fiz a verificação da assinatura do jar com o seguinte comando “jarsigner -verify ” e obtive:

jar-not-signed

O motivo desse erro para mim era porque, como o maven trabalha baseado em FIFO e na configuração do meu pom, eu estava colocando o plugin do jarsigner antes do shade.

Após trocar a ordem dos plugins e executar o comando de verificação novamente eu obtive:

jar signed

voilà!

Jar assinado e agora eu agora consigo executá-lo.

java.lang.ClassNotFoundException: org.jboss.ws.core.soap.SAAJMetaFactoryImpl

Recentemente me deparei com a seguinte situação no jboss 4.2.3:

java.lang.ClassNotFoundException: org.jboss.ws.core.soap.SAAJMetaFactoryImpl

O artefato que possui a classe solicitada acima é o jbossws.sar que fica dentro da pasta deploy do jboss que havia sido removido porque a minha aplicação não dependia do jax-ws antes.

Porém não tenho interesse em restaurar esse artefato porque não pretendo mais depender das classes jax-ws do JBoss. Dependerei das classes do Spring Web Services que já possui uma implementação do javax.xml.soap.SAAJMetaFactory.

A primeira pergunta é: Quem está solicitando ao JBoss a instanciação da classe org.jboss.ws.core.soap.SAAJMetaFactoryImpl?

Dentro do artefato jboss-saaj.jar que está presente na pasta lib e lib/endorsed do JBoss existe um apontamento para essa classe no arquivo META-INF/services/javax.xml.soap.MetaFactory.

E a segunda pergunta é: Como fazer para que o JBoss deixe de procurar essa classe?

Basta remover o arquivo jboss-saaj.jar tanto da pasta lib quanto da lib/endorsed e dessa forma, no meu caso, o Spring Web Services será utilizado para carregar o meu artefato.

Maven Release: branch + Git

Há pouco tempo me deparei com uma certa dificuldade em gerar a release de um branch que eu havia criado. Isso se deve ao fato de termos mudado de SVN para Git recentemente.

A nossa linha de desenvolvimento é no trunk, reservamos as branches somente para corrigirmos bugs que aparecem em produção em versões fechadas e que não tenhamos capotado a versão seguinte ou que já tenhamos adicionado novas features que ainda não estão maduras ou testadas o suficiente de forma a garantirmos a qualidade do software.

Então, para a versão fechada, digamos 1.15, criaremos a versão de branch 1.15.0.1.1. (Descreverei em outro post esse versionamento)

Lembrando que utilizamos o Git e que sendo assim, criamos o branch a partir da tag 1.15 com o comando abaixo:

git checkout -b projeto-1.15 projeto-1.15

Está correto mesmo, criaremos o branch 1.15 para que consigamos fazer com que o maven crie uma nova branch de desenvolvimento que se chamará projeto-1.15.0.1.1 e em seus poms teremos a tag version como projeto-1.15.0.1.1-SNAPSHOT. Caso contrário vc terá de alterar todos os poms manualmente para esta versão, o que não se justifica.

Feito o checkout da versão projeto-1.15 agora é só executar o seguinte comando:

mvn release:branch -DautoVersionSubmodules=true -DbranchName=projeto-1.15.0.1.1 -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false

Feito isso, a branch projeto-1.15.0.1.1 será criada e os poms estarão com a tag version projeto-1.15.0.1.1-SNAPSHOT.

Agora é só fazer as devidas correções do bug, adicionar ao index do git, commitar no repositório e executar o comando:

mvn release:prepare

E se tudo der certo:

mvn release:perform

Caso alguma coisa dê errado, verifique o erro informado e se for necessário vc poderá executar o comando (mas lembre-se de NÃO deletar os arquivos de rollback gerados pelo mvn release:prepare, senão o passo seguinte não funcionará):

mvn release:rollback

Olá Mundo!

Olá! Seja bem vindo!
A idéia da criação de um blog surgiu da minha necessidade e satisfação em compartilhar a minha experiência ao longo dos anos desenvolvendo software.

Website Powered by WordPress.com.

Up ↑