Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #17480
| From | "R.Wieser" <address@not.available> |
|---|---|
| Newsgroups | comp.lang.php |
| Subject | Re: Ecommerce site - how? |
| Date | 2017-06-26 17:12 +0200 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <oir89b$187l$1@gioia.aioe.org> (permalink) |
| References | <d2223e3b-f44c-4ef7-b55a-94e012d85a95@googlegroups.com> <oiodsn$pud$1@gioia.aioe.org> <PcqdnRTWK6vXeM3EnZ2dnUU7-X3NnZ2d@posted.internetamerica> |
Gordon, > Some shoppers are behind a proxy which may change the > outside IP address for every HTTP transaction. Thus: 1 main > page + 100 images = 101 differrent IP addresses. Thats no problem at all, as long as the IP from which the webpages are requested does not change. Provided that the e-commerce website does not have some kind of anti-leeching active ofcourse (disallowing requests for additional content (like product images) not present on the webpage thats currently viewed). > Using an IP plus the session cookie locks out a small part of > the user base (those behind proxies that use a changing outside > IP address) I think you misunderstood when those IPs do actually change ... > Some shopping carts last a lot longer than one session. Usually > this requires logging in With your described multiple different IPs within (something which the user percieves as) a single session that won't work either. TL;DR: You have brought up a problem (which I think does not exist, because you most likely misunderstood what happens), but have not spend a single letter at trying to decribe a known or possible solution for it. :-( Regards, Rudy Wieser P.s. I'm not the OP :-) -- Origional message: Gordon Burditt <gordonb.y152t@burditt.org> schreef in berichtnieuws PcqdnRTWK6vXeM3EnZ2dnUU7-X3NnZ2d@posted.internetamerica... > > Its only when you want to the goods to be send to you you will need to > > provide them *some* kind of identifying data -- otherwise they will have no > > clue where to send it to :-) . Even the payment methoud could be anonymous > > (think gift cards). > > > >> If it's id'ing you by IP address - what happens if you log off your > >> internet connection, and somebody else logs on, and gets your IP? > > > > Nothing. > > > > The IP *PLUS* the unique value identify the shopper -- and that unique value > > gets discarded as soon as you drop the connection (and the PHP session is > > terminated). > > Some shoppers are behind a proxy which may change the outside IP > address for every HTTP transaction. Thus: 1 main page + 100 images > = 101 differrent IP addresses. Navigate somewhere and they get a > few more dozen IP addresses. Anything trying to use the IP address > as part of the identifier won't work (you probably get an empty > cart just after putting something in it, every darn time). I believe > AOL is one ISP that did this. Few web sites want to lock out a lot > of customers from buying stuff from their site. > > Using the IP only is idiotic. Using an IP plus the session cookie > locks out a small part of the user base (those behind proxies that > use a changing outside IP address). Using a session cookie without > the IP works, if nobody can listen in on the conversation (but > that's what https: is for, isn't it?) Logging the IP (along with > the date, time, and TIME ZONE) for security reasons is often good > for criminal investigations after fraud is discovered. So is keeping > track of the address where you shipped it and the method of payment. > > Some shopping carts last a lot longer than one session. Usually > this requires logging in. The store gets to track you but they try > to also make the user experience worth more than the tracking is > scary, say by making suggestions in line with your interests. Amazon > might do this by suggesting, if I just ordered a Green Toyota, > suggest that I buy Blue and Yellow Toyotas to go with them. Sometimes > they do hit the mark, with, say, related books or suggesting I buy > batteries or accessories to go with what I just ordered recently. > > Sometimes a site will allow you to save your shopping cart and get > it back later, without requiring a login. This might request the > user's email address and a name provided by the user. It may or > may not check the email address IS an email address. If you use > such a site, make sure that the list name you give it isn't very > guessable. > > On Amazon, for example, I might have something in my shopping cart > for months before accumulating enough items to make it worth an > order. The shopping cart is tied to my account so the same shopping > cart will appear on my computer, my Kindle, and my cell phone, and > changes made in one appear in the others. I don't know whether > there is any intra-account privacy, but I doubt it. Consider a > husband and wife sharing the same account and the same credit card. > Husband might look up (wife's) past orders to get her clothing sizes > for an anniversary present, and just happen to spot her order for > his anniversary present. Meanwhile, she logs in to check on her > order status, thinking it's the latest order and spots his order, > spoiling the surprise. I don't think the site knows whose orders > are whose. > > Some E-commerce sites allow you to order without setting up an > account (although most will encourage you to do so, and if you do > you won't have to keep re-entering shipping addresses and other > info). During the ordering process, the session cookie tracks > what's yours vs. someone else. When you finish ordering, they > encourage you to print the invoice for future reference. That page > usually contains a link, or an invoice number, or something that > you can use to track your order (possibly by calling Customer Service > as well as using the web site) long after you've dropped the session. > They gave you *something* that can be tied to an entry in their > database. Maybe it's an invoice number, maybe it's a temporary > customer number. Whether or not you can you can see someone else's > order by decrementing the invoice number by 1 is a different issue. > If you leave the piece of paper you printed around where your little > brother can find it and type it into a browser, don't expect privacy > from him. > > >> Is there any way to prevent it? (short of forcing the user to sign in??) > > > > I suggest you read up on the above mentioned "PHP session". > > > I'd like to know how an Ecomm site works. Like, how is a shopping cart built > > up? When you "add to cart", it has to lay a cookie on your HD right? > > Whether or not the cookie ever hits your HD is debatable, and depends > on how the site is coded. Cookies may be set to last only for the > session (although those that want to track you will make it last > longer). It may stay in browser memory during the session and go > away when the browser is closed (without ever hitting the hard disk) > if the session isn't closed earlier. So, if you lose electrical > power, you probably lose the shopping cart. > > If you have to log in, the shopping cart can be attached to your > account, not the session. Assuming you can remember your login > information, you can get the cart back. > > > This is > > used to identify you on the server, right? What does this cookie look like? > > There is usually no useful information in a session cookie without > being able to reference the server's database. It's a bunch of > random bits, often encoded as a big number or a bunch of numbers > and letters. You won't find your credit score, weight, medical > history, address, phone number, credit card number, or retinal eye > pattern in there, although the session cookie *might* allow someone > access to your account - and depending on what the account is for > (your medical insurance, perhaps?), some of that info might be in > there. Of particular danger is the guy using the same computer at an > "Internet cafe" after you do, when you forget to close the browser. > > > > eg. what=what inside the cookie file? > > A bunch of random numbers. > > > And then, there'll be a line inside a > > SQL DB or whatever on the server, containing that value (whatever was inside > > the cookie), and containing whatever they're shopping - am I right about all > > this? > > There's a big distinction between what's IN the cookie (even if > encrypted) and what's IN the database on the server. Remember, the > user himself can tamper with cookies. He can't tamper with the > session record pointed at by the session cookie, unless the server > code lets him (e.g. he can add and delete things on the list, but > not change prices, not change other people's lists, and not buy > negative quantities of items). > > On a VERY poorly coded site, the user can set a cookie for > "is_logged_in" to "yes", and this will fool the site into thinking > he logged in. You can't do that with session variables unless you > can get the session cookie of an active session. > > > > Also, how does a site identify you before you sign in? > > Maybe they DON'T. Maybe they don't even try. Some sites don't > even let you sign in if they just contain information to be made > public. But if you complete an order, you will usually need to > fork over (a) a method of payment, and (b) a shipping address. Gift > cards can provide an anonymous method of payment (although maybe > not from your government), and if you download a digital file > (software, music, video, etc. that you are purchasing) instead of > having them ship it on DVD, you don't need to give them a shipping > address. > > How does a (telephone) call center identify you before they ask you > for your account number? (You may not even have one (yet) - maybe > you want to buy something for the first time.) He's the customer > calling in on THIS phone line (e.g. line 27). That's all they need > to talk to the customer. No, they don't need caller ID either - > although sometimes they use it if the call gets dropped when talking > over weak cell phone signals, and sometimes they match it against > their database to bring up the customer's account quicker, but > they're supposed to verify that this guess is correct before giving > out private information or making changes. > > If the telephone call center is giving out information, not taking > orders, they do not necessarily have to get your identification at > all. Consider, for example, the Internal Revenue Service help line > (in the USA). They answer questions about tax laws and how to fill > out forms. They may ask for more detail about your situation > relevant to the tax law and your question. They don't go looking > at past tax returns. They don't ask for your name unless they need > to research something and call you back later. As far as I know, > you can't get yourself audited just by asking stupid questions, but > don't admit crimes anyway. > > > Like, there are > > plenty sites where you can go there, and start adding to cart without > > signing up! (obviously a BIG draw of the site!). If it's id'ing you by IP > > If it's id'ing you by IP alone, it's going to screw up badly, and > some AOL customers can expect to lose the shopping cart about every > time they click on the page. This is where session cookies INSTEAD > OF IP come in. > > It *IS* possible that someone could capture your session cookie and > try to use it. In a family situation, your little brother says > "it's my turn to use the computer" and tries to go back to the site > you were looking at. If you didn't clear the browser cache and > history, he may be able to do that. If he works for your ISP, snooping > is possible. Use https:. > > > > address - what happens if you log off your internet connection, and somebody > > else logs on, and gets your IP? (assuming you're getting your IPs by DHCP). > > UNIX systems can have multiple users at the same time, and that's > a worse situation: several, dozens or hundreds of users with the > same IP *AT THE EXACT SAME TIME*. (TCP connections are uniquely > identified by the 2 endpoint IP addresses and the 2 endpoint part > numbers. In the case being discussed, only the client port number > is different). And maybe most of them browsing the same site. > Networks with browser proxies give you an even worse problem: entire > business offices, or entire universities, or possibly even entire > small countries, using *ONE* or a small number of IPs to the outside > world, with possibly hundreds of sessions to Amazon *simultaneously* > on that one IP. Even a single Windows system can have the same > site open twice on two different tabs. > > > > Will they then get your cart if they go to that site???!! This is NOT very > > impossible - around here, there are only a few major shopping sites which > > Everyone goes to - the scenario above COULD be happening!! Is there any way > > to prevent it? (short of forcing the user to sign in??) > > Let's suppose that the session key is a 64-bit number (and it could > easily be much bigger - the smallest available in PHP seems to be > 128 bits). You have to guess the session key before the user using > it logs out (once the database deletes the record containing the > session key, there's no session info to steal, and the server will > probably ask the user to log in or give them an empty shopping > cart). Suppose you can make one guess every microsecond (given the > speed of the Internet, especially to residential homes, this is way > optimistic. The time required to guess half of the session cookies > will be larger than a quarter of a million years. Are you really > worried about someone finding about about the porn you ordered that > far in the future? If 128 bits are used, that gives plenty of time > for the dinosaurs to re-evolve and die out many times. > > What would be the consequences if someone DID get your cart? It > doesn't have your name on it. They got someone's list and they > don't know whose. And what would they do with that info? It might > be annoying if someone added something to it and you didn't notice, > or ordered and thereby cleared the list. I'd worry a lot more about > them getting my credit card number. > >
Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Ecommerce site - how? bit-naughty@hotmail.com - 2017-06-25 05:42 -0700
Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-25 15:30 +0200
Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-25 16:03 +0200
Re: Ecommerce site - how? gordonb.y152t@burditt.org (Gordon Burditt) - 2017-06-26 05:43 -0500
Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 17:12 +0200
Re: Ecommerce site - how? "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-06-26 17:54 +0200
Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 19:40 +0200
Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-26 21:42 +0200
Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 23:14 +0200
Re: Ecommerce site - how? "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-06-27 00:28 +0200
Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 10:48 +0200
Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-27 07:56 +0200
Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 12:27 +0200
Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-27 19:15 +0200
Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 22:01 +0200
Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-28 07:07 +0200
Re: Ecommerce site - how? Gordon Burditt <gordon@hammy.burditt.org> - 2017-06-30 17:08 -0500
Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-26 18:29 +0200
Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 19:17 +0200
Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-26 13:34 -0400
Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 20:11 +0200
Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-26 21:31 +0200
Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-26 22:29 +0200
Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-27 07:19 +0200
Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 11:24 +0200
Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-27 19:43 +0200
Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 23:09 +0200
Re: Ecommerce site - how? "J.O. Aho" <user@example.net> - 2017-06-28 07:12 +0200
Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-27 21:10 -0400
Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-26 16:32 -0400
Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 10:30 +0200
Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-27 08:38 -0400
Re: Ecommerce site - how? "R.Wieser" <address@not.available> - 2017-06-27 17:47 +0200
Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-27 12:16 -0400
Re: Ecommerce site - how? gordonb.bytf1@burditt.org (Gordon Burditt) - 2017-06-29 18:16 -0500
Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-29 20:41 -0400
Re: Ecommerce site - how? gordonb.99a3p@burditt.org (Gordon Burditt) - 2017-06-29 23:39 -0500
Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-30 07:28 -0400
Re: Ecommerce site - how? Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2017-06-30 13:48 +0000
Re: Ecommerce site - how? gordonb.gcghn@burditt.org (Gordon Burditt) - 2017-06-30 16:15 -0500
Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-30 22:35 -0400
Re: Ecommerce site - how? Richard Damon <Richard@Damon-Family.org> - 2017-06-29 23:46 -0400
Re: Ecommerce site - how? gordonb.d2wed@burditt.org (Gordon Burditt) - 2017-06-29 17:32 -0500
Re: Ecommerce site - how? bit-naughty@hotmail.com - 2017-06-27 10:58 -0700
Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-06-27 15:34 -0400
Re: Ecommerce site - how? gordonb.4psc7@burditt.org (Gordon Burditt) - 2017-06-30 16:55 -0500
Re: Ecommerce site - how? bit-naughty@hotmail.com - 2017-07-01 03:03 -0700
Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-01 09:30 -0400
Re: Ecommerce site - how? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-01 09:34 -0400
csiph-web