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

[Ron Phipps]

Mike,

Can you discuss some of the other ways of handling the order number outside
of IC?  Were getting ready to launch a high traffic site next week Thursday
and if there is a chance that these errors could happen we'd like to avoid
that.  A bit about our setup, were running an Alpha 600 (EV56) with a gig of
RAM on RedHat with MySQL as the backend.  Are plans are to see how this box
handles under load and if it cannot do the job we'll be loading up another
Alpha 600 just to handle the MySQL server.  What is your recommended
solution for this situation?  Thanks for your help.

-Ron

----- Original Message -----
From: "Mike Heins" <mikeh@minivend.com>
To: <interchange-users@lists.akopia.com>
Sent: Friday, January 26, 2001 10:03 AM
Subject: Re: [ic] security (order number, failure to update)


> 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
>
> _______________________________________________
> Interchange-users mailing list
> Interchange-users@lists.akopia.com
> http://lists.akopia.com/mailman/listinfo/interchange-users