[ic] Remove Me

jkl9876543 jkl9876543@email.msn.com
Sat, 27 Jan 2001 01:09:15 -0600


----- Original Message -----
From: <cfm@maine.com>
To: <interchange-users@lists.akopia.com>
Sent: Friday, January 26, 2001 8:29 AM
Subject: Re: [ic] security (order number, failure to update)


> On Fri, Jan 26, 2001 at 12:09:48AM -0500, Mike Heins wrote:
> > Quoting cfm@maine.com (cfm@maine.com):
> > > On Thu, Jan 25, 2001 at 09:15:39PM -0700, John Beima wrote:
> > > > It appears if MiniVend is not able to create an account in the
UserDB, my guess
> > > > would be there are two orders going through at the same time trying
to
> > > > auto-create the same account name, since it is an incrementing
number, the
> > > > second one fails, and instead of an error generating, recieves the
user info
> > > > from the last logged in client, or the other user creation that it
collided
> > > > with.
> > >
> ...
> > > Failure to successfully update a counter should fail the
> > > transaction, even kill the catalog.
> > >
> > > We're going to <ahem>solve</ahem> it by using unique enterprise
> > > keys/counter for order numbers.  And we are setting up our catalogs
> > > to die on non-unique order numbers.  No doubt it will work just
> > > fine when everything is working.   Minivend needs a way to
> > > sequence order numbers independantly for multiple instances of
> > > the same catalog on independant machines, some of which may go
> > > offline but still take orders.  (eg POS/callcenter on localnet)
> > > The vanilla OrderCounter++ is not enough.
> > >
> > > It's getting to the point where the machine issuing unique numbers is
> > > more mission critical than our kerberos server.  yeesh.
> >
> > In recent Interchange (and maybe Minivend 4) all you have to do is
> >
> > [perl]
> > $Session->{mv_order_number} = your_unique_number();
> > [/perl]
> >
> > It will bypass OrderCounter at that point, and use yours. Then it
> > is on your head. 8-)
>
> Yes, we're using that but have not thought it through all the way.  We're
> grabbing an order number from our key generator, inserting the order
> into the order table and order_items table, and then verifying that
> we read back the same record.  On failure the idea was to send an
> op-header redirect; that didn't work too well on the **report** page. :->
> Fixed that.
>
> Still, if the system can't generate proper numbers and clean data what
> should it do?  Shut down gracefully?
>
> cfm
>
> --
>
> 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
>
> _______________________________________________
> Interchange-users mailing list
> Interchange-users@lists.akopia.com
> http://lists.akopia.com/mailman/listinfo/interchange-users
>