Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.php > #17480

Re: Ecommerce site - how?

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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