[Date Prev][Date Next][Thread Prev][Thread Next][Interchange by date
][Interchange by thread
]
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
