Mamy stronę główną pod adresem example.com
. Logowanie się example.com/admin
tam działa dobrze.
Ale na stronie testowej pod adresem test.example.com/admin
nie mogę zalogować się do administratora bez uprzedniego usunięcia wszystkich example.com
plików cookie. Następnie mogę się zalogować, ale jak tylko zaloguję się do example.com/admin
mojego następnego kliknięcia, serwer testowy powoduje powrót do strony logowania.
Nie wiem, czy to wpływa na logowanie klientów.
Czy w głównej witrynie lub w witrynie testowej jest jakaś konfiguracja, która rozwiązałaby ten problem?
magento-1.9
admin
login
cookie
Buttle Butkus
źródło
źródło
.
Ważna jest tylko uwaga: krok 3 dotyczący przedniej części domeny!example.com
adminie,test.example.com
adminie, czy w obu przypadkach?example.com
, drugitest.example.com
. Obaj mają własnych administratorów. Ale mówisz mi tylko, aby ustawić domenę dla jednego z administratorów. Mówisz, że powinienem zostawić drugą pustą?test.example.com
i w głównym sklepie,www.example.com
aby uniknąć nakładania się plików cookie.Anna podaje kilka dobrych punktów, a jej odpowiedź zadziała dla wielu osób, ale nie dla mnie, więc zamieszczam własną odpowiedź. Być może mój problem był o wiele bardziej fundamentalny niż ten, do którego się odnosi.
Moim rozwiązaniem była zmiana domeny mojej witryny z
example.com
nawww.example.com
. W rzeczywistości moje badania w Internecie sugerują, że powód, dla którego witryny takie jak Amazon, Google, Ebay i każde inne główne miejsce docelowe sieci używająwww
prefiksu, może być w dużej mierze spowodowane sposobem działania plików cookie. Może nie.Domyślny sposób działania pliku cookie polega na tym, że dotyczy wszystkich subdomen. Jeśli więc
example.com
wyśle Ci plik cookie, a następnie odwiedziszmail.example.com
,smile.example.com
lubdevsite.example.com
Twoja przeglądarka wyśle ten plik cookie do tych witryn, a strony te spróbują je wykorzystać. Ale nie będą w stanie znaleźć Twojej sesji, chyba że wszyscy użyją wspólnego folderu sesji. I nawet wtedy prawdopodobnie będziesz mieć problemy z powodu różnych konfiguracji bazy danych, różnych struktur aplikacji itp.Dokonanie zmiany polegało na utworzeniu przekierowań 301 w moim głównym pliku htaccess, zmianie bezpiecznych / niepewnych adresów URL w
core_config_data
tabeli bazy danych magento , zmianie stronyServerName
w ApacheVirtualHosts
i aktualizacji ustawień DNS / nameserver. Ale było warto.Tworząc moją główną stronę
www.example.com
, jej pliki cookie miałyby teraz zastosowanie tylko do jej subdomen, takich jakmail.www.example.com
(i nie mamy takich subdomen). Przeglądarki klienckie, które pobierająwww.example.com
plik cookie, nie wysyłają godevsite.example.com
, a problem został rozwiązany. Ponadto naprawdę miło jest miećwww
przed naszą nazwą domeny.źródło
Możesz po prostu zmienić nazwę pliku cookie adminhtml dla subdomen.
Dwie zmiany w pliku
app/code/core/Mage/Core/Controller/Varien/Action.php
.W
preDispatch
wierszach zmiany funkcjido
W
setRedirectWithCookieCheck
zmianie funkcjido
A potem wyszukaj tekst
we wszystkich plikach i zamień go na
jeśli jakieś zdarzenia zostaną znalezione.
źródło
adminhtml
domeny.example.com
. Podczas próby zezwolić na test.example.com/admin, próbuje coś zrobić z cookieadminhtml
dla.test.example.com
. Problemy różnią się w ustawieniach Magento. Głównym problemem jest to, że nie można modyfikować plików cookie domeny głównej z subdomeny. Powyższy kod powoduje, że Magento tworzy ciasteczkaadminhtml
na przykład.com i ciasteczkaadminhtml_subdomain
dla subdomena.example.com, więc nie będą się w żaden sposób mieszały. Zmieńsubdomain
na właściwy, którego używasz.Jeśli nadal nie możesz zalogować się do interfejsu użytkownika (nie można utworzyć sesji klienta) z powodu problemów z plikami cookie, należy zastąpić odpowiedni plik podstawowy
i
Skomentuj linie wskazane w tym wątku. To rozwiązało problem z logowaniem klienta do interfejsu użytkownika w sklepie w wersji wcześniejszej niż 1.8.x.
/magento//a/34057/695
źródło