-
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");
Następne wpisy z tego wątku
- 07.03.09 22:58 Grzegorz Staniak
- 07.03.09 23:00 Grzegorz Staniak
- 09.03.09 10:58 Marek
- 09.03.09 11:05 Marek
- 09.03.09 11:06 Marek
- 09.03.09 14:36 Grzegorz Staniak
- 09.03.09 20:22 porneL
- 09.03.09 21:10 Marek
- 09.03.09 21:17 Marek
- 09.03.09 21:49 Konrad Kosmowski
- 09.03.09 23:29 porneL
- 10.03.09 00:42 Marek
- 10.03.09 09:06 Maciej Łebkowski
- 10.03.09 09:23 Artur Muszyński
- 10.03.09 12:38 Marek
Najnowsze wątki z tej grupy
- Jakie znacie działające serwery grup dyskusyjnych?
- is it live this group at news.icm.edu.pl
- php, linki z nazwami a $_GET, SEO
- www polityka pl captcha
- dyktatura brudnego palucha
- www.znanylekarz.pl
- Czy pytanie o sczytywanie stron programami/skryptami to tu?
- Grupy webdevowe
- Jak wydrukować stronę?
- IIS, kilka witryn
- linki <a href="/strona.php"> (ze slashami)
- co rozszerza stronę??
- responsywny akapit <p>
- Czy istnieje jakiś emulator przeglądarek pod Mac'a?
- taka sama konfiguracja dla localhost i produkcji
Najnowsze wątki
- 2025-01-06 Jeździ, skręca, hamuje
- 2025-01-06 Białystok => System Architect (Java background) <=
- 2025-01-06 Gliwice => Specjalista ds. public relations <=
- 2025-01-06 Białystok => Solution Architect (Java background) <=
- 2025-01-06 Zielona GĂłra => Konsultant WdroĹźeniowy Comarch XL/Optima (KsiÄgowoĹ
- 2025-01-06 Popr. 14. Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- 2025-01-06 Ostrów Wielkopolski => Area Sales Manager OZE <=
- 2025-01-06 Do IO i innych elektrooszolomow, tu macie prawdziwe smrody
- 2025-01-06 Białystok => Full Stack .Net Engineer <=
- 2025-01-06 Kraków => Business Development Manager - Network and Network Security
- 2025-01-06 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2025-01-06 Warszawa => Spedytor Międzynarodowy <=
- 2025-01-06 Lublin => Programista Delphi <=
- 2025-01-06 Gdańsk => Specjalista ds. Sprzedaży <=
- 2025-01-06 śnieg