• Post Reply Bookmark Topic Watch Topic
  • New Topic

Intercepting HTTP requests using JSF  RSS feed

 
ian mcdavid
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think this belongs on the JSP forum, but i am working with JSF and need to know if that changes any details of the process i am inquiring about.

I am trying to get a client's internet protocol address by calling the .getAddr() function of an HTTP request. I have tried calling a function on the <h:form submit="function name"> control, but this doesn't work. If anyone could provide any suggestions as to how to go about this properly then i would appreciate it.
 
ian mcdavid
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have resolved this problem. This is the code i used:



Hope this helps some one out.
 
Tim Holloway
Bartender
Posts: 18715
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just as long as you remember that the client's IP address isn't authoritative! I'm behind a NAT filter myself, and every user on the backend network is going to appear as having the same IP address.

IP addresses are good for traffic tracking purposes but pretty useless for identification.
 
ian mcdavid
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What should i use for identification if i want to connect to a client's computer via RTP? Why are IP addresses so useless? I have tried to read about network address translators but it doesn't seem to help at all. The fact that there is no generalized class which establishes connections to the client at a high level is disappointing at best and a clear indicator of "expert oriented programming" at worst.
 
Tim Holloway
Bartender
Posts: 18715
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HTTP doesn't "establish a connection" in the sense that client/server apps do. The HTTP connections exist only for the length of time it takes to send down a request and receive a response. A whole new pair of connections is created and destroyed for each request/response cycle. There's no continuous connection.

Web servers gain the illusion of a continuous conversation by linking these one-shot requests to a state-saving object. In the case of J2EE, it's the HTTPSession object. The server creates it and assigns a key to it. That key is then transferred to and from the client so that the same session will be referenced on subsequent requests.

The application is responsible for establishing an identity, and that's normally done by logging into the application. The login process captures the user's ID and security credentials and an identity object is them bound to the session context. If you use the J2EE standard security system, that's the UserPrincipal object attached to your request.

The upshot is that web apps are generally less interested in where you are as far as your network address goes than WHO you are. Aside from being a more reliable means of identification, and discounting NAT, the IP address for a lot of users isn't constant. Instead it's assigned from a pool using the Dynamic Host Protocol Service (DHCP). The address is only leased, not owned, and can change if you power down and back up again or otherwise disconnect from the network.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!