AND don't forget about X-FORWARDED-FOR. (ie load balanced cache servers) X-FORWARDED-FOR can be faked.
-- Yasuo Ohgaki Compman86 wrote: > If there are two people behind a NAT, then the site would check for a > session ID and the IP. If a session ID is introduced AND their IP > matches the session, they are allowed to proceed. This would prevent > people from moving a session ID to another machine. If two people are > behind a NAT and share a session ID, I don't think there is a way of > preventing them to be assumed as the same person. So basically, it will > try to use cookies alongside a matching IP, and if cookies are disabled, > it will use the GET method alongside a matching IP. It just makes a > double check of the user...half the risk of transferring session ID's > among people...but still not fullproof...but I don't think there is a > fullproof way. > > "Dl Neil" <[EMAIL PROTECTED]> wrote in message > news:<0ad801c1a4ba$3d49bec0$7215100a@jrbrown>... > >>Entering the conversation late... >> >>1 IP addresses >>Remember these are not necessarily 'unique'. If two of us here log in, >> > >>won't we appear (to you) have the same IP address if we're 'hiding' >>behind a NAT (Network Address Translation) box? Also dial-up users >>share a pool of IP addresses which are reallocated between customers >>as they disconnect/reconnect. >> >>2 Cookies >>I think someone has already made points against their use. Many >>corporates set up/require that browsers are configured to reject all >>cookies (plays havoc with many shopping and banking sites). Obviously >>there is popular advice that cookies are 'not good', because I've had >>a number of friends and clients tell me that they regularly clear out >>their 'cookie jar' - and need help when they get over enthusiastic and >> > >>clear more than they should... >> >>There's a balance between easing life for those who are 'in', and >>turning off those trying to arrive. The trick is finding it! =dn >> >> >>----- Original Message ----- >>From: "SpamSucks86" <[EMAIL PROTECTED]> >>To: "'PHP-General'" <[EMAIL PROTECTED]> >>Sent: 23 January 2002 23:46 >>Subject: RE: [PHP] Need opinion On sessions - Cookies mandatory? >> >> >> >>>The idea of building a website is largely to accommodate as large a >>>portion of your visitors as possible. I'm not worried about people >>>bookmarking sessionID's, but what if someone copy/pastes the URL to >>>a friend and they use the section. My friend gave me an excellent >>>idea, and that is to check their IP and store the IP in the session. >>> > >>>If the IP doesn't match, then start a new session. This would be >>>perfect, because there's a double check. If someone disconnects to >>>the internet but never closes their browser, I don't think they >>>should be allowed to continue their session anyway, they should be >>>required to login again. >>> >>>-----Original Message----- >>>From: Nick Wilson [mailto:[EMAIL PROTECTED]] >>>Sent: Wednesday, January 23, 2002 3:35 AM >>>To: [EMAIL PROTECTED] >>>Subject: Re: [PHP] Need opinion On sessions - Cookies mandatory? >>> >>>-----BEGIN PGP SIGNED MESSAGE----- >>>Hash: SHA1 >>> >>> >>>* and then Jason G. blurted.... >>> >>>>If cookies do not work, then you must have a session_id appended >>>>to >>>> >>>the >>> >>>>URL. HTTP is a "stateless" protocol. So every time you make a >>>> >>>request via >>> >>>>HTTP, you must let PHP know what the session_id is either through >>>> >>>cookies, >>> >>>>or url query strings (or possibly posted with a form). >>>> >>>Yep, now I'm with you. The amount of times you'd see that kind of >>>ugly URL would be fairly minimal in most situations as most users >>>these days aren't even aware they *can* disable cookies. >>> >>> >>> >>>>>>disable cookies, but appending the session ID could be a >>>>>>security >>>>>> >>>risk. >>> >>>>>>Consider this: Someone is viewing a page and says "oh cool, I >>>>>>want >>>>>> >>>Joe >>> >>>>>>to see this". He then copy/pastes the URL, sessionID and all, >>>>>>to >>>>>> >>>Joe, >>> >>>>>>who then loads up the page using his friend's SessionID. With >>>>>> >>>cookies, >>> >>>>>>this would not happen. >>>>>> >>>>>Not a problem. The session is *destroyed* as soon as a user >>>>>closes >>>>> >>>the >>> >>>>>browser. >>>>> >>>>A session will only be *destroyed* if it uses a cookie. PHP never >>>> >>>knows >>> >>>>when you close the browser, but the browser will remove the >>>>cookie. >>>> >>>Next >>> >>>>time you fire up the browser, it will not send the cookie, and a >>>> >>>different >>> >>>>session will be started. >>>> >>>Sure. But there is some kind of clean on the host machine right? You >>> > >>>couldn't expect to continue a session a week later because you've >>>bookmarked a URL containind a SID. I think this is controlled by >>>something like a timeout var in the php.ini. >>> >>> >>>>In my personal experience, using cookies only has not proven to be >>>> > >>>>a problem. Your call. >>>> >>>When you say using cookies only do you mean 'requiring' the user to >>>have cookies enabled? >>> >>>- -- >>> >>>Nick Wilson >>> >>>Tel: +45 3325 0688 >>>Fax: +45 3325 0677 >>>Web: www.explodingnet.com >>> >>> >>> >>>-----BEGIN PGP SIGNATURE----- >>>Version: GnuPG v1.0.6 (GNU/Linux) >>> >>>iD8DBQE8TnW3HpvrrTa6L5oRAthOAJ0WOpUWC5fFMokhYF2QsaQaQolp+wCfQWHL >>>03BrqRN2kLf+VWC/tzDSHho= >>>=Gek0 >>>-----END PGP SIGNATURE----- >>> -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
