[ic] security (order number, failure to update)
Fri, 26 Jan 2001 13:03:23 -0500
Quoting email@example.com (firstname.lastname@example.org):
> 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
> > 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 <email@example.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