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

[Mike Heins]

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?

I have seen some reported problems with File::CounterFile on BSD, but
not otherwise.

> 
> > That is why Interchange writes orders 4 places by default -- the
> > order email image (based on order number), the database, the email,
> > and if all else fails the tracking.asc file. Obviously you run from
> > one, but the others are there to reconstruct if necessary.
> 
> We've stopped paying attention to the tracking.asc file.  That 
> is a good idea to revisit.  Thank you.  In a real time scenario -
> say the userdb and access permissions - one runs the risk of 
> 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.

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

-- 
Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
phone +1.513.523.7621 fax 7501 <heins@akopia.com>

I don't want to get to the end of my life and find I have just
lived the length of it. I want to have lived the width of it as
well. -- Diane Ackerman