Jogger.pl


Bug #245

Ogólne 27 maja 2006

Bug #245: Nieskończone przekierowania w zewnętrznej domenie

Poprawione.

Niestety Lynx nadal nie działa. Nie mam pojęcia dlaczego tylko on nie przyjmuje cookie. Jakiś pomysł ?


Komentarze RSS

  1. Może przez to, że przed pierwszym przekierowaniem (z domeny na jogger.pl) Jogger wysyła ciastko PHPSESSID? Bo mi się wydaje, ze zewnętrzna domena powinna dostarczać ciacho tylko na samym końcu...

    PS. Hmm... dziwna sprawa. Jak w Lynksie odrzucam ciacho, to dany Jogger wchodzi. Jak przyjmuję, to przekierowuje w nieskończoność.

    W Konquerorze jeszcze dziwniej — tak jakby w ogóle nie przekierowywał...

    I swoją drogą, przy wejściu przez starą domenę (.jogger.pl), Jogger mógłby przekierowywać już na nową z SID-em, zamiast na główną nowej, która potem przekierowuje z powrotem na Joggera...

  2. IMHO obecne rozwiązanie jest do dupy. Strona główna mojego Joggera to jest http://blog.jajcus.net/ i tak ma być. A nie żadne http://blog.jajcus.net/sid/smiecijakies/. Ja chcę sensownego indeksowania w przeglądarkach.
    Już lepiej, jakby nic nie działo się automatycznie, tylko trzeba było coś ręcznie kliknąć, żeby "pożyczyć" ciasteczko z jogger.pl. Ewentualny automatyzm mógłby wchodzić w grę, jakby przeglądarka dostarczyła ciasteczko, ale np. przeterminowane. I zawsze na końcu przeglądarka powinna trafiać na właściwą stronę z _normalnym_ URL.

  3. jajcus: wymysl lepiej. Bardzo chetnie poslucham. Jak wykryc ze przegladarka nie obsluguje ciasteczka i zachowywac ta informacje bez dodawania niczego do url ? Moge oczywiscie co kazde klikniecie sprawdzac i po 4 razy przekierowywac.

  4. @jajcus: ehhh sprawdzanie co kazde klikniecie tez jest bez sensu bo ostatecznie i tak musi byc cos w url bo znowu przekieruje tak jak to jest przy pierwszym wejsciu.

  5. Zauważmy małą różnicę. Skrypt nie ma sprawdzać, czy przeglądarka obsługuje ciastka, ale czy przyjmie to konkretne ciastko...

  6. 1. Nie ma żadnego ciasteczka -> pokazuj stronę bez żadnych trików, bez przekierowań itd. Tylko z linkiem do "zalogowania" (który uruchamia całą maszynerię, ale bez możliwości zapętlenia)
    2. Jest ciasteczko -> spróbuj powiązać z sesją joggerową, jak się uda, to pokaż stronę jak dla zalogowanego użytkownika
    3. Jeśli ciasteczka nie udało się użyć -- usuń je i wystaruj maszynerię. W najgorszym wypadku skończy się na punkcie 1.

    W efekcie:
    - ktoś z przeglądarką bez ciasteczek (albo np. bot wyszukiwarki) ma normalną stronę bez żadnych sesji czy zalogowania
    - ktoś z przeglądarką z ciasteczkami, ale niegdy się na stronie nie logujący ma to samo, ale jednym kliknięciem jest zalogowany
    - jeśli już kiedyś stronę odwiedzał, to powinno działać wszystko normalnie
    - jesli coś nie tak idzie z ciasteczkami, to się nic nie powinno zapętlić, bo po powrocie do punktu wyjścia ciasteczka nie ma

    Może tak by się dało?

  7. @jajcus: 1. Juz tak kombinowalem. Wez jednak pod uwage, ze przy pierwszym wejsciu nigdy nie ma ciasteczka. Jezeli wejde bezposrednim linkiem w Twoj wpis to bede niezalogowany, formularze beda puste, a jezeli poziom wpisu jest > 1 to mi sie nawet nie wyswietli.

  8. Bot wyszukiwarki ma url bez /sid. To sie pojawia wylacznie wtedy, gdy przegladarka faktycznie nie obsluguje ciastek

  9. sparrow: ale mnie to by przeszkadzało znacznie mniej niż nieindeksowanie przez Google. Ci, dla których logowanie jest istotne odwiedzają mnie częsciej i jedno kliknięcie przy pierwszym wejściu nie powinno być problemem. Jeżeli dana strona zawierałaby jeden wpis tylko dla zalogowanych, to wtedy "maszyneria" może się odpalić -- niepubliczne strony mogą mieć bezsensowne URLe, lub po prostu wymagać ciasteczek, byle wszystkie publiczne miały kanoniczne URL.

  10. @jajcus w takim razie bede musial to zrobic jako opcje. Zaraz sie pewnie podniosa krzyki z innej strony, ze sie trzeba specjalnie logowac.

  11. Jeśli boty dostają "prostą" stronę (ale czy na pewno i czy wszystkie?), to nie jest tak źle. Ale opcja o której mówimy też by nie była zła.

    W każdym razie dzięki, że zająłeś się problemem! :-)

  12. @jajcus: boty moga dostac id sesji tylko wtedy jezeli udaja ze sa przegladarka. Sprawdzam user-agent 20-stu popularnych/mniej popularnych przegladarek, jezeli sie nie zgadza to nigdzie nie przekierowuje.

    Twoje proponowane rozwiazanie (przegladarka bez obslugi ciastek, z obsluga to nie dotyczy):

    1. wchodze na strone
    2. jest pare wpisow, nie widze nic z poziomu > 1, nie moge dodawac komentarza jako uzytkownik joggera
    3. kilkam 'zaloguj'
    4. przekierowuje pare razy i ostatecznie pojawia sie strona z identyfikatorem sesji w url

    wiec gdzie tu sens, skoro i tak i tak bedzie sid w adresie, a tylko dodatkowo utrudnia czytanie wpisu/dodawanie komentarzy ?

  13. sparrow: to może na razie uznajmy problem za rozwiązany. Zobaczę jak to będzie działać w praktyce i najwyżej zgłoszę nowego requesta.
    Najbardziej bałem się o boty wyszukiwarek, ale tak jak jest wydaje się całkiem sensownie.
    A skoro są problemy z lynxem, to możesz go na razie wywalić z tej listy przeglądarek. Inna sprawa, że lynx może po prostu bardziej trzymać się protokołu HTTP niż Jogger w którymś miejscu... ale to już trzebaby zdebugować.
    W każdym razie: dzięki :-)

  14. Sprwadzanie UA to najbardziej chory pomysł, jaki można zastosować. W ogóle te cały zewnętrzne domeny to jeden, wielki niewypał.

  15. @peres: Specjalnie przekierowuje ze starej domeny nick.jogger.pl najpierw na nowa, aby zostalo ustawione ciastko sesji. Potem na glowna jogger.pl i spowrotem. Przy powrocie na nowy adres jezeli jest juz ustawione cookie to znaczy, ze przegladarka je zaakceptowala i mozna pracowac bez /sid.

  16. @peres: masz mniej chory pomysl niz UA ?

    sprawdzam takie user-agent:

    Sunrise/
    (DreamPassport/
    Ace Explorer
    Advanced Browser
    Amiga-AWeb/
    AmigaVoyager/
    annotate_google;
    ANTFresco/
    Cyberdog/
    ELinks
    IBrowse/
    iCab/
    Jakarta
    K-Meleon/
    Liferea/
    Links
    Lynx/
    Mozilla/
    NETCOMplete/
    Opera/
    Orca Browser
    SlimBrowser
    T-Online Browser

  17. Jakbym miał możliwość spojrzenia w kod tych przekierowań, to może bym coś wymyślił.

  18. @peres: UA i zewnetrzne domeny to wielki niewypal, wiec po co go poprawiac :) wymysl lepsze rozwiazanie, po prostu sam pomysł :)

  19. IMO problem Lynksa polega na tym, że Jogger ustawia dwukrotnie dla domeny zewnętrznej PHPSESSID — raz przed przekierowaniami, i drugi raz po nich. I przez to za drugim razem Lynx ignoruje ciastko. Przynajmniej tak mi się wydaje.

  20. Albo po prostu to wina cache, bo ostatni URL jest identyczny jak pierwszy. Więc Lynx wyciąga wynik z cache i przekierowuje... może zmień 302 na 307.

  21. A chyba najlepszym rozwiązaniem będzie zmuszenie Joggera, by ostatnie przekierowanie nie było na /, tylko np. /x/; i potem wszystkie URL-e tym /x/ poprzedzić. /x/ jest dosyć krótkie, więc nie ubrzydzi bardzo domeny, a pozwoli rozpoznać, że przekierowanie już nastąpiło i nie należy przekierowywać ponownie.

  22. @peres: jeszcze potestuje i zobacze co sie da zrobic

  23. Michał Górny: ja żadnego /x/ nie chcę

    sparrow: zauważyłem jeszcze jedno:
    Expires: Thu, 19 Nov 1981 08:52:00 GMT
    Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
    Pragma: no-cache

    Nie wydaje mi się to odpowiednie na stronie bloga, szczególnie w przypadku "bezciasteczkowym" (dla zalogowanego użytkownika no-store, no-cache ma jakiś sens, Expires w przeszłości już mniej). Do tego "no-store" może być interpretowany przez wyszukiwarki jako zakaz trzymania kopii.

    Najlepsze byłoby tylko właściwe Last-Modified i odpowiednie Expires (ale wyznaczenie tego może być kosztowne), ale wystarczyłoby odpowiednio łagodne Cache-Control.

  24. I tu się zaczyna problem. „Bo najważniejsze, żeby mi się URL podobał — a czy inni są w stanie wejść, to już mnie nie obchodzi”.

  25. Michał: sorry, ale śmieciasty URL jako obejście problemów gdzie indziej nie jest rozwiązeniem. Jestem przeciwny brzydkim hackom, nawet jako obejście ograniczeń samego protokołu HTTP. Już wolę zrezygnować w niektórych przypadkach z funkcji "automatycznego logowania", tak jak wcześniej zaproponowałem -- bo ta funkcja to tylko bonus (bardzo przydatny). Gdyby mi było wszystko jedno pod jakim URLem jest mój blog, to czemu w ogóle włączałbym własną domenę?

  26. Skomentuję to czterema słowami: przerost formy nad treścią.
    Z mojej strony EOT.

  27. No Google już indeksuje mojego joggera... ale niezupełnie tak jakbym chciał — razem z tym durnym /sid/smieci :-(

  28. http://www.google.pl/search?q=site%3Ablog.jajcus.net

  29. to bardzo brzydko z jego strony ze udaje zwykla przegladarke

  30. sparrow: celem bota Google jest zindeksowanie treści (czyli tego co widzą użytkownicy) jak największej ilości stron. Sam wiesz, że wiele stron wpuszcza tylko to co wygląda jak przeglądarka. W szczególności, "Mozilla/" w User-Agent ma prawie wszystko co chodzi po stronach WWW (łącznie z MSIE), więc użycie tego ciągu było conajmniej nierozsądne. Oglądałeś chociaż wcześniej logi? Założyłem, że tak, dlatego wcześniej nie weryfikowałem tych wzorców co tu wkleiłeś.

  31. wylacze zewnetrzne domeny i bedzie spokoj, to jest bez sensu walczyc z google

  32. Jasne, tak najprościej. Mamić użytkowników nowymi funkcjami, a potem się poddać, jak nie działają.... Przecież listę wartości User-Agent dla botów łatwo zdobyć, a dla przeglądarki po prostu użyłeś wzroców zbyt ogólnych.

  33. A może odseparować zewnętrzną domenę od .jogger.pl ? Tzn. ludzie spoza Joggera będą mogli wchodzić na zewn. i tam się logować, etc., a ludzie z Joggera będą wchodzić na .jogger.pl, nie będą nigdzie przekierowywani i będą mogli normalnie działać?

  34. a moj pomysl jest tak powalony ze nawet nie warto go tutaj wrzucac, aczkolwiek jesli po testach cos z tego wyjdzie to zarzuce

  35. Dalsze rozważania na temat problemu.

    trackback od Blog Michała Górnego: A zewnętrzna domena wciąż zepsuta...
    http://mgorny.jogger.pl/2006/06/26/a-zewnetrzna-domena-wciaz-zepsuta/

Komentowanie tylko dla zalogowanych