Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [PHP]Metoda post, a get ?
Forum PHP.pl > Forum > Przedszkole
piotr485
1. Która metoda jest bezpieczniejsza ? Mam stworzony kod ktory wyswietla galerie, chcialbym, aby obok kazdego zdjecia byl przycisk usun. Zrobic to za pomoca <a href="&usun=1"></a> itd. czy za pomoca post - dla kazdego zdjecia <form><input type="hidden" name="fotka" value="1"><input type="submit"></form>

Która metoda bezpieczniejsza i bardziej rozsądna ?

2. Czy tworzenie getow w panelu admina &id=4&komentarz=5 jest dobrym pomyslem ? Moze to jakos zamieniac dla bezpieczenstwa? 4 zamieniac na md5? czy to ma sens ? Jak to widzicie ?
cojack
Bez znaczenia jak to zrobisz, tak czy siak i jedna i druga jest bezpieczna. Na tyle na ile jesteś mądry i filtrujesz dane wprowadzane w getach i postach.

Ale robić formularz dla usuwana zdjęć? Imo bzdura. Dawaj geta i święto.
MateuszS
POST uzywamy np. przy rejestracji (żeby nam ktoś w pasku adresu nie zobaczył hasła gdy przesyłamy GET biggrin.gif, wysyłając różne dane z inputów też raczej używa się POST). GET np. gdy usuwamy jakiś wpis z bazy, tak aby jego id było w adresie. (zaszyfrowane bądź nie ;P). Obie są bezpieczne jak się wie jak je używać...
batman
~piotr485
1. Do takich rzeczy jak usuwanie zdjęć przyjęło się stosować GET, co nie oznacza, że nie można użyć POST. Korzystasz z tego, co jest dla Ciebie wygodniejsze. W takim przypadku nie ma mniej lub bardziej bezpiecznej metody.

2. Nie ma sensu kombinować z kodowaniem zmiennych przekazywanych w adresie. Lepiej poświęcić ten czas na stworzenie ładnych linków. W takich przypadkach znacznie ważniejsze jest sprawdzenie przed wykonaniem danej akcji, czy osoba, którą ją wywołała, ma odpowiedni poziom uprawnień.

~MateuszScirka
POST używa się w formularzach, ponieważ kiedyś zmienne GET miały ograniczoną długość. A przesyłanie hasła W POST jest tak samo "bezpieczne" jak w przypadku GET. Dowolne narzędzie do podsłuchiwania nagłówków i mam hasło wysłane POST-em.
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.