[Typo3-dev] the horror of different usertables

[Elmar Hinz]

> 
> 
>>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... :-)
> 

The image of one bit is in any case very nice. But as each user would be 
assigned to his groups it would be one bit in each assigning record. That means 
lots of bits if you have lots of users. Each bit on a differnt place on the data 
carrier.

Following the bit argument you could never trust your bank, cause with the 
change of one bit all your money can go to someone else. :-)

The risk lies rather in db queries, that are not coded correctly and admins that 
don't understand their system of groups. Things that happen.

> 
> 
> 
>>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);
> 
> ?>
> 
> 

Ok, lets overthink the mode of two synchronised table systems. Is it so trivial 
as you describe?

a.) You argued right that the circle of FE users is usually much bigger than 
that of BE users. Your approach kills all FE users that are not in the BE. Why 
does that matter? There are a lot sites, where FE users register themself. So 
they are not in the BE Table and shouldn't go there until the admin has added 
them to an appropriate group for that.

b.) On the other hand you want't to make use of the BE user administration. 
Regarding a.) that means that you probably need to compare the timestamps to 
decide which record is newer.

c.) You probably can't convert encrypted BE passwords to unencrypted FE 
passwords. (OK, there are plannings to change this.)

So how about this? Rather abstract.

<?php

$GroupMap = getFeToBeUsergroupsMap();
copyFeToBeUserIfYoungerAndInMappedGroup($GroupMap);
copyBeToFeUserIfYoungerAndInMappedGroup($GropMap);

?>

Assumption c.) is already solved.
As long as c.) is open Passwords could only changed from the frontend.


Regards

Elmar