Session tussen 2 domeinen
Ik wil een oplossing bouwen waarbij het mogelijk is om op domein A in te loggen, en deze inloggegevens middels sessions te kunnen gebruiken op domein B.
Heeft iemand hier ervaring mee, en hoe kan ik dit het beste bouwen?
Heeft iemand hier ervaring mee, en hoe kan ik dit het beste bouwen?
Tussen subdomeinen is het het nog wel te doen. Maar twee losse domeinen domeinA.nl en domeinB.nl is echt een stuk lastiger, omdat browsers het niet toestaan dat cookies op meerdere domeinen kunnen worden uitgelezen.
De enige oplossing die ik ken is een eigen Sessionhandler te schrijven, en de data daarvan te delen in de database.
http://php.net/manual/en/class.sessionhandler.php
De enige oplossing die ik ken is een eigen Sessionhandler te schrijven, en de data daarvan te delen in de database.
http://php.net/manual/en/class.sessionhandler.php
Tussen verschillende subdomeinen kun je zeker met dezelfde sessie werken. Tussen verschillende domeinen op dezelfde server misschien, weet ik niet zeker. Vertel eens of de domeinen op een eigen server staan?
Toevoeging op 15/11/2014 11:28:39:
Tussen verschillende subdomeinen kun je zeker met dezelfde sessie werken. Tussen verschillende domeinen op dezelfde server misschien, weet ik niet zeker. Vertel eens of de domeinen op een eigen server staan?
Toevoeging op 15/11/2014 11:28:39:
Tussen verschillende subdomeinen kun je zeker met dezelfde sessie werken. Tussen verschillende domeinen op dezelfde server misschien, weet ik niet zeker. Vertel eens of de domeinen op een eigen server staan?
Het kan "op de oude manier" door een sessie-ID mee te geven in een URL, dus met links in de stijl: index.php?sid=... Daarbij deel je de sessiedata achter de schermen inderdaad via bijvoorbeeld een gemeenschappelijke database, zoals Aar uitlegt.
Niet echt veilig, daarom doen we het liever niet meer, maar voor alledaagse toepassingen wel voldoende veilig te maken, bijvoorbeeld door met extreem sterke sleutels te werken die hooguit enkele seconden mogen worden gebruikt en die alleen via SSL te transporteren.
Niet echt veilig, daarom doen we het liever niet meer, maar voor alledaagse toepassingen wel voldoende veilig te maken, bijvoorbeeld door met extreem sterke sleutels te werken die hooguit enkele seconden mogen worden gebruikt en die alleen via SSL te transporteren.
Bij dit soort vragen is allereerst belangrijk WAAROM?
Websites zijn op zichzelf staande eilandjes die niks met elkaar te maken hebben. Het is dan ook niet logisch dat ze sessie-bestanden met elkaar delen. Zelfs al zijn de (eigenaars van de) websites "vriendjes" met elkaar.
Websites zijn losse dingen, allemaal met hun eigen leden. Als je gebruik wilt maken van website A zul je je eerst moeten aanmelden "ding dong, daar ben ik... mag ik naar binnen?". Als je vervolgens wordt toegelaten tot website A, wil dat niet zeggen dat je ook automatisch wordt toegelaten tot website B. Het zijn eilandjes, weet je nog? Ook hier zul je je dus weer even moeten aanmelden.
Mijn advies: laat het idee van het onderling delen van sessies compleet varen, want je haalt je een hoop ellende op de hals.
Websites zijn op zichzelf staande eilandjes die niks met elkaar te maken hebben. Het is dan ook niet logisch dat ze sessie-bestanden met elkaar delen. Zelfs al zijn de (eigenaars van de) websites "vriendjes" met elkaar.
Websites zijn losse dingen, allemaal met hun eigen leden. Als je gebruik wilt maken van website A zul je je eerst moeten aanmelden "ding dong, daar ben ik... mag ik naar binnen?". Als je vervolgens wordt toegelaten tot website A, wil dat niet zeggen dat je ook automatisch wordt toegelaten tot website B. Het zijn eilandjes, weet je nog? Ook hier zul je je dus weer even moeten aanmelden.
Mijn advies: laat het idee van het onderling delen van sessies compleet varen, want je haalt je een hoop ellende op de hals.
Ik denk dat ik al een oplossing heb.
Slechts 1 MySQL database gebruiken voor 2 domeinen.
Het betreft een VPS, en beiden domeinnamen draaien op dezelfde VPS.
Slechts 1 MySQL database gebruiken voor 2 domeinen.
Het betreft een VPS, en beiden domeinnamen draaien op dezelfde VPS.
Hey,
Als je in twee domeinen wilt inloggen met sessions, dan heb jij twee oplossingen.
- ajax calls
- redricts
- met ajax kan je een http request gebruiken voor elke domein.
Met redrict kan je die stappen gebruiken.
Belangrijk:
zij moeten allebei redrictlogin.php pagina hebben
Als je in twee domeinen wilt inloggen met sessions, dan heb jij twee oplossingen.
- ajax calls
- redricts
- met ajax kan je een http request gebruiken voor elke domein.
Met redrict kan je die stappen gebruiken.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
In domein1.com:
$login = checklogin();
if($login == 'success') {
createSession();
redrict('http://domein2.com/redrictlogin.php?user='.usernaam.'&pass='.password);
die();
}
In domein2.com/redrictlogin.php pagina
$login = checklogin();
if($login == 'success') {
createSession();
// redrict back terug naar domein1;
redrict('http://domein1.com/');
die();
}
$login = checklogin();
if($login == 'success') {
createSession();
redrict('http://domein2.com/redrictlogin.php?user='.usernaam.'&pass='.password);
die();
}
In domein2.com/redrictlogin.php pagina
$login = checklogin();
if($login == 'success') {
createSession();
// redrict back terug naar domein1;
redrict('http://domein1.com/');
die();
}
Belangrijk:
zij moeten allebei redrictlogin.php pagina hebben
Gewijzigd op 16/11/2014 09:01:12 door Simo Mr
Ozzie PHP op 15/11/2014 17:18:12:
Dit is wel een beetje flauwekul hoor en enigszins schoolmeesterachtig. Een goed voorbeeld is Coolblue met zijn tientallen websites(domeinen) die absoluut geen eilandjes zijn. En waarom een hoop ellende, TS zegt dat de websites op 1 vps draaien en kennelijk zijn ze aan elkaar gerelateerd. Mijn voorbeeld van Coolblue slaat ook echt niet 10x mijn NAW op. TS heeft wellicht iets vergelijkbaars.Bij dit soort vragen is allereerst belangrijk WAAROM?
Websites zijn op zichzelf staande eilandjes die niks met elkaar te maken hebben. Het is dan ook niet logisch dat ze sessie-bestanden met elkaar delen. Zelfs al zijn de (eigenaars van de) websites "vriendjes" met elkaar.
Websites zijn losse dingen, allemaal met hun eigen leden. Als je gebruik wilt maken van website A zul je je eerst moeten aanmelden "ding dong, daar ben ik... mag ik naar binnen?". Als je vervolgens wordt toegelaten tot website A, wil dat niet zeggen dat je ook automatisch wordt toegelaten tot website B. Het zijn eilandjes, weet je nog? Ook hier zul je je dus weer even moeten aanmelden.
Mijn advies: laat het idee van het onderling delen van sessies compleet varen, want je haalt je een hoop ellende op de hals.
Websites zijn op zichzelf staande eilandjes die niks met elkaar te maken hebben. Het is dan ook niet logisch dat ze sessie-bestanden met elkaar delen. Zelfs al zijn de (eigenaars van de) websites "vriendjes" met elkaar.
Websites zijn losse dingen, allemaal met hun eigen leden. Als je gebruik wilt maken van website A zul je je eerst moeten aanmelden "ding dong, daar ben ik... mag ik naar binnen?". Als je vervolgens wordt toegelaten tot website A, wil dat niet zeggen dat je ook automatisch wordt toegelaten tot website B. Het zijn eilandjes, weet je nog? Ook hier zul je je dus weer even moeten aanmelden.
Mijn advies: laat het idee van het onderling delen van sessies compleet varen, want je haalt je een hoop ellende op de hals.
Gewijzigd op 16/11/2014 12:35:21 door John D
@John D
Als je bij Coolblue inlogt in shop A en je gaat vervolgens naar shop B, ben je dan automatisch in shop B ingelogd? Of gebruik je de gegevens van shop A om in te loggen bij shop B?
Maar goed, ieder moet voor zich weten wat ie doet natuurlijk. Als het websites zijn die een keten vormen valt er wellicht iets voor te zeggen, maar dan nog moet je goed nadenken WAAROM je sessies wilt delen. Websites zijn op zichzelf staande dingen. Je maakt VERSCHILLENDE websites, omdat ze blijkbaar... verschillend zijn! Anders was het wel 1 website geweest nietwaar. Daarom geef ik alleen aan dat je over dit soort dingen heel goed moet nadenken, ook vanuit het oogpunt van usability. Persoonlijk zou ik het zelfs raar en onwenselijk vinden als ik bij shop A een laptop koop en mijn contactgegevens invul, en als ik dan vervolgens naar website B (een shop met dameskleding) surf, dat daar ineens mijn gegevens ook al bekend zijn, terwijl ik me daar nooit heb aangemeld.
Als je bij Coolblue inlogt in shop A en je gaat vervolgens naar shop B, ben je dan automatisch in shop B ingelogd? Of gebruik je de gegevens van shop A om in te loggen bij shop B?
Maar goed, ieder moet voor zich weten wat ie doet natuurlijk. Als het websites zijn die een keten vormen valt er wellicht iets voor te zeggen, maar dan nog moet je goed nadenken WAAROM je sessies wilt delen. Websites zijn op zichzelf staande dingen. Je maakt VERSCHILLENDE websites, omdat ze blijkbaar... verschillend zijn! Anders was het wel 1 website geweest nietwaar. Daarom geef ik alleen aan dat je over dit soort dingen heel goed moet nadenken, ook vanuit het oogpunt van usability. Persoonlijk zou ik het zelfs raar en onwenselijk vinden als ik bij shop A een laptop koop en mijn contactgegevens invul, en als ik dan vervolgens naar website B (een shop met dameskleding) surf, dat daar ineens mijn gegevens ook al bekend zijn, terwijl ik me daar nooit heb aangemeld.
"Anders was het wel 1 website geweest nietwaar". Ozzie, neen, je houdt te krampachtig vast aan je idee. Coolblue heeft er kennelijk voor gekozen om uit reclame, commercieel oogpunt en herkenbaarheid te werken met: laptopshop.nl, tabletcenter.nl, computerstore.nl, videokaartshop.nl, ereaderstore.nl, memoryshop.nl etc. DAAROM verschillende websites (en domeinen) en met name vanwege eenduidig ontwerp, inrichting en herkenbaarheid is het niet raar en onwenselijk dat je contactgegevens op elk van deze "websites" bekend zijn. Het blijft immers de herkenbaarheid van Coolblue. Je koopt duidelijk herkenbaar bij Coolblue. Wellicht heeft TS een dergelijk idee of ontwerp en is je uitgebreide reactie niet op zijn plaats.
Gewijzigd op 16/11/2014 21:10:55 door Aad B
Uiteraard mag je dat vinden, dat is je goed recht. Daarentegen heb ik gelukkig ook recht op mijn mening.
Het is niet erg om je als keten te profileren. Ik zeg alleen dat ik het raar vind als ik inlog op website A mijn gegevens ineens bekend zijn bij website B. Als ik in een winkel mijn gegevens achterlaat, dan verwacht ik niet dat als ik een winkel verder loop dat daar ineens ook mijn gegevens bekend zijn zodra ik kom binnenwandelen. Dat Coolblue zich als keten profileert is prima. Het is prima als ik me bij Coolblue shop A inschrijf en dat ik herkend wordt bij Coolblue shop B op het moment dat ik me daar bewust aanmeld (door in te loggen). Het wordt echter vreemd als ik zomaar uit het niets bij shop B wordt herkend zonder dat ik me daar heb aangemeld.
Maar goed, dit gezegd hebbende... sessie cookies zijn zover ik weet niet uitwisselbaar tussen verschillende domeinen, dus dan zou je sessies moeten gaan overdragen via GET of POST data zoals Ward hierboven al even aanhaalde. Lijkt me niet heel veilig.
Het is niet erg om je als keten te profileren. Ik zeg alleen dat ik het raar vind als ik inlog op website A mijn gegevens ineens bekend zijn bij website B. Als ik in een winkel mijn gegevens achterlaat, dan verwacht ik niet dat als ik een winkel verder loop dat daar ineens ook mijn gegevens bekend zijn zodra ik kom binnenwandelen. Dat Coolblue zich als keten profileert is prima. Het is prima als ik me bij Coolblue shop A inschrijf en dat ik herkend wordt bij Coolblue shop B op het moment dat ik me daar bewust aanmeld (door in te loggen). Het wordt echter vreemd als ik zomaar uit het niets bij shop B wordt herkend zonder dat ik me daar heb aangemeld.
Maar goed, dit gezegd hebbende... sessie cookies zijn zover ik weet niet uitwisselbaar tussen verschillende domeinen, dus dan zou je sessies moeten gaan overdragen via GET of POST data zoals Ward hierboven al even aanhaalde. Lijkt me niet heel veilig.
Misschien kan Etienne zelf uitleggen wat hij precies wil bereiken?
Pas dan weten we of hij voor dit probleem nu een schroevendraaier of een hamer nodig heeft.
Technisch kun je er meerdere kanten mee op. Je kunt je eigen gecentraliseerde public key infrastructure (PKI) of gedecentraliseerd web of trust (WOT) opzetten als een klein netwerk van webservers dat elkaar (deels) vertrouwt. Zolang het geheel op één server draait -- én dat ook te verifiëren is!! -- is het niet heel moeilijk.
Pas dan weten we of hij voor dit probleem nu een schroevendraaier of een hamer nodig heeft.
Technisch kun je er meerdere kanten mee op. Je kunt je eigen gecentraliseerde public key infrastructure (PKI) of gedecentraliseerd web of trust (WOT) opzetten als een klein netwerk van webservers dat elkaar (deels) vertrouwt. Zolang het geheel op één server draait -- én dat ook te verifiëren is!! -- is het niet heel moeilijk.
Als het op 1 server draait, kan je toch gewoon 'continue' de cookies van de ene website naar de andere website kopieren?
Dus bij A zijn er servercookies, die kopieer je gewoon naar B.
Wordt pas leuk als iemand uitlogt: dan ben je nog op B ingelogd en die kopieert het terug naar A...
Dus bij A zijn er servercookies, die kopieer je gewoon naar B.
Wordt pas leuk als iemand uitlogt: dan ben je nog op B ingelogd en die kopieert het terug naar A...
Dan wissel je niet continue cookies uit, maar slechts een sleutel bij overschakelen van A naar B of terug van B naar A. De data zelf sla je afgeschermd op in de gedeelde database; de sleutel geeft er toegang toe.
Daarom is dit systeem ook niet ongevaarlijk: de sleutel kan in verkeerde handen vallen. Daarom zou ik bewezen technieken voor het uitwisselen van die sleutel gebruiken die dicht aanliggen tegen PKI of WOT.
Daarom is dit systeem ook niet ongevaarlijk: de sleutel kan in verkeerde handen vallen. Daarom zou ik bewezen technieken voor het uitwisselen van die sleutel gebruiken die dicht aanliggen tegen PKI of WOT.




