[ic] security

[Mike Heins]

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.
> 
> We've had the same issue with order numbers recently.  Multiple users
> getting the same order number because the order counter did not update.
> It was pathological, it had to be our fault, but it should have been 
> caught (mv4.03).
> 
> 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-)

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

Nature, to be commanded, must be obeyed. -- Francis Bacon