Filter vRaptor 2

Assuntos Gerais
#1

Olá,

Estou tentando utilizar um filter para interceptar as requisições e alterar o response em determinadas situações.

O problema é que devido ao uso de .jsp não consigo fazer um Filter, pois ocorrerá de chamar o getWriter() duas vezes, o que causa erro.
Também tenho casos onde não utilizo .jsp e chamo o write manualmente…

Desde já aviso que não há chance de migrar p/ vRaptor 3 =)

Help!

#2

isso não tem a ver com o VRaptor 2… tem a ver só com a api de filtros…

o que vc tá tentando fazer? vc quer escrever algo a mais no response?

#3

Eu coloquei vRaptor 2 para que se existir algum recurso nele que atenda isso, já possa ser discutido…

O que eu preciso é validar o que está indo na resposta… e, se for o caso, trocar a resposta.

#4

como assim validar, vc vai pegar o que foi escrito na resposta e então inspecionar o que está lá dentro?

se sim, vc vai precisar de um filtro mesmo e fazer o seguinte:

passe para o doFilter uma implementação do response que sobrescreve o método getWriter() (estenda o HttpServletResponseWrapper), e retorne um StringWriter que vc vai guardar em um atributo dessa classe.

após o doFilter, pegue esse atributo, use o writer.toString() pra pegar o conteúdo (se eu não me engano) inspecione o que vc quiser inspecionar, e escreva esse conteúdo no response original.

#5

Exatamente isso que preciso.

Acho que entendi…

Isso tudo seria para evitar XSS… Você tem alguma outra ideia para evitar isso?

#6

jeito fácil: escapando o html das entradas do usuário.

tem um projeto que faz isso pra vc: https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

#7

Mas eu tenho a entrada do usuário de diversos ambientes, não só web…
Esse projeto atende isso?

#8

sim… num projeto que eu fiz eu criei um objetinho pra isso, uma classe Text que guarda um atributo com o texto do jeito que o cara digitou e o toString sempre retorna o texto tratado com o antisamy

daí é só usar essa classe em todas as suas entidades em que as entradas vem do usuário.

#9

Mas tenho entradas no sistema de lugares onde não tenho “alcance”… Ou seja, não posso alterar lá o que vai vir do usuário.
Por isso a ideia de sempre interceptar o out…

#10

por isso que eu falei de limpar os dados no toString da classe Text, ou seja, na saída. Mais fácil do que parsear html e limpar algo no meio.

#11

Não sei se você entendeu o que eu estou querendo dizer, por quer não entendi a tua ideia.

O meu problema é que algumas informações simplesmente vão entrar no meu banco de dados, e eu não tenho conhecimento da origem delas… Ou seja, não tenho como limpar a entrada de dados na outra ponta.

#12

vamos supor que vc está usando JPA/hibernate:

@Entity
public class EntidadeQualquerDoSistema {
   // atributos
   @AttributeOverride(name="text", column = @Column(name="nomeQueVaiProBanco"))
   private Text textoQueVaiSerLimpo;
}

@Embeddable
public class Text {
   private String text;
   
   //toString limpando esse texto
}

assim o hibernate vai pegar o texto que tá no banco e criar um objeto do tipo Text,
ou seja não importa como está no banco, o toString dessa classe vai sempre retornar o texto limpo.

daí qdo vc for imprimir na sua jsp, vc pode fazer ${entidadeQualquer.textoQueVaiSerLimpo}, que o jsp vai usar o toString.

entendeu mais ou menos como é?

#13

Entendi…
Uma alteração nesse sentido não sei se é viável hoje, vou dar mais uma pesquisada… mas muito obrigado pela sua ajuda Lucas. Vlw!

#14