[MYSQL] 2 user-databases converteren

[Verwijderd]

Voor mijn huidige website heb ik in de database een tabel met gebruikers. Ik wil echter aan de site een forum koppelen, en wil hiervoor gebruik maken van Open Source software. Maar dit forum zou dan een aparte user-tabel krijgen, terwijl ik wil dat je slechts eenmaal hoeft te registeren.

Wat is nu de handigste manier om dit op te lossen? Zelf dat ik het volgende:
Iedereen registreert zich op de site. Bij eerste keer inloggen op forum worden de gegevens gekopieerd naar de forum-user-tabel. Wachtwoord veranderen/opvragen moet dan ook alleen via de site lopen en in beiden tabellen worden aangepast.

Of heeft iemand een ander idee? Vaak zijn de usertabellen van die fora dusdanig uitgebreid dat totaal integreren niet te doen is.

[Kalentum]

Zo'n forum heeft vast een login functie. Die kun je ombouwen om te authenticeren tegen je eigen database.

[Janoz]

Ik zou het eerder andersom doen. Je eigen inlog ombouwen naar de forum inlog. Dus eigenlijk de forum authenticatie gebruiken voor de rest van je site. Vaak zijn hier wel redelijk kant en klaar oplossingen voor te vinden.

[BCC]

Wat rutgerw zegt idd. Je kan ook de logins opslaan in bijvoorbeeld een ldap database. Heel veel applicatiies kunnen daar tegen authenticeren. PHP heeft ook goede ldap support.

[ Voor 5% gewijzigd door BCC op 24-01-2008 14:19 ]

[Verwijderd]

Zou zelf ook zoals je zelf al zegt de site koppelen aan het forum

Dus de userdatabase en de login van het forum gaan gebruiken
Klein beetje scripting, en t is handiger dan voor je site een totaal andere login/usersysteem te scripten

Gewoon dus als je inlogt naar de loginroutine van het forum gaan zodat die je sessies/cookies neerzet en je ingelogd bent op site en forum gelijk
Qua registreren is het net zo, je schrijft gewoon alles naar de usertable van het forum

[Kettrick]

Wat je ook kan doen is met wat triggers en views in de weer gaan en op DB niveau het forum tegen je site-user tabel aan laten praten. Op deze manier laat je de forum code origineel, dit heeft met upgrades natuurlijk een groot voordeel.

Met postgres is dat redelijk eenvoudig, of mysql hier inmiddels de mogelijkheden voor heeft weet ik niet zeker

[Gerrit88]

Waarom niet gewoon de user-tabel van het forum gebruiken? Je kan toch de data in de huidige gebruikers tabel toevoegen aan de nieuwe tabel voor het forum. Mijns inziens is het dan daarna een kwestie van je queries voor je login script aanpassen aan de nieuwe tabellen. Dan hoef je in elk geval geen moeilijke dingen te doen op db niveau. Ander voordeel is, war RoeLz ook al aangaf ,dat je inderdaad geen problemen heb met upgrades in de toekomst. Mischien is het wel verstandig nog even een optimalisatieslag te doen voor je de inhoud van je tabel zomaar kopieerd maar dat ligt uiteraard aan je huidige db structuur.

[DukeBox]

Of een table sync op event trigger.

[Gerrit88]

@DukeBox, nadeel is dan dat je dubbele data krijgt wat eigenlijk helemaal niet nodig is (naar mijn inzicht). Wat mij betreft is dat echt not done. Maar het kan wel een handige oplossing zijn als om een of andere reden een tabel niet haalbaar is.

[BCC]

Gerrit88 schreef op donderdag 24 januari 2008 @ 14:58:
@DukeBox, nadeel is dan dat je dubbele data krijgt wat eigenlijk helemaal niet nodig is (naar mijn inzicht). Wat mij betreft is dat echt not done. Maar het kan wel een handige oplossing zijn als om een of andere reden een tabel niet haalbaar is.

Idd, dat is een hack.. die werkt vast, maar mooi is het niet.

[DukeBox]

Nee, mooi zeker niet.. maar eigenlijk alle applicaties die singlesignon zeggen te zijn syncen op de achtergrond toch hun data.

[Janoz]

DukeBox schreef op donderdag 24 januari 2008 @ 18:00:
Nee, mooi zeker niet.. maar eigenlijk alle applicaties die singlesignon zeggen te zijn syncen op de achtergrond toch hun data.

Dat is niet waar. De meeste single sign on toepassingen hebben een centrale repositor waarin de credentials opgeslagen worden (Denk aan ldap en/of AD)

[DukeBox]

Ja via radius e.d. maar intern syncen (al dan niet als cache) ze de database of de opgevraagde gegevens.

[BCC]

DukeBox schreef op donderdag 24 januari 2008 @ 19:47:
Ja via radius e.d. maar intern syncen (al dan niet als cache) ze de database of de opgevraagde gegevens.

Nee? Je stuurt de username met password naar je ldap / radius. Dan krijg je een ack of nack terug. Op basis daarvan log je iemand in of niet. Lijkt me niet dat je dat wil cachen.

[DukeBox]

Dat wil je wel bij 100en verificaties per min. Bijv.met certificaten is het heel gebruikelijk dat je een ttl op de revocation list hebt.

[Janoz]

Maar dat is nog steeds een heel andere benadering. Daar wordt gedecentraliseerd vanwege optimalisatie. Uiteindelijk is er nog wel 1 leidende opslag en zijn alle 'caches' volgend. Dat is nog steeds iets heel anders dan twee even belangrijke authentication repositories die onderling moeten gaan syncen waarbij beschikbaarheid en performance nog geen enkele rol van betekenis zijn.