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

Groups > comp.lang.php > #17476 > unrolled thread

Ecommerce site - how?

Back to article view | Back to comp.lang.php

Contents

  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

Page 3 of 3 — ← Prev page 1 2 [3]

#17521

On 6/30/2017 5:15 PM, Gordon Burditt wrote:
>> Yes, some can last.  However, that does not mean an IP change will
>> interrupt them.  Connections run at the transport layer, while the ip is
>> part of the network layer.  The transport layer is pretty well insulated
>> from the network layer.  And ssh, telnet, etc. are way up at the
>> application layer, well insulated from either of the two.
>>
>> Yes, it does take a little time for either system to realize the ip has
>> changed.  
> 
> You are describing a potentially severe TCP connection hijacking
> vulnerability which I don't believe exists, at least not in this
> simple form.  
>

Nope, it's not a vulnerability because HTTP does not depend on the IP
address.  At least people who know how to program websites properly
don't.  And neither does NNTP or many other services.

Now when you are talking links like (s)ftp, ssh and the like, it's a
different story.

> From the point of view of the server, how does it tell the difference
> between an IP change or the much more likely situation that the 
> client:
> 	(a) lost power
> 	(b) lost its dialup connection
> 	(c) had its network disconnected, or
> 	(d) is in the process of rebooting
> In both cases, the server keeps retrying sending a packet, and it
> never gets any responses back, except possibly RST packets.
> 

It doesn't - and it doesn't care.  After so many retries, the packet is
dropped.  However, when the client gets its new IP, it reestablishes the
connection with the server and things continue.

>> There can be up to seven outstanding packets.  If a packet
>> does not get a response after some period of time, it will be retried
>> (network layer).  This generally takes a few seconds.  But once the
>> packet is retried successfully, communications continues.
> 
> 
> A TCP connection consists of a unique set of:
> 	Server IP address
> 	Client IP address
> 	Server port
> 	Client port
> 
> If you change one of these (at the endpoints of the connection),
> it's *NOT* the same connection as before and it shouldn't affect
> that connection, which is now dead, even if neither end realizes
> it yet.  (If you change the IP address of one of the intermediate
> routers, this shouldn't cause a problem).
> 

So?

> If the server sends a packet with the old client IP address, it
> won't even REACH the client (it no longer has that IP).  It will
> reach some other system assigned that IP, which will send back a
> RST packet, or a router will notice that there's no system with
> that IP on the network, and drop it.  The server can retry all it
> wants; it will not get the packet back to the original client (unless
> the client changes its IP back to the original one, or starts up a
> new connection with the new IP).
> 

So?

> If the client sends a packet with the new client IP address to the
> server, the server will try to associate it with a connection, find
> that there isn't any existing connection with the new IP address,
> and drop it, sending a RST packet back to the client.  The client
> can retry this forever and it will not work, again assuming the
> client IP address is not changed back to the original one.
> 

So?  The client sees the RST packet and simply reestablishes the
connection.  No problem.

> The only fix here is for one end (the client) to abandon the old
> connection and re-establish a new connection with the server, and
> do whatever it is to set up the state of the aborted session.  (HTTP
> is stateless.  Cookies, the contents of the server database, pages
> with dynamic content, etc. aren't.)  The server will eventually
> abandon its connection when all of the retries fail.
> 

Which is what happens transparently to the user (other than maybe a
slight stutter in the data flow).

> What prevents me from taking over a TCP connection from a client?
> I'm on the same network as the client, so I send the server a packet
> with my IP, which is slightly different from the IP of the original
> client.  If necessary, I "accidentally" trip over the power cord
> of the original client so it doesn't respond.  Is the server going
> to let me use the original client's connection with the new IP?  I
> sure hope not.  Note that I have a much better chance of hijacking
> a TCP connection if I knock the original client offline, then change
> my IP to that of the original client.
> 

Because retrieval via HTTP doesn't depend on the IP address.  Sure, you
might get some packets - but your system wouldn't know what to do with
them.  And even if you got the packets, you wouldn't be able to send the
correct session cookie to the server, so the server will reject any
requests depending on that cookie.

> 
>>> What is a "webinar"?  I think it involves real-time streaming
>>> interactive video.  To get anything meaningful out of it, a connection
>>> needs to last way more than a few seconds.  Since it's interactive,
>>> you can't download the whole thing in 2 seconds and spend 2 hours
>>> watching it.  (The same applies to VOIP phone calls).
>>>
>>
>> Where have you been?  Webinars have been around for over 20 years.  And
> 
> True, but I don't think the word "webinar" has been around that long
> with the specific implication of the presentation being real-time
> and interactive.
> 

Actually, it has.

>> yes, it is a live presentation, often times 30 to 50 minutes long,
>> although I've seen ones which last all day (with multiple
>> presentations).  But once again, a change in the client's ip doesn't
>> break the connection; there will be a stutter while it recovers, but it
>> continues on.
> 
> I don't believe that's possible unless it re-establishes a TCP
> connection.  If it realizes there's no data, which it can probably
> determine faster than for a ssh session that can legitimately sit
> idle for minutes while the user gets coffee, it can re-establish
> the connection quickly.
> 

Which, as I have tried to explain to you over and over, is exactly what
happens.

But once again I'm trying to teach a pig to sing.  I suggest you read up
on TCP/IP and various protocols and learn how they work.  I'm done with you.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17514

On 6/29/17 7:16 PM, Gordon Burditt wrote:
>> Nope, because connections are bi-directional.  My client was
>> communicating with the webinar's server.  If the IP changed, the next
>> packet would have the new address and the server would respond to the
>    ^^^^^^
> Do you mean "connection" here?
> 
>> new address.  At most seven packets would have to be retried.
> 
> A TCP connection is defined as a unique combination of 4 items:
> 	- The server IP address
> 	- The client IP address
> 	- The server port number
> 	- The client port number.
> 
> You can't change any of these and have the connection stay up.
> (Although the ends might have different views of what these values
> are, especially in the case of NAT gateways).
> 
> One way for your IP to change would be a configuration change
> in the DHCP server, followed by a lease renewal.  My DHCP servers
> seem to like renewing the IP a client already has, but if that
> IP is removed from the acceptable IPs for this client, it will
> change.
> 
> If my (client) IP address changed due to renewing with a different
> address, how does the TCP connection survive?  I've always observed
> that both ends of the connection are disconnected.  Eventually they
> time out and go away, but this might take 45 seconds.
> 
> NNTP connections don't survive an IP change, largely because they
> stay up for hours while you're reading USENET, unlike a web server
> which is likely to load a page and disconnect, so connections last
> a few seconds.
> 
> Now, if the IP change happens between TCP connections (so none are
> up when the change is made, that's OK).  I'm not so sure that http
> wouldn't have a persistent connection that would have to time out
> (and probably show an error on the browser).
> 
> 

HTTP is a stateless protocol, so a connection is only as long as a 
single page load. I also knew that at least at one time some ISPs 
wouldn't assign users a routable IP address, but give end users an IP in 
the 10.x.x.x range, and ran NAT at their boarder. This let them work 
while needing less routable IP addresses than subscribers, so while a 
give connection would need to use a constant IP/port, other connections 
would might use a different IP address. This meant that you couldn't 
lock a session to the starting IP address, as for those users, it could 
vary over a /24 network.

[toc] | [prev] | [next] | [standalone]

#17511

>> 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.

I'm suggesting that the IP from which the webpages are requested
*ALWAYS* changes for some ISPs.  Or almost always.  And this has
nothing to do with sub-second leases from DHCP.

Imagine an ISP who has a large load-balancing web proxy server setup
with one thousand caching servers.  Your web request gets sent to
one of the servers, somewhat at random (due to the load-balancing
feature), and if it's not in the cache (or you are requesting dynamic
content), that server (with one of a thousand outside IPs) requests
the page from the server you are accessing.  I believe this is just
what AOL does.  Or at least did.  And they probably aren't the only
ones, although most won't need a thousand servers.  You had a chance
of about 99.9% of getting a different IP from your last HTTP request
on your next HTTP request.  Even 10% would be pretty disruptive of
shopping carts.

I have heard some arguments that this kind of proxy, (besides saving
ISPs money for high-bandwidth pipes to the internet, or earning
money injecting ads) serves some kind of security purpose and that
the goal should be to NEVER repeat a source IP address.  (Obviously,
this is impossible with IPv4, not sure about IPv6.  And it might
require a lot of effort to provide NEVER repeating vs.
twice-in-the-lifetime-of-the-universe repeating with IPv6).  I don't
think I believe that.  What counts is whether the ISPs believe it.

Your browser or OS knows nothing of those IP changes.  Your browser
thinks it has the same IP the whole time (which might be 10.167.230.77,
a private address which shouldn't appear on the Internet but may
be used by systems behind NAT gateways.  Example: some cable systems.
Also, some home routers use private addresses and NAT so the one
real IP you get is shared between devices on your home Wi-Fi and
wired network).

You may not be allowed to avoid this setup from this ISP (without
a VPN) - if it goes to port 80, it goes through the proxy setup,
even if the destination IP on the packet says go direct.  The ISP
may also alter the page you see (e.g. insert their own ads, which
hopefully doesn't apply if you're using https:, so you might see
AT&T ads on what you thought was the Sprint website).


> 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).

If they don't use the IP for the anti-leeching, but instead use a
session cookie given out on the home page or whatever, it still
might work.  Among other things, no session cookie, no image.  
You could also test if the session cookie was reasonably recent.

Some sites that won't let you use them unless they see your browser
fetching ads, might break if they use the IP address to determine
this.  If they only use the session cookie, it would still work.

>> 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.

If you use a session cookie and NOT THE IP ADDRESS, it would work fine.

Logging in works for an arbitrarily long period of time as long as the
user remembers his login credentials.  The shopping cart is attached
to the account.  Log in, you get your account back.  Doesn't matter 
how many different devices you use or their IP address.  Doesn't
depend on cookies, either (you can't put a cookie on multiple devices
at the same time, especially if some of them are offline).

> 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. :-(

The solution for it:  DO NOT USE THE CLIENT IP ADDRESS to define a
session.  That's going to break anyway when you have many users using
the same IP (behind a NAT gateway), such as a home, school, military base, etc.
Use a large, randomly-generated session cookie.

You might legitimately use the IP for:
	- Security logging.  If they damage your site, it might be useful in 
	  conjunction with ISP logs in court.  The same applies to logging what
	  you shipped out and to what (postal) address.
	- Initially defaulting the user's language until he gets a chance to select it.
	- Historical statistical information (like what states/countries 
	  customers come from).

[toc] | [prev] | [next] | [standalone]

#17504

Guys, a lot has been said, but I'm still not getting a clear answer to my first question - inside the cookie, WHAT is equal to <something>? I'm guessing it's like - "userid=7305" - am I correct? i.e. it has the USERID info inside the cookie, and then on the server, the figure "7305" is associated with that user's cart info or whatever... Am I correct about all this?

[toc] | [prev] | [next] | [standalone]

#17505

On 6/27/2017 1:58 PM, bit-naughty@hotmail.com wrote:
> Guys, a lot has been said, but I'm still not getting a clear answer to my first question - inside the cookie, WHAT is equal to <something>? I'm guessing it's like - "userid=7305" - am I correct? i.e. it has the USERID info inside the cookie, and then on the server, the figure "7305" is associated with that user's cart info or whatever... Am I correct about all this?
> 

The cookie on the user's system will have some (rather lengthy) value
which identifies the session on the server.  The exact format of the
cookie is immaterial because the server sets the cookie and the server
reads the cookie.

The session on the server then contains some information.  It may be the
items in the shopping cart, it may be a (pending) transaction id, or
even a row id in a SQL database.  Again, that's internal to the server,
and unimportant in the scheme of things.

The thing to remember is the user's browser contains a cookie which
identifies the session.  The server has the session data in whatever
form it requires.

A good design stores nothing critical on the client's machine.  For
instance, it *could* (but generally does not) store item numbers there.
That's OK, because even if the user changes the item number, all he/she
will get is a different item.

But the design should *NOT* store the price on the user's computer.
Doing so could allow the user to change the price such that he/she could
get a $2,000 item for $2.00 - or even $0.02.  The price would be
considered critical information.

But in general it's just easier to keep everything in one place, which
would be on the server.  That way there is no potential problem with
data being changed by the user.  And if the user does change the session
id, chances are he/she will be unable to hijack someone else's session
because it's rather long (in PHP the default is 32 randomly generated
alphanumeric characters).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17519

> Guys, a lot has been said, but I'm still not getting a clear
> answer to my first question - inside the cookie, WHAT is equal to
> <something>? I'm guessing it's like - "userid=7305" - am I correct?
> i.e. it has the USERID info inside the cookie, and then on the
> server, the figure "7305" is associated with that user's cart info
> or whatever... Am I correct about all this?


The default name of the session cookie in PHP is PHPSESSID.  An
application running on a web server can change the name to anything
it wants within limits of the character set for cookie names.
Actual businesses are unlikely to use swear words for the cookie
names because customers might be offended.

The value of the cookie is a string of characters, probably
representing a large (e.g. >= 128 bits, equivalent to about 39
decimal digits) random number.  It might be represented as hexadecimal
or base64 or something else.

It's supposed to be a large random number so large that the liklihood
of having two come out the same in the same century is minimal.

PHPSESSID=3jvagi4HJgb43bkkl2j7hGF7GbjskerPZQ

The session ID represents a SESSION, NOT a "user". A "user" is
usually a particular human being.  You could have several sessions
going at once (e.g. from your cell phone, your desktop, and your
tablet).

If you're looking for some deep inner meaning of the value:  there
isn't one.  It's likely a primary key of a database table that holds
information like "user id", when the session expires, and possibly
shopping cart information.

PHP generates the session ID, and interprets it.  You don't need
to worry about it beyond "it's a string", and the maximum length
of it so you can define a database field to hold it.

Some systems generate a new session ID for every page, with the
database entry being updated at the same time.  This offers some
(but far from perfect) protection against session hijacking, as if
you sniff a session ID on the network, you have very little time
to use it before it's changed.

It is likely that the session expiration time is updated on every
new page, so the session lasts as long as you keep using it and
some time period, like an hour or a week, beyond that.

[toc] | [prev] | [next] | [standalone]

#17524

On Saturday, July 1, 2017 at 3:25:55 AM UTC+5:30, Gordon Burditt wrote:
 
> The default name of the session cookie in PHP is PHPSESSID.  An

Ahh! THIS is the info I was looking for - Thanks Gordon! :)
Yes, I know it has no "deep inner meaning" :) But hang on - what if I go to 2 different Ecomm sites, which *each* set one of these "PHPSESSID" things? How will the system differentiate between each site's?

[toc] | [prev] | [next] | [standalone]

#17525

On 7/1/2017 6:03 AM, bit-naughty@hotmail.com wrote:
> On Saturday, July 1, 2017 at 3:25:55 AM UTC+5:30, Gordon Burditt wrote:
>  
>> The default name of the session cookie in PHP is PHPSESSID.  An
> 
> Ahh! THIS is the info I was looking for - Thanks Gordon! :)
> Yes, I know it has no "deep inner meaning" :) But hang on - what if I go to 2 different Ecomm sites, which *each* set one of these "PHPSESSID" things? How will the system differentiate between each site's?
> 

Cookies are domain-specific.  A cookie for one domain is not sent do
another domain.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17526

On 7/1/2017 6:03 AM, bit-naughty@hotmail.com wrote:
> On Saturday, July 1, 2017 at 3:25:55 AM UTC+5:30, Gordon Burditt wrote:
>  
>> The default name of the session cookie in PHP is PHPSESSID.  An
> 
> Ahh! THIS is the info I was looking for - Thanks Gordon! :)
> Yes, I know it has no "deep inner meaning" :) But hang on - what if I go to 2 different Ecomm sites, which *each* set one of these "PHPSESSID" things? How will the system differentiate between each site's?
> 

Oh, and BTW - the default name for the PHP session currently is
PHPSESSID.  But this can be changed - the actual name is immaterial as
long as the scripts that set the name and the ones that get the name
agree on it.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.php

csiph-web