[Typo3-dev] the horror of different usertables

[A.MacDonald-typo3 at slitesys.demon.co.uk]

Before I start I'm aware that I'm jumping into a topic that I've only been
skimming, and an area that I'm not overly familiar with, but it is 
something that I've been thinking about at odd intervals recently ...

On Tue, Jun 01, 2004 at 02:24:22PM +0200, Kasper Sk?rh?j wrote:
> On Mon, 2004-05-31 at 23:03, Michael Stucki wrote:
> > The only redundant position I see are username, name and email. Is this
> > really what we are discussing about?
> 
> ... and this redundancy is even removed when you use the same LDAP
> directory for both frontend and backend users - that would be the right
> solution.
> 
> ... but of course horribly redundant in Elmars eyes I suppose... :-)
> (since we would have to create "place-holder" records in
> fe_users/be_users tables...)

I've looked at LDAP as an authentication mechanism before and ran into
this fe_users/be_users business and I'm aware of at least one site for 
whom this could be a big problem for. Not because of duplication between
front and backend users, but because of the duplication between the
fe_users/be_users and the LDAP database and the synchronisation that it
requires. 

When I first started wondering about this and the question was why are 
be_users/fe_users required? The answer appears to be because so much of 
the code actually "knows" about them and just goes and gets the 
information that it wants directly from the tables. IE there is a
deficiency in the API which means you can't get this information any
other way. That suggested that the correct solution was to develop that
API and then replace the existing direct calls. This would also appear
to be compatible with the LDAP notes in the TODO list. The downside of
this is that this would affect quite a few extensions, such as 
newloginbox. At the time I wasn't sure how this could be implemented 
so that you could mix and match mechanisms. Now, however, I've read 
the document on services and that would seem to be the answer. (In
fact, that is used as an example in the services document) 

The net result of this would be that there would not need to be
any redundancy. If you wanted to store both sets of data in the same
table? Fine -- either write the appropriate service handler or make
the core version capable of handling this by using an (optional) flag
to indicate whether this user as fe/be privileges. If you want to use
LDAP for one or both? Fine -- the LDAP database stores all the 
information. You want to mix and match? Fine -- arrange for the
services to daisy-chain themselves.

I'm going to go back to lurking now. Of course, if anyone thinks this
makes sense and wants to talk to me, feel free. 

Alistair