[ic] security (order number, failure to update)

cfm@maine.com cfm@maine.com
Fri, 26 Jan 2001 17:27:30 -0500

On Fri, Jan 26, 2001 at 01:03:23PM -0500, Mike Heins wrote:
> Quoting cfm@maine.com (cfm@maine.com):
> > On Fri, Jan 26, 2001 at 10:24:03AM -0500, Mike Heins wrote:
> > 
> > > > Still, if the system can't generate proper numbers and clean data what
> > > > should it do?  Shut down gracefully?
> > > 
> > > Most businesses don't ever like to stop taking orders as long as they
> > > are sure the price and delivery are reasonable. I usually fall back
> > > to an OrderNumber style file that has a unique series of numbers like
> > > ABC00000. The order number will be unique (presuming you set it up so
> > > each machine has a unique ID) and will alert you to the fact that there
> > > will be a customer service problem.
> > 
> > Agreed.  Still, the root of this thread that I've so handily
> > deleted was **failure** to update a number in a registered userdb.
> > Orders are same.  In that case orders or registered users get 
> > mixed or nixed, at least in the database and for anything else
> > that keys off that non updated sequence number.
> Are you telling me that Interchange's OrderCounter gave you back a number
> without die()-ing? That should never happen. If it can't increment, it
> should die. When did it not?

mv4.03.  It gave back the number from OrderCounter without die()ing 
and did not update.  I'm confident that we broke it (though I don't
know how) and I'm confident that mv did not die.

> > compromising more than just a sale.  Maybe it's enough to
> > verify that the counter file has been changed and synced to disk?
> > 
> That is supposed to happen in the increment. It should die if it doesn't.
> That is a hard failure, and you should always die on a hard failure.

    open($fh, "+<$file") or croak "Can't open $file: $!";
    flock($fh, 2) or croak "Can't flock: $!";  # 2 = exlusive lock

> I think we are talking about two different things here. I was assuming
> you were asking "what happens if my remote db/order number server goes down?".
> My answer is then that you fall back to OrderCounter. If OrderCounter fails,
> then you have a hard problem and should die (and presumably alert that the
> server is down).

Thank you, that answers my concern.  It sounds like your experience is 
it **should** die LOUDLY in such a situation.  In my opinion, minivend does
not die easy enough.  :-)


Christopher F. Miller, Publisher                             cfm@maine.com
MaineStreet Communications, Inc         208 Portland Road, Gray, ME  04039
1.207.657.5078                                       http://www.maine.com/
Content management, electronic commerce, internet integration, Debian linux