Capturar IP do cliente

Para sua máquina, o IP real remoto é mesmo o gateway.

É o seguinte. O sistema será utilizado dentro de uma rede. Então se duas maquinas desta rede acessar o meu sistema, automaticamente o sistema reconhecerá as duas com o mesmo endereço.

ExemplO:

Maquina 1

Sufixo DNS específico de conexão . :
Endereço IP . . . . . . . . . . . . : 172.25.1.138
Máscara de sub-rede . . . . . . . . : 255.255.254.0
Gateway padrão. . . . . . . . . . . : 10.10.1.1

Maquina 2

Sufixo DNS específico de conexão . :
Endereço IP . . . . . . . . . . . . : 172.25.1.137
Máscara de sub-rede . . . . . . . . : 255.255.254.0
Gateway padrão. . . . . . . . . . . : 10.10.1.1

Ou seja, o log do meu sistema gravará para as duas maquinas o ip: 10.10.1.1 e não o ip real daquela maquina na rede.

Você pode tentar o header X-Forwarded-For, mas você vai ter de tomar o seguinte cuidado: suponha que seu cliente também esteja atrás de um proxy ou um roteador.

Em casa, por exemplo, o endereço IP da minha máquina é algo parecido com 192.168.1.___ e o endereço do roteador é o que o provedor de Internet me fornece quando me conecto a ele (algo como 182.186.___.___ ou coisa parecida).

Se você usar X-Forwarded-For (que normalmente é um header acrescentado por proxy servers, mas não por roteadores), não sei se ele vai apontar o endereço 192.168.1.___ (que acho que é inútil para você - já que várias casas têm esse endereço IP “local” que não serve para absolutamente nada), 182.186.___.___ (que é um pouco mais útil) ou simplesmente não vai aparecer para você.

Ainda assim, esse header não é obrigatoriamente anexado a mensagem. Por isso o thingol falou em tentativa.

Mas se o sistema é interno como eu faria para identificar qual maquina da minha rede está acessando aplicação sendo todas configuradas com o mesmo gateway? Perdoa-me se a minha pergunta foi redundante mas estou tentando dificuldade de compreender essa situação.

Mas seguindo a orientação obtive um “null”

protected void setGrava(Auditavel auditavel)
   {
      auditavel.setIpRemoto(getRemoteAddr());
      auditavel.setOperador(getUserPrincipal().getName());
   }

   private String getRemoteAddr()
   {
      return ((HttpServletRequest) getExternalContext().getRequest()).getHeader("x-forwarded-for");
   }

É assim: você pode tentar escrever uma página bem boba que mostre TODOS os headers HTTP que estão vindo do request do browser do usuário. (Algo como o que está mostrado nesta página aqui:

http://www.cafesoft.com/products/cams/docs/program/WebappProgramming.html

Aí você pode ir até o browser de cada máquina da sua rede que você está tendo problemas, e veja se existe algum header que está imprimindo resultados diferentes para cada cliente. Pode ser, por exemplo, X-Forwarded-For ou outro. É questão de listar os headers e ver se há algum que presta.

teste :shock:

thingol:

É assim: você pode tentar escrever uma página bem boba que mostre TODOS os headers HTTP que estão vindo do request do browser do usuário. (Algo como o que está mostrado nesta página aqui:

http://www.cafesoft.com/products/cams/docs/program/WebappProgramming.html

Aí você pode ir até o browser de cada máquina da sua rede que você está tendo problemas, e veja se existe algum header que está imprimindo resultados diferentes para cada cliente. Pode ser, por exemplo, X-Forwarded-For ou outro. É questão de listar os headers e ver se há algum que presta.

Cara…

Como eu faria para testar esses exmplos deste site. Eu criei um novo projeto no eclipse e em seguida criei uma pagina jsp e coloquei o primeiro exemplo. Rodei o servidor, chamei a pagina mas ficou em branco.

Me dê algumas dicas por gentileza.

Aí é com você. Pegue seu site mesmo que está funcionando, e crie uma página a mais com o código que você pode pegar do tal exemplo (você entendeu o exemplo, para começar?) Não precisa fazer um site “vazio”.

Depois você apaga a página, que é só para testes. É até melhor você fazer na sua própria aplicação mesmo, em vez de criar uma aplicação vazia, que vai dar um trabalhão daqueles para acabar funcionando.

Tem certeza que request.getHeader(“x-forwarded-for”) não funciona pra ti?
Ele não pega o valor do IP interno. Nunca pegou comigo. Sempre é o IP externo, aquele que serve pra nós.

Bom dia Galera,

Tenho um comando que pega o Ip da máquina cliente, porém tem algumas máquinas que ele não está pegando e na minha máquina localhost também não pega, alguém pode me dar uma mão?

HttpServletRequest request = (HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest();

System.out.println(request.getHeader("X-Forwarded-For"));

Uso o tomcat 7

diogo soares:

Bom dia Galera,

Tenho um comando que pega o Ip da máquina cliente, porém tem algumas máquinas que ele não está pegando e na minha máquina localhost também não pega, alguém pode me dar uma mão?

HttpServletRequest request = (HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest();

System.out.println(request.getHeader("X-Forwarded-For"));

Uso o tomcat 7

Você chegou a ler o tópico? Como já explicado, esse campo é opcional na mensagem IP. Se algumas máquinas não enviam, não há nada que você possa fazer.
É errado depender dele.

Alguém achou alguma alternativa?
Estou precisando dessa funcionalidade!

LaercioPontin:

Alguém achou alguma alternativa?
Estou precisando dessa funcionalidade!

Já tentou as alternativas do próprio tópico?

Preciso de garantia de retorno de ip, e pelo que vi nos exemplos anteriores, não são todas as vezes que ele retorna o ip, e por minha aplicação ser para usuário externo, não tem como eu obriga-lo a fazer nada para que eu pegue essa informação dele (app).

Isso se parece com aquela coisa que me pediam sempre, e sempre tive de dizer que nunca dá para fazer com 100% de segurança.

A história é a seguinte: no tempo em que o pessoal confiava muito em emails para mandar informações quaisquer, o cliente queria porque queria ter um recibo ou confirmação de que o cliente realmente tinha lido o tal email, sei lá por quê.

Eu sei que a única forma confiável é quem recebeu o email telefonar de volta para você (ha ha ha), mas excluindo essa alternativa, há várias outras que não funcionam 100%, como:

a) Solicitar no header do email que seja retornado um recibo - obviamente, se você mandar um email desses para um web mail, como o GMail ou o Yahoo Mail, esse header será categoricamente ignorado. No caso do Outlook, pode ser que o usuário opte por não mandar o recibo de volta.
b) Colocar um “bug” - uma figura com zero pixels no corpo de uma mensagem HTML, que indique que a mensagem foi realmente lida (Hoje em dia o tal do “bug” passou a ser uma figura grande, como o logotipo da loja que mandou o email, porque aí força o usuário a visualizar a figura para poder entender o email). É óbvio que isso também não funciona com web mails e mesmo com o Outlook isso passou a não funcionar mais.
c) Fazer o cliente clicar em um link - é obviamente a solução mais trabalhosa para o cliente e isso só funciona quando você quer que ele faça a confirmação de um cadastro, ou outra coisa que é importante para ele.

Pois bem, o pessoal sempre me pedia algo que funcionasse 100% (e obviamente não há nada que funcione 100%), e eu tinha até um relatório pronto com essa análise e o pessoal sempre pensava “mas não há outra alternativa”? No fim das contas, sempre tinha um maluco que dizia que dava para resolver de outro jeito, esse tal jeito era implementado, mas não funcionava (funcionava pior que as alternativas que eu tinha elencado), e eu infelizmente tinha de dizer “eu te disse?”.

E sempre dá para enganar com essa história do IP - por exemplo, como é que você faz para alugar filmes, comprar músicas ou outras coisas em vários sites dos Estados Unidos que checam se seu IP é americano? Você simplesmente paga um “proxy” ou “VPN” e pronto, você pode pegar seu vídeo gratuito se você for um cliente Amazon Prime sem pagar um centavo - exceto a sua mensalidade da VPN.