Ik probeer het volgende systeem op te zetten:
client komt op domein1.nl
domein1.nl haalt login.php op via JSON van domein2.nl
Het loginformulier wordt gevalideerd dmv javascript die in hetzelfde bestand beschreven staat (dmv JSON werkt dit al).
Zodra het loginformulier gesubmit wordt moet domein2.nl controleren of gebruikersnaam/wachtwoord klopt, en als die klopt moet er een sessie met de ingevulde gebruikersnaam tussen de client en domein1.nl komen.
Waarom dit systeem? De gebruikerstabel is onderdeel van een backoffice met een firebird database. Firebird kan echter via PHP alleen benaderd worden met de interbase plugin en aangezien veel van onze klanten bij hun hosting geen interbase-ondersteuning krijgen willen we dit dmv JSON oplossen.
Data verzenden naar domein2.nl (met interbase ondersteuning) lukt al wel, evenals data (HTML en JAVASCRIPT) lukt ook, alleen een blijvende sessie tussen client en domein1.nl creëeren lukt niet.
Als iemand zich hier een beeld van kan vormen en mij een optie kan geven, graag :).
De gemakkelijkste manier is om de gebruiker in te laten loggen op domein1.nl (dus de gebruiker heeft alleen direct contact met domein1.nl) waarna de server van domein1.nl zelf via bijv. [php]file_get_contents[/php] aan domein2.nl zal vragen of de gegevens correct zijn. Dit is eigenlijk precies hetzelfde als normaal inloggen, behalve dat je dan niet aan de database vraagt of de gegevens kloppen, maar aan een andere webservice. Klein verschil.
Als je main concern is dat domein1.nl niet de logingegevens van de gebruiker zelf te weten mag komen kan je een schema zoals OAuth implementeren. Maar ook dan zullen de servers van domein1 en domein2 met elkaar moeten praten.
Als dat het probleem is (de servers van domein1 en domein2 mogen niet met elkaar praten) zou je iets ingewikkelds kunnen maken wat lijkt op dat wat banken doen met zo'n pincode apparaatje dat je gebruikt wanneer je inlogt op internet bankieren. Heel simpel uitgewerkt: domein1.nl vraagt je om in te loggen op domein2.nl, maar vraagt je ook om $token mee te sturen naar domein2.nl. Ondertussen onthoud domein1.nl $token in een sessie. Zowel de server van domein1.nl als domein2.nl weten $shared_secret, een lange reeks random spul. Als inloggen op domein2.nl lukt, stuurt domein2.nl je terug naar domein1.nl met sha1($token . $shared_secret) als data. Domein1.nl kan diezelfde sha1-hash genereren, en kijken of hij gelijk is aan die van domein2.nl. Is dat het geval, en ervan uitgaande dat alleen domein2.nl in staat is die hash te genereren omdat dat de enige andere server is die $shared_secret kent, kan je vaststellen dat inloggen op domein2.nl is gelukt.
De gemakkelijkste manier is om de gebruiker in te laten loggen op domein1.nl (dus de gebruiker heeft alleen direct contact met domein1.nl) waarna de server van domein1.nl zelf via bijv. [php]file_get_contents[/php] aan domein2.nl zal vragen of de gegevens correct zijn. Dit is eigenlijk precies hetzelfde als normaal inloggen, behalve dat je dan niet aan de database vraagt of de gegevens kloppen, maar aan een andere webservice. Klein verschil.
file_get_contents is idd een optie, ik heb het al eerder gebruikt, maar probleem is een beetje dat ik een standaard probeer te maken voor zowel het login script als een lijst producten van een webshop oid. Het probleem van file_get_contents is dan dat de client informatie opvraagt aan domein2 - Als je in firefox een lijst afbeeldingen ophaalt met file_get_contents staat er "bezig met laden van domein2".
De client moet niet kunnen zien dat er verbonden wordt met domein2, in ieder geval niet op het eerste gezicht, het is momenteel wel mogelijk om in de broncode door te klikken en vanzelf op domein2/bestanden/bestnand.php met heel veel encrypted getvariabelen te belanden, maar dit is niet zo zeer het probleem.
Jelmer rrrr op 10/08/2011 15:32:46
Als je main concern is dat domein1.nl niet de logingegevens van de gebruiker zelf te weten mag komen kan je een schema zoals OAuth implementeren. Maar ook dan zullen de servers van domein1 en domein2 met elkaar moeten praten.
Domein1 mag gegevens de inloggegevens van de gebruiker zien.
De eigenaar van domein1 is tevens de eigenaar van de database en domein2 is in ons beheer. Alleen omdat domein1 zonder interbase niet in staat is zijn eigen database te benaderen is domein2 benodigd.
Tevens staat zo veel mogelijk coding (dwz: HTML, JAVASCRIPT, PHP, SQL) op domein2 zodat dit in eigen beheer is met het oog op eventuele wijzigingen van de database in nieuwe updates van onze back-office, dan kunnen deze wijzigingen in onze eigen coding worden aangepast voor alle klanten die hun site (domein1) via deze methode werken.
Het zou het mooiste zijn als hij een userID en een userNAME is een sessie heeft staan op basis waarvan hij bepaalde content wèl en niet kan weergeven.
Jelmer rrrr op 10/08/2011 15:32:46
Als dat het probleem is (de servers van domein1 en domein2 mogen niet met elkaar praten) zou je iets ingewikkelds kunnen maken wat lijkt op dat wat banken doen met zo'n pincode apparaatje dat je gebruikt wanneer je inlogt op internet bankieren. Heel simpel uitgewerkt: domein1.nl vraagt je om in te loggen op domein2.nl, maar vraagt je ook om $token mee te sturen naar domein2.nl. Ondertussen onthoud domein1.nl $token in een sessie. Zowel de server van domein1.nl als domein2.nl weten $shared_secret, een lange reeks random spul. Als inloggen op domein2.nl lukt, stuurt domein2.nl je terug naar domein1.nl met sha1($token . $shared_secret) als data. Domein1.nl kan diezelfde sha1-hash genereren, en kijken of hij gelijk is aan die van domein2.nl. Is dat het geval, en ervan uitgaande dat alleen domein2.nl in staat is die hash te genereren omdat dat de enige andere server is die $shared_secret kent, kan je vaststellen dat inloggen op domein2.nl is gelukt.
[size=xsmall]Toevoeging op 11/08/2011 10:19:09:[/size]
