eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.wwwJak pokazać ścieżkę dostępu do dokumentu?Re: Jak pokazać ścieżkę dostępu do dokumentu?
  • Data: 2009-03-07 20:21:46
    Temat: Re: Jak pokazać ścieżkę dostępu do dokumentu?
    Od: porneL <n...@p...net> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On Sat, 07 Mar 2009 19:01:51 -0000, Marek <m...@s...interia.pl> wrote:

    >> Ale POST wcale nie jest bezpieczniejszy niż GET! W obu przypadkach
    >> każdy ma możliwość przesłania ci dowolnych danych.
    >
    > Ja nie mówiłem o bezpieczeństwie wcale lecz o utrudnieniu ingerencji.
    > Powiem na przykładzie: był kiedyś formularz kontaktowy na jakimś
    > serwisie wykorzystujący GET.

    Uparcie robisz na opak :)

    Formularz kontaktowy _powinien_ używać POST, bo ma efekt uboczny - wysłanie e-maila.

    > POST ruch natychmiast ustał. Dodatkowo dorzuciłem jeszcze w ukrytym polu
    > ID transakcji aby jeszcze bardziej ograniczyć działalność botów
    > spamerskich.

    Spam to jest osobna sprawa i spambotom wcale nie jest trudniej wysłać dane przez POST
    niż GET (co dobrze wiem po przeanalizowaniu parunastu milionów spamów na sblam.com)

    > Ale to już wymaga znacznie większej ilości pracy. Niewiele osób ma
    > ochotę grzebać aż tak głęboko. GET wypełnią nawet nudzące się dzieci.

    Dlatego należy robić walidację danych! Nie rób bezbronnych aplikacji (security by
    obscurity) polegając na tym jak bardzo komuś się (nie)chce. Zrób to porządnie tak,
    żeby nie było oczywistych dziur w użyciu danych POST, GET, cookies i innych.

    >> POST przyciąga spamerskie boty znacznie bardziej niż GET, a dobrym
    >> botom można zakazać GET w robots.txt.
    >
    > Sęk w tym, że identyfikacja takiego bota jest żadna. Przypadkowy IP,
    > podszywanie się pod przeglądarkę itp. Nie ma jak zakazać.

    Powiedziałem dobrym botom. Te złe i tak będą ci łaziły po wszystkich formularzach -
    GET (harvestery) i POST (spamboty).

    >> OK, ale proponuję to robić dodatkowo, a nie zamiast tworzenia
    >> niezawodnych URL-i.
    >
    > No dobrze, a po co w serwisie dwie wyszukiwarki oferujące to samo tyle
    > tylko, że jedna pracująca w trybie GET i nie pozwalająca na łatwy
    > powrót do niej gdy w łąńcuszku zdarzeń jakiś POST się przytrafił?

    Nie rozumiem o czym mówisz. Wyszukiwarka = GET. Koszyk = POST. Wyszukiwarka !=
    koszyk.

    >> To nie ma związku z wyszukiwarką, szczególnie jakbyś prawidłowo użył GET.
    >
    > Akurat to ma związek m.in. z wyszukiwarką i każdym innym formularzem w serwisie.

    Nie musisz robić wszystkich formularzy tą samą metodą! Wręcz odwrotnie - bardzo ważne
    jest użyć odpowiedniej metody do odpowiedniego rodzaju formularza.

    >> Kiedy potrzeba użyć POST, to ten bug obchodzi się wysyłając status 303
    >> i przekierowanie.
    >
    > Nie zaskoczyłem? Co można w ten sposób zyskać i jak miałoby to działać?
    > Jeśli możesz to przedstaw mi krok po kroku wypełnienie formularza i
    > wpływ tej medody na problem "wstecz".

    Przeglądarka wysyła POST. Obrabiasz dane, wysyłasz status 303 i nagłówek Location.
    Przeglądarka załaduje nową stronę używając GET. Wracanie działa tak, jak zawsze
    powinno.

    To jest mniejwięcej to, co opisałeś na początku wątku. Sęk w tym, żeby to stosować
    tylko wtedy, gdy potrzeba POST (czyli nie przy wyszukiwaniu) i żeby URL podany w
    Location zawierał coś unikalnego zależnego od danych z POST, jeśli ma z nimi jakiś
    związek (jeśli wyświetlasz tylko stronę z "dziękujemy za wysłanie formularza", to nie
    musi być unikalny. Jeśli wyświetlasz "dodałeś czajnik do koszyka", to powinien być
    unikalny, żeby po dodaniu czegoś innego do koszyka użytkownik na pewno nie dostał
    strony o czajniku).

    >> Tego się nie czepiam. Czepiam się, że używasz POST zamiast GET tam,
    >> gdzie się nie powinno.
    >
    > POST tak czy owak muszę stosować choćby z uwagi na limit danych GET.

    No, ok. Jeśli masz tyle danych, że nie mieszczą się w GET to nie ma wyjścia.

    > zamkniętych rozwiązań typu wyszukiwarka Google. Gdy co jakiś czas musisz
    > dodawać nowe funkcje, bo klient tak sobie życzy, to zrobisz sobie
    > krzywdę prędzej czy później bazując na GET.

    Jeśli masz w aplikacji choć odrobinę abstrakcji, to powinno dać się używać GET na
    początku i bezboleśnie przerobić na POST, jeżeli ilość pól urośnie do niebezpiecznego
    rozmiaru.

    W praktyce jednak z tym się nie spotykam. Formularz, który ma kilkaset pól albo opcji
    do zaznaczenia w <select> najczęściej jest też zbyt skomplikowany dla użytkowników i
    robi zbyt wiele rzeczy na raz. Taki formularz dzielę na mniejsze (coś a'la wizard)
    albo wybór spośród setek indywidualnych opcji zamieniam na coś innego - np. wybór
    całych grup/kategorii albo wg. tagów/słów kluczowych.

    --
    http://pornel.net
    this.author = new Geek("porneL");

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: