Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: serwer proxy, ssl, https, sesja
Forum PHP.pl > Forum > PHP
filka
Witam wszystkich
Szukam już jakiś czas i trochę podobnych tematów znalazłem, ale całościowo nie jest to chyba omówione, więc może ktoś bardziej doświadczony pomoże w rozwiązaniu takiego problemu:
Próbuję postawić na bezpłatnym hostingu niekomercyjny serwis, na localhoście mi to nawet chodziło, a po wrzuceniu na zdalny pojawił sie problem.
znika mi $_SESSION!. A wygląda to tak:
na ty hostingu https realizowane jest za pomocą serwera proxy (czyli normalnie URL mam http://www.moja-domena.pl/index.php/, a dla SSL taki https://ssl.jakis-serwer.pl/moja-domena.pl/index.php/).
Logowanie przebiega prawidłowo (z https), po zalogowaniu ustawiam $_SESSION['costam'] i wszystko gra do momentu, kiedy chcę udostępnić podstronę przez http, ale bez wylogowania. $_SESSION['costam'] jest wtedy pusta i nie wyświetla się w związku z tym np. panelu logowania właściwy dla zalogowanego użytkownika. - wskakuje mi panel przeznaczony do logowania. Po powrocie do https (klikając np. w rzeczonym panelu załóż konto) mam znowu dostęp do $_SESSION['costam'] i wszystko na stronie wraca do normy, do czasu aż wychodzę z https, czyli ruch nie idzie przez serwer proxy (ssl.jakis-serwer.pl). Problem sprowadza się więc do tego, żeby uzyskać dostęp do zmiennej $_SESSION['costam'] nie tylko kiedy w pasku przeglądarki mam https://ssl.jakis-serwer.pl/moja-domena.pl/...egisterCustomer, ale też wtedy kiedy mam http://www.moja-domena.pl/index.php?artykul=1
Na podstawie różnych materiałów napisałem coś takiego:

CODE
mysql_connect("localhost", "root", "");
mysql_select_db("sesje_test");

function sesja_open($lokalizacja, $nazwa_sesji) {
return true;
}

function sesja_close() {
return true;
}

function sesja_read($id_sesji) {
$result = mysql_query("SELECT Dane FROM sesje WHERE IDsesji = '$id_sesji';");
$biezacyCzas = time();
if (!mysql_num_rows($result)) {
mysql_query("INSERT INTO sesje (IDsesji, dodano)
VALUES ('$id_sesji', $biezacyCzas);");
return '';
} else { extract(mysql_fetch_array($result), EXRT_PREFIX_ALL, 'sesja');
mysql_query("UPDATE sesion SET dodano = $biezacyCzas
WHERE IDsesji = '$id_sesji';");
return $daneSesji;
}
}

function sesja_write($id_sesji, $data) {
$biezacyCzas = time();
mysql_query("UPDATE sesion SET Dane = '$data', dodano = $biezacyCzas
WHERE IDsesji = $id_sesji';");
return true;
}

function sesja_destroy($id_sesji) {
mysql_query("DELETE FROM sesion WHERE IDsesji = $id_sesji';");
return true;
}

function sesja_gc($czasTrwania) {
$biezacyCzas = time();
mysql_query("DELETE FROM sesion WHERE dodano + $czasTrwania < $biezacyCzas;");
return true;
}

session_set_save_handler("sesja_open", "sesja_close", "sesja_read", "sesja_write", "sesja_destroy", "sesja_gc");

session_start();

$_SESSION['pierwsza'] = 'pierwsza';
print "kawałek tekstu <br />";
$_SESSION['druga'] = 'druga';

print " <br />" . $_SESSION['druga'];

?>


dołożyłem w bazie tabelę

CODE
CREATE TABLE sesje
(ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY, IDsesji CHAR (26),
Dane Text DEFAULT '',
dodano INT);

i w osobnym pliku mi to działa, ale różne próby zastosowania w praktyce się nie powiodły. Będę wdzięczny za wszelkie sugestie, myślę że na ten problem wcześniej czy później natknie się wiele osób, więc rozwiązanie posłuży nie tylko mnie, pozdrawiam Wszystkich.
quality
Hmmm
Troche nie rozumiem tych adresow dla ssl i bez smile.gif

http://www.moja-domena.pl/index.php/, a dla SSL taki https://ssl.jakis-serwer.pl/moja-domena.pl/index.php/).

Z tego co tu jest napisane to masz ssl na zupelnie innej domenie :/ ? Wiec niby jak sesja ma ci przejsc na inna domene ?
Problem lezy wlasnie w ustawieniu ciasteczek sesyjnych.

Nie wiem do konca jak to jest z samym https:// i http://, ale przy http://moja-strona.pl i http://ssl.mojastrona.pl to ciasteczko sesyjne musisz miec ustawione na ".moja-domena.pl", wtedy ciasteczko przechodzi rowniez na subdomeny. Sadze ze wlasnie w tym jest problem smile.gif
filka
Dzięki quality
szperałem w różnych miejscach i jak na razie wnioski mam takie:
setcookie() pozwala ustawić w swoim piątym parametrze domenę w taki sposób:
CODE
setcookie('nazwa', 'wartość', '', '', '.moja_domena.pl');
tylko nie wiem czy można coś takiego zastosować dla cookies sesyjnych, a jeżeli to jak?
Jakby się to dało zrobić to powinienem otrzymywać ciasteczka tak na http://www.moja-domena.pl/ jak i na https://ssl.jakis-serwer.pl/moja-domena.pl/ , tak przynajmniej rozumiem czytając materiały na ten temat. Tylko że raczej niewiele to zmieni, bo dane sesji i tak będą na https://ssl.jakis-serwer.pl, i nie dojdę do nich będąc na http://www.moja-domena.pl/. Ten kod który podałem wcześniej z session_set_save_handler() pozwala skierować dane sesyjne do bazy danych albo do pliku w podanej lokalizacji. Może to być dobre wyjście, choć rozwiązanie z bazą ponoć źle wpływa na wydajność. Z moją wiedza na ten temat na razie się za to nie zabieram, mam natomiast taką koncepcję:
przechodząc na http://www.moja-domena.pl/ przekażę w url-u dane sesji (wiem, niezalecane ze względów bezpieczeństwa, docelowo tego tak nie zostawię) następnie normalnie ustawię nową sesję i zobaczę czy to zadziała. Pozostaje problem jak potem posprzątać sesje na obydwu serwerach jednocześnie, czuję że obrośnie mi to sporą ilością kodu i czy zadziała? - dlatego staram się wcześniej przemyśleć różne możliwości. Zapraszam do dalszej dyskusji, na pewno jest jakiś optymalny sposób, przecież takich rozwiązań że połączenie SSL jest realizowane przez serwer proxy jest w necie dużo, jakoś sobie ludzie radzą. Pozdrawiam Wszystkich.
Zyx
To ma być szyfrowane połączenie? Ale żeś patent opracował - normalnie na Ig Nobla się nadaje, albo coś w tym stylu smile.gif. Co z tego, że masz szyfrowane połączenie do serwera proxy, skoro później te same dane lecą nieszyfrowanym kanałem między proxy, a właściwym serwerem? Szkoda Twojego czasu na implementowanie czegoś, co i tak nie będzie działać tak, jak chcesz by działało.
filka
Nobel jest Nobel, czuję się nominowany, hehe – ale ważniejsze to co piszesz dalej, że potem pomiędzy proxy a właściwym serwerem nie mam szyfrowania. Pełna zgoda, tylko skoro chcę część podstron udostępnić z SSL a część bez (dla tego samego zalogowanego usera) to tak czy inaczej w pewnym momencie dane pójdą nieszyfrowane. Przekonuje mnie po prostu teza że SSL obciąża serwer i łącza, ale nigdy w to dokładniej nie wnikałem jak bardzo, może to mit z przeszłości i przy wzroście tych parametrów nie warto wyrzucać usera z połączenia szyfrowanego, żeby trochę przyoszczędzić? To pierwsza kwestia, a właściwie prośba o wasze opinie.

Nadal moje podstawowe pytanie brzmi jak: widzieć sesje za proxy, podczas gdy wygląda na to, że dane sesji są zapisane na proxy. Fajnie by było jakby ktoś się wypowiedział w pierwszej kwestii, może moje wysiłki są nie warte zachodu, czyli: zostawić usera po zalogowaniu cały czas na SSL, a jak się wyloguje przechodzę na nieszyfrowane połączenie – wtedy problem nie istnieje. Co do mojego karkołomnego pomysłu z dwoma sesjami to nie wiem czy w ogóle wykonalny, ale na razie tego nie sprawdzę, bo wczoraj przekopałem trochę materiałów na forum i jednak spróbuję zapisywać sesje w bazie danych. Na moim etapie ewentualne spowolnienie z tego powodu nie ma aż takiego znaczenia, ważne żeby działało i nie stanowiło poważnej luki w bezpieczeństwie. Na Forum znalazłem dużo gotowych rozwiązań z wykorzystaniem session_set_save_handler(), czas przejść do konkretów. Myślę że wkrótce zamelduję o problemach jakie pewnie wynikną. Ważne żeby w sensownym czasie dojść do jakiegoś rozwiązania, dlatego czekam na wasze wypowiedzi i sugestie, Pozdro.
Zyx
Pierwsza kwestia: ja bym zostawił. Taki GMail całą transmisję ma opartą o SSL i działa bez problemów. Strony internetowe banków również.

Druga kwestia: jakbyś miał normalny SSL, to przynajmniej hasło nie szłoby jawnym tekstem, a u Ciebie nie idzie w sposób szyfrowany NIC. Nieważne czy sobie cały portal zaSSLujesz, czy tylko strony logowania - wszystkie, wszystkie, WSZYSTKIE, każdy bajt informacji, jaki prześlesz, pójdzie jawnym tekstem między właściwym serwerem, a proxy i ten SSL nie da Ci absolutnie nic. Równie dobrze mógłbyś dywagować, czy lepiej jest na podróż kupić benzynę E95 czy E98 do samochodu, który nie ma silnika... Prawda jest taka, że do baku możesz mu nawet zupę jarzynową wlać i dalej będziesz w tym samym miejscu. Tak samo jest z Twoim SSL-em.
filka
Hmm ... z pewna dozą ostrożności jestem skłonny tak zrobić jak piszesz Zyx– trzeba by tylko obserwować wykorzystanie transferu i jakby za szybko nabijało licznik wtedy wrócić do sprawy. Odpadło by trochę roboty. Ale żeby trochę skorzystać z wiedzy tych którzy znajdą czas i chęci, pociągnę temat, może kiedyś komuś lub mnie ta wiedza się przyda.

Kwestia druga: wszystkie 3 przyjmuję, przykład bardzo przekonywujący. Jak to z analogiami bywa, sprawdzają się czasem w 100%, czasem trochę mniej. Mianowicie np. klikając link „załóż konto” (mowa o tym nad czym pracuję) mam przekierowanie na stronę zakładania konta, która jest już przesyłana przez https. (czyli idzie przez proxy mający SSL).Dane z formularza też są szyfrowane – cały czas jestem w https. Po zweryfikowaniu danych zapisuje co trzeba do bazy, ustawiam zmienną sesyjną i następuje przekierowanie na stronę główną z odpowiednimi parametrami w url-u. Te parametry wraz z z zawartością sesji decydują o tym co wyświetlić userowi, i czy utrzymać https, czy w tym momencie odesłać mu stronę przez http. Wychodzi mi że jeszcze w tym momencie silnik jest, czyli ważne jest co wleje, bo na zupie raczej nie pohula. Jeżeli odeślę mu stronę przez http, to od tego momentu zgoda, wszystko idzie bez szyfrowania.

No i taki przypadek weźmy pod lupę. Teraz jakbym ustawił nową sesję (bo ta na proxy wprawdzie istnieje, ale nie mam w tym momencie do niej dostępu) zapisując w niej to samo co w tej na proxy (jak bym to chciał zrobić będzie poniżej), miałbym co trzeba żeby wyświetlać opcje przewidziane dla zalogowanego użytkownika . Teraz user mogłby robić na stronie różne rzeczy, które są dostępne dla każdego, niezalogowanego, ale miałby też możliwość wybrania opcji dla zalogowanego. Takie żądanie wychodziło by od klienta jako http, i musiało by zawierać identyfikator, który pozwolił by zidentyfikować użytkownika, żeby to miało sens. No i jak tego dokonać?

Po zalogowaniu mam w zmiennej ID_usera. Robiąc w tym momencie przekierowanie (to by było jeszcze na proxy, czyli mam jeszcze https) mógłbym przekazać przez GET ID_usera. Jasna sprawa że warto by go zaszyfrować, choć tak naprawdę to się nie pojawi w pasku przeglądarki, bo w głównym skrypcie dopiero następuje przekierowanie na http. I teraz dopiero strona jest odsyłana do klienta z nowym ciasteczkiem nowej sesji, w której to sesji mam (zaszyfrowany) ID_usera, a URL jest skonstruowany od nowa i nie ma już w nim nic, czego nie powinno być.

Czyli nie mam połączenia szyfrowanego, ale też nie mam żadnych informacji poufnych, które bezpośrednio mogły by być wykorzystane w momencie przechwycenia.

Jak już wspomniałem pewnie tego nie zrobię, ale co mi szkodzi pomyśleć nad problemem, skoro już i tak nad tym siedzę. Może choć trochę sensu w tym jest, wytykanie błędów i dalsze uwagi mile widziane. Co nas nie zabije to nas wzmocni. Pozdro.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.