[Typo3-dev] the horror of different usertables

[Kasper Skårhøj]

On Mon, 2004-05-31 at 00:56, Elmar Hinz wrote:
> Kasper Skårhøj wrote:
> 
> > This has been suggested before with the same arrogance about the
> > "weakest point" argument. It turns out that this totally depended on the
> 
> I don't see any arrogance in having a personal point of view.
> 
> Any system that keeps redundant data at any point I will probably consider a 
> weak system at that point even in 10 years.

Redundant data is not a problem if it is automatically synchronized
which I suggest you do.


> As soon as you administer a website with more than 1 person you have a community 
> system. As soon as you set up FE users you have a community system. From this 
> point of view I call 95% of typo3 a community system. I guess it is rather a 
> great exeption, that there are two completely different groups of people on both 
> sides. Even in your basic tutorial "Kom i gang" that is not the case. Am I 
> right? It's long ago I read it.

again: you must come from the community point-of-view. Other people set
up websites with internal editors (like in a company employee) and
external customers (thousands of people getting access to the website).
Such scenarios are all over the place and people love the "big wall" as
a concept because it emphasises the separation they already want to be
very clear; that customers logging in on the website does not share the
slightest degree of interests with employees working from inside.

The concept is well known from electronics as well where you use "photo
transistors" (I can't remember the right name) to hermetically separate
circuits. You do so mainly because you want to add protection in extreme
cases where a lightning bold strikes the one system. 
its the same here. We could merge the tables but suddenly only a single
bit separates a frontend user from a backend user and when the lightning
strikes you never know what happens.

Separate user tables build trust.


BTW: Lets make a poll:

Who thinks the current "dual-user-table" is:
- A "big wall" that is TYPO3s "weakest point": [YES] / [NO]

Who thinks that merging the backend and frontend users table into one
table is:
- A good idea: [YES] / [NO]
- A top-priority (higher than planned core work): [YES] / [NO]

If you answered "YES" to any of the above, do you want to:
- Scan all (at least core) documentation for places where the
frontend/backend users are mentioned and change the wording so it
describes the new situation with a single table.
- Write a converter utility that offers to merge the two tables in all
existing installations when they upgrade.
- Carefully analyse the core and most important extensions for the
impact such a change would have including necessary patches to changes
needed.
- Carefully test the reliability of the new concept so you can convince
sceptics that the new single-user-table is a very secure solution.


> 
> That is the reason why this point is so important and will cause trouble as long 
> as is not solved. Directly in the center of the city you set up this big wall, 
> just at a place where only the fewest people really need it. And a lot of people 
> get victim of disater while going the unnecessary long ways to get on the other 
> side.

With your suggestion one bit could trigger the end of the world... :-)



> In the resulting overhead of syncronization, as you propose it, I personally 
> rather see new doors of weakness. Syncronization isn't trivial and failures have 
> to be expected.

Well, it *is* trivial. I could make a bugfree syncronization script in
100 lines PHP code after this model:

<?php

$be_users = selectAllBackendUsers();	// Backend users = master table
$fe_users = selectAllFrontendUsers();	// Frontend users = slave table

deleteAllFeUsersThatAreNotBackendUsers($be_users,$fe_users);
createMissingFeUsersThatAreBackendUsers($be_users,$fe_users);
synchronizePasswordsForTheRest($be_users,$fe_users);

?>


... but I couldn't sleep well at night if 10.000 fe-users on typo3.org
were in the be_users table! (let alone manage the mere 20 accounts
effectively that actually should have backend access!)


> 
> It realley would stimulate me to see, how to clean up the code that such a 
> change wouldn't be so difficult but rather be done in one place. And with the 
> additional feature to choice between one and two parallel user tables as goody.

You are trying to turn around a very big ship. I have done that a few
times in history and I know the cost. You probably don't.

- kasper