Być może to będzie dla wielu proste, ale mi moja kreatywność sie skończyła gdy nie znalazłem nic w Google, manualu i na forum...

Sprawa wygląda następująco..

Jest sobie zwyczajny, ładnie ostylowany formularz logowania z polem login i hasło. No i powiedzmy tyle tego co musi być

Dotychczas wykorzystywałem mechanizm sesji - i tu nie mam nic przeciwko, ale muszę dodatkowo dodać autoryzacje a konkretnie to zapamiętywanie że ktoś sie zalogował, ale tak by to przetrzymać w tym mechanizmie autoryzacji WWW.

[PHP] pobierz, plaintext 
<?php
 
$login = "admin"; // tu wpisz swój login
$password = "pass"; // a tu swoje hasło
 
?
?
?
 
if( !isset($_SERVER['PHP_AUTH_USER']) or strcmp($_SERVER['PHP_AUTH_USER'],$login) or strcmp($_SERVER['PHP_AUTH_PW'],$password) ) {
   // Formulaz logowania
} else {
   // User sie zalogowal i różne rzeczy sie dzieją..
}
 
?>
[PHP] pobierz, plaintext 

No i powiedzmy że tak to mniej więcej powinno działać. Ale nie chcę ani wyskakującego okienka autoryzacyjnego.
Wiem że da się to zrobić - ale niestety jak zwykle nie wiem jak.

Z góry dzięki za pomoc!

Ok może coś nie tak wyjaśniłem.
Muszę przekazać informacje o użytkowniku między różnymi domenami (nie subdomenami).

Proces wygląda następująco,
1. Użytkownik loguje się na stronie A (np. jakas-domena.pl), system zapamiętuje go w sesji, a identyfikator tej sesji przechowuje w ciasteczku.
2. Muszę połączyć się z serwera B (np. jakas-inna-domena.pl), do serwera A i odebrać informacje o użytkowniku (jak jest nie zalogowany to nic nie odczyta ).

Tak mniej więcej w praktyce. Chciałem to zrobić na ciasteczku (odwoływać się do jakiegoś skryptu który w JavaScript lub XML udostępni jakieś informacje o właśnie tym zalogowanym użytkowniku) ale niestety to nie działa w IE.

Śledząc inne strony w tym google, facebook i twitter - zauważyłem że wykorzystują m.in. mechanizm autoryzacji www - no chyba że się mylę.

W przypadku bodajże twitter'a, jeśli np. na jakiejś stronie jest skrypt JS i odczyta info o tym że ktoś się zalogował w twitter może wyświetlić okienko - strona wykryła że jesteś zalogowany na twitterze (i tam dalsza część komunikatu).

Albo gdy zaloguję się na google.pl to automatycznie jestem zalogowany na google.com, google.de i wielu innych...


PS. Okienko autoryzacji WWW - to nic innego jak te które wywołuje jeden z tych nagłówków:
header('WWW-Authenticate: Basic realm="My Realm"');
header('HTTP/1.0 401 Unauthorized');

...i tego chcę uniknąć - bo chce mieć ładne okienko logowania które jest osadzone i ostylowane (CSS) na stronie...

Mam nadzieję że teraz chyba wyjaśniłem mój problem lepiej..

Będę wdzięczny za każdą nawet drobną sugestie..

nie wiem jak chcesz przechodzić na drugą stronę ale pomysł tak na szybciutko biegiem na podtrzymanie sesji to:

• przekazujesz informacje potrzebne sesji z serwera A do serwera B (oczywiście wyślij to jakoś zabezpieczone i ten serwer B niech wie, że to na pewno serwer A coby czasem ktoś się nie podszył - tutaj komunikacja serwer serwer)
• gdy już przekażesz wszystkie informacje o sesji do drugiego serwera (identyfikator oraz dane sesji jakiekolwiek miałeś zapisane bądź jakie są potrzebne) przejście z serwera A do B robisz albo przez podanie specjalnego linku i identyfikacją sesji w parametrze get (lub jeśli automatycznie to przekierowanie z tym specjalnym linkiem) albo przez formularz z ukrytym polem identyfikacyjnym sesji
• na serwerze B odbierasz informacje i parametr identyfikacyjny, w danych sesji sprawdzasz, czy gostek się nie podszywa itp... jeśli chcesz sesje trzymać w ciasteczku tworzysz je na tym serwerze B i linki będą "normalne"

ten sposób wykorzystywałem już, ale mówiąc szczerze nie sprawdza się.
Nie chcę do serwera B przekazywać za wiele informacji, a "odchudzanie" danych w sesji było by dość kłopotliwe...

Stąd właśnie pomysł by to oprzeć na autoryzacji HTTP. Dzięki temu - można w prosty sposób wiele rzeczy sobie uprościć i na pewno zadziała w każdej znanej przeglądarce...

Po kilku próbach i śledzenia zmiennych systemowych i nagłówków znalazłem kilka może ciekawych rzeczy które może nakierują kogoś na właściwy trop.

Po poprawnej autoryzacji pojawiają się 2 zmienne, w których są podane dane o loginie i haśle: $_SERVER['PHP_AUTH_USER'] i $_SERVER['PHP_AUTH_PW']

Wywnioskowałem iż te informacje są zapamiętane przez przeglądarkę, a wysłane w postaci "zapamiętanego" nagłówka o takiej treści: "Authorization: Basic YWRtaW46cGFzcw=="

Kod: YWRtaW46cGFzcw== to nic innego jak "zahaszowana" informacja za pomocą base64_encode, w następującej składni base64_encode( $login . ':' . $password )

I tu jest taki problem że tyle wiem napewno - bo do takich informacji dotarłem przez Wujka G.,

niestety nie potrafię zrobić by przeglądarka zapamiętała tę informację. Próbowałem podstawiać nagłówek: header('Authorization: Basic '. base64_encode( $login . ':' . $password ) ); ale nic to nie dało.

Czy ma ktoś wobec tego jakiś pomysł?

jest coś jeszcze. Po autoryzacji z okienka autoryzacji http, pojawia się wspomniana zmienna w sekcji: HTTP Request Headers - po wpisaniu phpinfo(), ale gdy taką samą zmienną wysyłam za pomocą header(..), pojawia się w sekcji: HTTP Response Headers

Nie wiem czy jest ktoś w stanie pomóc. Ja powoli wymiękam, a to mi się bardzo rzadko zdarza...

gdyż za przeproszeniem szukasz dziury w całym ;D... ale szkoda słów...

gdybyś miał to na jednym serwerze a inna domena to wystarczylo by tylko przekazać identyfikacje sesji - jak masz na różnych serwerach i nie pasuje Ci powyższe to szukaj, może coś "nowego" wymodzisz - jakby co daj znać gdyż każdy nowinek będzie ciekaw [czytaj mój podpis ]

spoko
może ktoś sie jeszcze znajdzie :-)

hmmm... nie wiem czy do końca zrozumiałem, ale zakładam, że sytuacja jest taka

: masz 1 serwer z domeną A
: masz 2 serwer z domeną B

Logujesz się w A.

Wchodząc na B chcesz wiedzieć czy zalogował się w A.

Jeśli tak to mówisz o technice single sign on czyli po polsku technika pojedynczego logowania.

po wpisaniu w google znalazłem kilka artykułów na ten temat. Między innymi takie gotowe rozwiązanie:

https://support.zendesk.com/entries/25662-s...sign-on-for-php

Połącz to z cookies gdzie możesz zapisać cookies wskazując domenę i myślę ze może to być to o co Tobie chodzi.

Pozdrawiam,
Dominik

Cookie można nadać dla domeny w tym przypadku A.

Serwer A nie może przypisać ciasteczka domenie B.

Ale uwaga, śledziłem i wynalazłem takie coś: http://www.peej.co.uk/sandbox/htmlhttpauth/

Zobaczę też te Single Sign-On i zobacze o co w tym kaman

i nie może i może - ale skoro nie chcesz przesyłać sesji do serwera b to jest "kupa" za przeproszeniem...

mógłbyś zrobić tak jak pisałem wyżej + jeśli nie chcesz przekierowywać lub robić linków a żeby użytkownik nie wiedział, że na Twoim drugim serwie jest logowany (bo że est zalogowany dowie się po wejściu tam) możesz na stronie np. dać obrazek z serwera b z odpowiednim adresem z parametrami get (lub inny pliczek czy to css czy javascript) - oczywiście musisz to wysłać skryptem -> wysyłając taki pliczek możesz od razu ustawić cookies dla serwera b na serwerze b analizując adres tego obrazka (parametry get bo tak najprościej)

ale nie wiem jakim cudem coś takiego chcesz osiągnąć skoro Ty upierasz się, by serwer B nie wiedział nic o istnieniu serwera A i nie zamierzasz przesyłać między serwerami jednorazowo podstawowych danych sesyjnych (przyrównał bym to do sytuacji jakbyś od znajomego wymagał, by czytał Ci w myślach o.0 -> "przyślę Ci gościa do pracy, wpuście go przez furtkę" [tak pomyślałeś] -> "przecież Ci mówiłem!!!" -> "kiedy?? o.0 )

no ale może na coś nowego wpadniesz... jednak dalej uważam, że szukasz dziury w całym ;D

twoje rozwiązanie nie zadziała w internet explorer, za długo to drążę bym o takich sposobach nie wiedział

nie mogę zmuszać kogoś do np. kliknięcia i przejścia ze strony A jakimś tam linkiem na stronę B.

To ma w zamyśle działać tak, że klient loguje się na stronie A...

W google znajduje przypadkowo stronę B która posiada mój kod. Kod ze strony B łaczy się z serwerem A, za pomocą Ajax'a i sprawdza stan czy ta osoba jest zalogowana. Jeśli tak to odbiera pakiet ważnych informacji potrzebnych do zidentyfikowania klienta.

Tu sprawdza czy klient jest w bazie strony B, jeśli go tam nie ma - wyskakuje komunikat: Strona wykryła że jesteś zalogowany na stronie A (tu jakiś adres np. www.cos.pl), czy chcesz przepisać dane i dokonać automatycznej rejestracji? <tak> <nie>


Nie wiem jak to prościej wyjaśnić...

To ma być dla ludzi proste i przyjemne, a nie trudne i wymagające jakiś działań...

więc napisz dlaczego?? skoro IE tutaj nie ma nic do gadania gdyż wszystko robisz po stronie serwera??

hehe -> nawet nie przeczytałeś mojego posta jak widzę ^^

Więc przypomnę, że taką funkcjonalność będziesz miał dopiero w HTML5 ;D - AJAX nie może odbierać danych między różnymi domenami... jednak jest rozwiązanie i nazywa się DHTML [no tu np. możesz załączyć pliczek js. z domeny A z jakąś zmienną, po czym sprawdzasz czy wynik jest true czy false - do js pasuje dać jeszcze timestap coby nie byl keszowany w przeglądarce przy następnym zapytaniu)... ALE PYTANIE PO CO!!! -> ALE WCZEŚNIEJ PISAŁEŚ TEŻ O CZYM INNYM - O LOGOWANIU DO 2 DOMEN NIEMAL W TYM SAMYM CZASIE!!!

przed tym cytatem do takiej sytuacji dałem rozwiązanie -> DHTML - bo z ramek z innych domen też już nie da się czytać zawartości przez javascript...

A jeśli dalej myślisz o automatycznym logowaniu na obu serwerach to co od użytkownika wymaga dodatkowych działań jeśli on nic nie robi poza logowaniem się na jednym serwerze?? skoro nic nie musi klikać przecież pisałem, że zamiast specjalnego linku to do strony załączyć plik (obrazek, styl css, lub pliczek js) z serwera B ze specjalnym adresem po rozpoznaniu którego serwer B wysyłając pliczek do przeglądarki ustawia cookies dla serwera B (ale ten pliczek musisz wysłać skryptem /* EDIT - skryptem z serwera czy programem a nie skryptem javascript */)

nie wiem, ale myślałem, że to co napisałem bardziej łopatologicznie nie da się napisać, ale skoro nawet nie czytasz...

o tym ajax to przekombinowałem. chodziło mi o przekazanie zwykłego js ze zmiennymi - co innego myślałem, co innego napisałem....

Mówiąc szczerze nie było by problemu gdyby to były tylko 2 serwery ;/

Jak do tej pory pod opieką jest ponad 100 innych stron (sklepów internetowych, czyli wiele serwerów i nie mogę każdego wrzucać na serwer A by wyczytywał jakiś tam pliczek - dlatego to odpada...

Ale doszliśmy do porozumienia, że serwer A jest tutaj kluczowy?? coś jak serwer "matka"??

Informacji potrzebujesz tylko w kluczowych sytuacjach... jak dla mnie najwygodniej będzie tak jak napomniałem poprzez DHTML (duży minus, iż nie zadziała przy wyłączonym javascript)...

jak ja to widzę... zacznijmy od tego, że akurat ten jeden przynajmniej skrypt nie może być buforowany (najprostsze rozwiązanie to dorzucić do get jeszcze timestap co sprawi, iż link zawsze będzie inny)

na serwerze A masz jakiś pliczek generowany dynamicznie tak jak stronę [proponuję ten adres przepisać w .htaccess coby końcówka wyglądała na *.js a nie *.php) - po stronie serwera nie problem sprawdzić, czy zalogowany czy nie na podstawie identyfikatora sesji będącego w cookies serwera A...
więc generujesz na serwerze B:
http://serwerA/sprawdz_delikwenta.js?timestap=1283423243bleble [timestap do niczego Ci nie służy ]

ten pliczek jest załączany na stronie wygenerowanej z serwera B i skryptami javascripti sprawdzasz wynik [w powyższym skrypcie przesyłasz informacje jawne potrzebne do dalszego transferu danych jeśli jest zalogowane takie jak np. nick]....

i dalej skryptami js robisz swoje wyświetlając zapytania i inne odpytując serwer A i serwer B przez DHTML...

gdy już jest potwierdzone, że uzy_szkodnik chce zaimportować konto coby to było bezpieczniejsze (a nie ktoś się podszył) przy imporcie danych na serwer B z serwera A [komunikacja bezpośrednia pomijając przeglądarkę] pobierz także podstawowe dane sesji jak np. nagłówki samej przeglądarki oraz IP i jeśli się różnią to danych zaimportowanych nie wykorzystujesz, jeśli potwierdziłeś zgodność kończysz importowanie (to tylko algorytm taki daję)

jest jeszcze rozwiązanie (algorytm) na zrobienie tego bez javascript jednak chyba nie ma co o nim pisać bo były by z 2 redirekty (niby też nie trzeba by nic klikać) - ale sama idea jest podobna jak ta co opisałem powyżej...

[edit] w pliku js możesz jeszcze dla zalogowanego uzyszkodnika podać jako jedną z wartości zmiennych identyfikator sesji z serwera A jako kolejny np. czynnik "identyfikujący" - źle nazwane - to wysylając dane z serwera A do B przy komunikacji bezpośredniej mając to podajesz dane osoby z tym identyfikatorem sesji (tą wartość przy wysyłaniu informacji na serwerze A sprawdzić możesz jako ciągłość sesji, a na serwerze B porównać pozostałe czy czasem jakimś sposobem passkeya nie skopiowali)...

Ogólnie rzecz biorąc to się rozumiemy.

Tyle że aby serwer A rozpoznał tego właśnie użytkownika, a w tym wypadku musiał by odczytać ciasteczko (z identyfikatorem sesji) musiał by być wywołany z serwera A. Internet Explorer nie przekaże ciasteczka z serwera B.

Ale to tylko 48% użytkowników jakich korzysta z IE więc chyba tymczasowo właśnie tak to zrobię...a potem jak wymyślę coś lepszego to zmienię..

hmmm.... jednej rzeczy nie mogę teraz sprawdzić gdyż pod ręką nie mam IE, ale...

TAK - ciasteczko na pewno nie będzie widoczne między domenami... jednak....

jeśli plik/skrypt czy cokolwiek zostanie wywołane na serwerze A powinien mieć dostęp do ciasteczek z serwera A... więc tutaj dane dopiero po stronie serwera A wygenerowałbyś te co potrzebujesz a nie po stronie B...

uogólnię pytanie...
czy jeśli skrypt jest wywoływany z innej domeny to na pewno na serwerze A [podkreślam na serwerze A] nie będą dostępne ciasteczka z serwera A?? gdy IE wykona zapytanie??...

jeśli nie to podam zaraz algorytm na to odporny i działający także bez javascript jednak będą 2 redirekty w między czasie...

[EDIT]
sprawdź przy wczytywaniu pliku js z domeny A (gdzie adres do źródła będziesz mial na stronie wygenerowanej na domenie za pomocą np. tego narzędzia:
ieHTTPHeaders lub za pomocą skryptu js generowanego dynamicznie po stronie serwera a w treści skryptu/źródła na sztywno wpisane/wygenerowane nagłówki jakie dotarły do serwera A czyli:
alert(<?php echo $naglowki;?>);

o ja će miszczu jesteś - ukłony!

szukałem i googlowałem i na myśl mi nie przyszło by skorzystać z czegoś w tym stylu. Pamiętam że gdy IE miał problemy z przezroczystością w PNG to podobnie sprawę załatwiłem - znalazłem jakiś "pacz" który pomógł IE poakazać poprawnie obrazek...

dlatego od drugiego mojego postu pisalem, że chyba się nie rozumiemy ;p - podobnie wspominałem o przekazaniu ciągłości sesji przez same obrazki gdy pisałeś, że są tylko 2 serwery i na obu konta... tylko wtedy adres spreparowany i w między czasie komunikacja serwer - serwer bez przeglądarki (a też nie obrazki na każdej stronie tylko w kluczowych momentach podobnie jak z tym javascript)...

cookies na tej samej domenie są zawsze dostępne i mnie zaskoczyłeś pisząc, iż IE coś takiego blokuje - a to co ja pisałem to już jawnie przesylałeś pewne informacje...

stąd pomysł by wykorzystać autoryzacje http - to nie jest blokowane przez żadną przeglądarkę...

ale w końcu cookies z serwera A nie sa wysyłane w IE na serwer A?? - bo po tym poście to już Cię wogóle nie rozumię - jak nie to mogę opisać jak to na redirektach zrobić i na 99% cookies wtedy nie będą zablokowane...

Test dotyczący ciasteczek wykonałem w następujący sposób.

1. Serwer A zapisuje ciasteczko do przeglądarki i tylko on może go odczytać (co jest oczywiste).
2. Na serwerze A zrobiłem prosty skrypt który sprawdza czy ciacho istnieje, po czym wypisuje w php informacje

[PHP] pobierz, plaintext 
<?php
   if( isset($_COOKIE['a']) {
      echo 'document.write("ciacho da sie odczytać"); ';
   } else {
      echo  'document.write("ciacho jest niedostępne"); ';
   }
?>
[PHP] pobierz, plaintext 

3. Na serwerze B wykonuję dokument html. Ma za zadanie sprawdzić czy z innego adresu (czyli serwer , serwer A odczyta ciasteczko (bo wywołuje adres "w tle" inny serwer niż A, czyli :

[HTML] pobierz, plaintext 
<script type="text/javascript" src="http://serwer-A.pl/skrypt.sprawdzajacy.php"></script>
[HTML] pobierz, plaintext 

..

Reasumując, następujące przeglądarki: FireFox, Opera, Chrome, Safari przekazały ciasteczko i można było je odczytać.

Przeglądarka Internet Explorer (v. 6, 7, 8) sobie z tym zadaniem nie poradziła

PS. Autoryzacja HTTP tu masz info co to i po co i na co...: http://php.net/manual/pl/features.http-auth.php

ok. nagłówki wiem z czym się je ;p

nie miłe zaskoczenie ;/ ^^
hmmm... zrób podobny test z samym IE ale na redirect... a dokładniej [bo potrzebujesz to na stronie tylko rejestracji czy logowania] na określonej stronie robisz przekierowanie do serwera A... zrób przekierowanie na specjalnie do tego przygotowaną stronę ze skryptem i wyświetl tam informacje o ciasteczku... jeśli tutaj IE nie będzie robiło udziwnień to w drugim etapie zrobisz z tej specjalnej strony przekierowanie z powrotem na serwer B z dodatkowymi parametrami get czy zalogowany, jeśli zalogowany to inne parametry get informacyjne w adresie redirekta... jeśli nie zalogowany zwrot na tą samą stronę z jakimś też parametrem po rozpoznaniu którego będziesz wiedział, że już sprawdzałeś [nie przekierowywać] i że nie zalogowany tam...

przy tych cookies to dziwne zachowanie ale może przy redirekcie się "normalnie" IE zachowa - bo to prawie jak przejście linkiem do innego serwisu...

[edit]
i napisz wynik czy IE dalej blokuje ciasteczka z serwera A na serwerze A

tu z kolei google powie że nie widzi strony - robiłem już tak kiedyś z przekierowniem...

heh - fajne wyzwanie choć nie mam czasu do testów dzisiaj i na tym laptopie nie mam niestety IE... niżej "drobne przemyślenie"...

co do JavaScript od wielu lat czyta się na serwisach kontrowersje z bezpieczeństwem -> może stąd takie ograniczenie (moim zdaniem niepoprawne) w IE...

idąc dalej... tu miałem napomnieć o pewnym sposobie przekazania informacji przez css lub obrazki z serwera B do A i odpowiedzi, ale były by mało wystarczające nawet jeśli tutaj do tych danych cookies nie są blokowane...

dalej... jak już wspomniałem, z iframe już [tak - już gdyż daaaawno temu można było z innych domen - teraz tylko tak jak AJAX] nie można odczytać informacji poprzez javascript... jednak... jednak powinno być zdarzenie onload i... do czego zmierzam... korzystając z DHTML'a zrób ramkę z adresem do specjalnej strony na serwie A... adres z getem sesji w B [to będzie konieczne do odpowiedzi]...

jeśli iframe dzięki odizolowaniu nie blokuje cookies w IE na otwartej stronie w PHP będziesz mial dostęp do identyfikatora sesji... w kodzie z serwera A (iframe) html dajesz 1 pikselowy obrazek lub inny element (js bądź css) ze specjalnym adresem do serwera B gdzie w get identyfikacja sesji celem podtrzymania, oraz dodatkowe potrzebne informacje w get jak czy zalogowany i jeśli to nick itd... na serwie B przy próbie wyslania wywolanego pliku w ramce mając w parametrze identyfikator sesji zapisujesz w tej sesji te dodatkowe informacje już na serwerze B... gdy odeślesz plik z serwera B do ramki bedzie zdarzenie onload.... i teraz w skrypcie ze strony B odpytać odpowiednią stronę na serwerze już B z sesji, mając informacje już komunikacja serwer-serwer przy transferze konta...

ale to dosyć mocno okrężna droga...

w pierwszej kolejności sprawdź w samym iframe czy cookies w IE zostanie wyświetlone -> czyli na stronie serwera B wyświetl DUUUŻE iframe (którego adres jest serwer A) przy testach bez kombinowania by wizualnie odczytać kod html informujący, czy jest tam cookies czy nie...

[added]
PS.
przecież redirekta z domeny B na A możesz zrobić w JavaScript a nie przez nagłówki...

kolejna rzecz to komunikacją omijającą przeglądarkę serwerB - serwerA możesz wykonać zapytanie o użytkowników z tym samym IP i tym samym nagłówkiem przeglądarki którzy są zalogowani - jeśli znajdziesz jednego lub więcej zalogowanych o tym samym IP i tej samej przeglądarce to dopiero wtedy możesz zrobić redirekta (a jeśli zamierzasz to mieć dostępne na każdej stronie, to coby serwery się nie odpytywały co chwila po prostu w sesji na serwerzeB zapisz, czy wykonałeś sprawdzenie danego klienta - jeśli tak to nie sprawdzasz go)...