Ukrycie adresu strony.

[Tomahawk]

Witam!

Mam dla użytkowników napisany panel administracyjny w php.

Wszystko opiera się na jednym pliku do którego są przesyłane informacje poprzez $_GET co ma zrobić (co includować/modyfikować itd...)

Chciałbym teraz jakoś ukryć ten brzydki adres żeby nie pokazywało tych parametrów w pasku adresu i żeby user ich nie mógł modyfikować...

Narazie rozważyłem 2 możliwości. Pierwsza to wrzucenie wszystkiego do ramki ale wtedy mam problem bo używam przekierowań 301 header(location:....) poto aby np. przy odświeżeniu strony nie dodać np. tej samej rzeczy... Kiedy mam to w ramce to rzecz jasna to przekierowanie nie realizuje swojego zadania...

Druga sprawa to wszędobylskie formularze z method="post" ale ciarki mi przechodzą bo było by to nie ładne...

Macie jakieś propozycje? Otwarty jestem na wszelkie "Ajaxy", "javascripty" i inne metody byle żeby jednakowo działało. Znam tylko php więc sam nic nie napisze w user-side lang ale z prostym kodem myślę że dam radę...

A szczerze powiedziawszy to wolałbym jakoś php/.htaccess itp...

[papieros]

A czemu użycie POST miałoby być nieładne, tak się właśnie robi.

Jeśli chces koniecznie z GET, to proponuję porostu zaszyfrować parametry GET'a tak żeby nie było szans, że zmodyfikowany parametr będzie wskazywał na jakąś stronę/akcję. Można też dodawać sumę kontrolną aby sprawdzić czy parametry nie były modyfikowane

[Tomahawk]

Niechcę post ponieważ za dużo formularzy by było i bardzo nieczytelnie. Poza tym uciążliwe jest cofanie gdy np. trzeba potwierdzać wysłanie danych.

[papieros]

Przecież POST działa identycznie jak GET, jeno trza czasami zapamiętać przesłane dane. A dlaczego miałoby być więcej formularzy niż z GET

[slawek22]

Niechcę post ponieważ za dużo formularzy by było i bardzo nieczytelnie. Poza tym uciążliwe jest cofanie gdy np. trzeba potwierdzać wysłanie danych.

Zaraz po POST robisz redirect. To z resztą powszechnie używana metoda, żeby ktoś przypadkiem nie wysłał tych samych danych 2 razy

[Tomahawk]

Ale jaki redirect? Jak zrobie w php 301 to przecież ramka tego nie widzi i traktuje jako jedną stronę i wychodzi tak jakby tego przekierowania w ogóle nie było... więc nic nie daje...

Mogę zrobić w javascript ale nie lubi tych user-side języków bo każda przeglądarka ma swój świat...

Przecież POST działa identycznie jak GET, jeno trza czasami zapamiętać przesłane dane. A dlaczego miałoby być więcej formularzy niż z GET

Jak to czemu? A jak mam niby dane przesyłać metodą POST jeśli nie poprzez formularze? Normalnie bym dał linka z parametrami i już...

[papieros]

Aha, myślałem, że dane tak, czy inaczej pochodzą z formularzy ... to może rozwiązaniem, żeby adresy ładnie wyglądały, będzie mod_rewrite i sprawdzanie czy wywołanie już nie było użyte (żeby pozbyć się dubli) tu pomocne mogą być cookie, żeby zidentyfikować użytkownika.

[slawek22]

Tylko jeśli użyjesz redirect masz pewność, że wywołanie nie było wynikiem przeładowania strony a faktycznie kliknięcia.

Jeśli akcja modyfikuje dane lub trzeba ukryć przesyłane zmienne:

(1) Strona -> (2) POST (redirect) -> (3) potwierdzenie

jak z strony potwierdzenia (3) dasz wstecz to lądujesz na stronie 1 i nie trzeba używać ciasteczek, klikać w komunikaty, etc. Problem dublowania danych też odpada. Ciastka i inne dziwne pomysły tylko spowodują problemy a i tak nie będą działać dobrze bo tego się inaczej zrobić nie da. BTW: jeśli ktoś myśli, że się da to niech napisze jak. Może się douczę

Pomijając sens innych rozwiązań bo po co pisać zabezpieczenie przed przeładowaniem bardziej skomplikowane od samego panelu, skoro standardowe rozwiązanie zajmuje jedną linijkę kodu.

Jeśli akcja nie modyfikuje danych

(1) Strona -> GET (wyświetlenie wyników)

lub

Link -> Wyświetlenie wyników

Ramka to kolejny bezsensowny pomysł i będą z tym same problemy (wstecz / bookmarki / nawigacja) a linki i tak będą się wyświetlać w pasku stanu.

Z resztą to panel administracyjny. Kogo te linki obchodzą? Niestety masz błędny pogląd na to za co się zabierasz. Użytkownik ma nie modyfikować adresu w pasku? Znowu pozbawione logiki założenie. Jak się postara i jest inteligentniejszy od małpy to i tak zmodyfikuje, choćbyś zrobił rewrite, ramki, AJAXY i wdrożył jeszcze 150 bezsensownych rozwiązań. Trzeba zabezpieczyć przekazywane dane a nie uniemożliwiać ich edycję. Każdy średnio rozgarnięty dzieciak potrafi odpalić firebuga i przekaże takie dane jakie chce w 2 sekundy, albo nawet wpisze to ręcznie w pasku lub wyedytuje lokalnie formularz jeśli będziesz sprawdzał po request method.

Bardziej bym się martwił o te linki w panelu bo to błąd i to bardzo poważny. Jak masz np. funkcję do usuwania czegoś i robisz to na linkach to jeśli jakiś użytkownik wejdzie z akceleratorem WWW to on mu te linki "odczyta z wyprzedzeniem" a user np. skasuje sobie konto i nawet nie będzie wiedział kiedy.

Można nawet trochę odejść od tematu w stronę serwerów proxy bo na niektórych sieciach są one tak skonfigurowane, że robią bezwzględny cache wszystkich requestów po GET i nie patrzą nawet na nagłówki (które mówią "nie keszować"), przy przeglądaniu panelu nie jest to problem, gorzej gdy na przykład masz dajmy na to zmianę DNS domeny po GET... a ta operacja zatrzymuje się na cache sieci osiedlowej.

[qwertyuiop]

Proponuję Ci raczej dobrze przemyśleć kontroler, to na pewno rozwiąże wiele problemów, bo raczej tu widze problem.

[Tomahawk]

Tylko jeśli użyjesz redirect masz pewność, że wywołanie nie było wynikiem przeładowania strony a faktycznie kliknięcia.

Jeśli umieści w iframe panel to pod np. Safari redirect nic nie zdziała... Dane zostaną wysłane jeszcze raz.. Więc trzeba robić przekierowanie w meta tagach...

Ramka to kolejny bezsensowny pomysł i będą z tym same problemy (wstecz / bookmarki / nawigacja) a linki i tak będą się wyświetlać w pasku stanu.

Jak do panelu to IMHO się nadaje... Ale lepszym pomysłem jest załadowanie strony do okienka javascript tak jak jest ładowana strona z listą linków w livelink.pl

Trzeba zabezpieczyć przekazywane dane a nie uniemożliwiać ich edycję. Każdy średnio rozgarnięty dzieciak potrafi odpalić firebuga i przekaże takie dane jakie chce w 2 sekundy, albo nawet wpisze to ręcznie w pasku lub wyedytuje lokalnie formularz jeśli będziesz sprawdzał po request method.

Zabezpieczyć? Tzn. jak? Wiadomo stosuje się standardowe filtrowanie itd. ale przecież można cos zawsz przeoczyć... Wątpie żeby każdy średnio rozgarnięty dzieciak miał aż takie pojęcie o www

Bardziej bym się martwił o te linki w panelu bo to błąd i to bardzo poważny. Jak masz np. funkcję do usuwania czegoś i robisz to na linkach to jeśli jakiś użytkownik wejdzie z akceleratorem WWW to on mu te linki "odczyta z wyprzedzeniem" a user np. skasuje sobie konto i nawet nie będzie wiedział kiedy

Pierwsze słysze o takim czymś... Ale wszystkie "usuwania" zazwyczaj wymagają potwierdzenia...

[graft]

jasne że POST + redirect ! Po redirekcie wyświetlasz już informacje zapisane, więc nie ma problemu, że przy wciśnięciu przycisku :wstecz: pojawi się beznadziejny komunikat o ponownym przesłaniu zmiennych post.

Jeśli chcesz natomiast wykonywać operacje (np. zewn. skrypt.php) bez przeładowania strony zainteresuj się powiedzmy biblioteką mintajax + function SendRequest(), a nie szitowate iframe - lepiej wczytywać do diva (chyba...).

[slawek22]

Iframe to porzucona technologia. W specyfikacji W3C już dawno tego nie ma, właśnie ze względu na problemy. Nie wiem dlaczego redirect ma nie działać w safari lecz przyjęcie założenia, że przeglądarka użytkownika obsługuje redirect jest dużo bardziej zdroworozsądkowe niż przyjmowanie, że użytkownik ma włączony javascript i że ten javascript zadziała, bo musisz przetestować praktycznie pod każdym browserem, żeby mieć pewność, chyba, że to na prawdę prosta rzecz.

Możesz wpakować panel w iframe. Tak się robiło w latach 90'tych, niektórzy dalej robią strony na tabelkach. Możesz nawet napisać niestandardowy mechanizm zapobiegania podwójnemu wysyłaniu danych... dla 1% użytkowników którzy nie są kompatybilni z powszechnie używaną technologią / rozwiązaniami. Co sprawi, że ten 1% będzie zadowolony... i popsuje ten mechanizm pozostałym 50% użytkowników.

Pasek w przeglądarce jest po to... żeby użytkownik widział URL gdzie się znajduje. Gdyby użytkowników raził w oczy wygląd linków albo pasek byłby niepotrzebny to twórcy przeglądarek by go wyłrzucili 15 lat temu... a nie zmuszali każdego do ładowania strony we frejmy.

Jak do panelu to IMHO się nadaje... Ale lepszym pomysłem jest załadowanie strony do okienka javascript tak jak jest ładowana strona z listą linków w livelink.pl

Modyfikowałem parę paneli na AJAX. Moim zdaniem JS w panelu to można użyć jako dodatek, nie można na nim opierać całej funkcjonalności, może jakieś proste czynności. Często się to wysypuje - ludzie mają problemy z działaniem i obsługą.

Zabezpieczyć? Tzn. jak? Wiadomo stosuje się standardowe filtrowanie itd. ale przecież można cos zawsz przeoczyć... Wątpie żeby każdy średnio rozgarnięty dzieciak miał aż takie pojęcie o www

Jeśli nie dzieciak to automat, poza tym nie doceniasz pomysłowości dzieciaków Wszystkie linki w przeglądarkach są teraz ogólnie widoczne / możliwe do skopiowania. Pisać na klawiaturze każdy potrafi.

Co do skryptu to dobrze widać jakie dane lecą, na 100% widzisz co trzeba zabezpieczyć. Popatrzysz na listę argumentów i od razu widać co i jak. Jeśli zamiast przerobić tę listę od góry do dołu chcesz olewać bezpieczeństwo i "maskować" błędy usiłując ukryć adres to tylko tracisz czas bo użytkownik który będzie za głupi, żeby przesłać do witryny dowolne dane nie jest dość inteligentny, żeby przesłać do witryny odpowiednio spreparowane dane. Zabezpieczasz skrypt przed osobami, które nie stanowią zagrożenia tak czy inaczej.

Pierwsze słysze o takim czymś... Ale wszystkie "usuwania" zazwyczaj wymagają potwierdzenia...

Wymagają, gorzej gdy potwierdzenie też jest przez link. Co do POSTów - po prostu robisz ukryty formularz i używasz form.submit(). Jeśli użytkownik wyłączy javascript pokazujesz formularz i dodatkowo przycisk. Cała filozofia.

Pogoogluj 'google web accelerator fiasco':

https://www.techsideup.com/web-events-of-20...lerator-fiasco/

https://blog.taragana.com/index.php/archive...e-can-solve-it/

Earler this year, Google announced a beta product known as Web Accelerator. It was one of the biggest mistakes Google ever made. The idea was to cache websites browsed by all users using Web Accelerator in order to “make browsing faster”. What Google failed to realize that the technology used to cache websites - the same technology used to “spider” the web by following links - also had the capability of following “Delete” links, “Edit” links and other damaging actions, particularly in behind the scenes admin panels and content management systems.

Takie same problemy może powodować GET i źle skonfigurowane serwery PROXY.