Unique user accounts

[Markus Schaber <schaber@scan-plus.de>]

Hello,

I just want to apologize for my last post that had a misleading subject.

Thanks to those who pointed me to various "atomic incremental" methods
I already found myself before via google and the ml archive search,
and more thanks to all who pointed me to google and the ml archive.
Maybe they only read the subject of my mail, maybe that my statements
were not clear enough.

So I'm afraid I have to make more explicit what I need.

> Our scenario:
> Our customers get unique, but ugly identifiers which are created by a
> mechanism not under our control.

Those identifiers are, as I wrote, unique, and thus serve well as an
internal ID tag. So I don't need an "atomic incremental" scheme for
creating unique ids in a near-sequential way.
 
> Now we want to enable them to create alias names via web interface. As
> this alias names are to be used for creation of web urls and email
> adresses, they must be unique.
> Now, how can I ensure in a bullet-proof way that an alias name is
> unique?

The problem is that the customer should be able to suggest this alias
(e. G. in the form of firstname.lastname), and my app has to test
whether this alias already exists.

> Simply looking whether it exists before adding it to the directory is
> not considered bullet-proof as there could be concurrent access by
> several customers.

So this method presents an obvious race condition.

Looking whether it exists twice after adding it doesn't work because
first, we might have a small moment where both aliases exist which makes
some of our other software going mad, and second, two customers
concurrently trying to create the alias could result in both getting the
error message, and thus rejecting an alias that is free.

Our current solution is to use an external lockfile with fnctl-locking
in all applications, but this is a) ugly because we have to maintain
this mechanism in a bunch of apps, and b) will fail as soon as one of
our app instances doesn't have access to a common file system any more.

> In SQL, I'd use transactions, but I never heard of transactions
> existing in LDAP.

I found a paper about ldap transactions in the web, it is available
under: http://www.openldap.org/conf/odd-wien-2003/proceedings.html
However, this paper doesn't tell anything about whether this is already
implemented, and where to get it.

Thanks for your patience,
Markus Schaber