eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.wwwAjax - kwestie bezpieczeństwa
Ilość wypowiedzi w tym wątku: 34

  • 21. Data: 2012-12-22 21:42:57
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Borys Pogoreło <b...@p...edu.leszno>

    Dnia Thu, 20 Dec 2012 21:13:39 +0100, Marek napisał(a):

    > Przykład przetwarzania formularza:
    > (...)

    Ale Ty chcesz najwyraźniej odtworzyć proces obsługi formularza w
    narzędziu, które ma zupełnie inną filozofię działania. Widać to po tych
    kombinacjach z przekierowaniami. Przyjmij, że masz do dyspozycji tylko
    zapytanie-odpowiedź i świat stanie się prostszy.

    > No wysyłam do modułu A ale ten w odpowiedzi nie może wygenerować
    > przekierowania na inny URL bo wysłałby je nie do przeglądarki lecz do JS.

    Zgadza się, więc całą logikę sterującą formularzem musisz zaszyć w JS (ew.
    po prostu wyświetlać co zwraca serwer). Nie ma lekko, zachciało się
    ajaksów, to trzeba cierpieć ;)

    --
    Borys Pogoreło
    borys(#)leszno,edu,pl


  • 22. Data: 2012-12-23 18:39:01
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Marek <p...@s...com>

    W dniu 2012-12-22 17:02, Tomasz Sowa pisze:
    > On 2012.12.22 16:39, Marek wrote:
    >
    > Ja u siebie robie tak, normalne requesty:
    > http://www.domain.tld/cos/gdzies
    > a ajaxem dodaje sobie parametr:
    > http://www.domain.tld/cos/gdzies/type:ajax
    >
    > i tutaj sobie zwracam albo jsona albo kawalek htmla z 'srodka' strony,
    > no więc masz racje, te urle są różne ;)

    Właśnie tak teraz sam zaczynam kombinować. Nawet pal sześć różne URLe
    lecz wymaga to (tak jak pisaliśmy już) innego podejścia
    programistycznego w obsłudze transakcji. De facto jeśli do tej pory URL
    = moduł, to teraz 1 URL = 2 moduły (1 dla Ajaxa, a 2gi dla tradycyjnego
    requesta) zachowujące się odmiennie z punktu widzenia systemu. Nie jest
    istotne czy rozdzielisz "adresowanie" modułu URLem, parametrem czy
    nagłówkiem. Wymagane jest oddzielna obsługa.


  • 23. Data: 2012-12-23 18:40:48
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Marek <p...@s...com>

    W dniu 2012-12-22 21:38, Borys Pogoreło pisze:

    > Wystarczy pilnować nagłówka X-Requested-With, wiekszość bibliotek dodaje
    > go automatycznie.

    Nie sprawdzałem: goły Ajax też ustawia ten nagłówek? Nie stosuję
    bibliotek. Metoda wydaje mi się sprytna i w tym kierunku pójdę. Dzięki
    za podpowiedź :-)



  • 24. Data: 2012-12-23 18:51:49
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Marek <p...@s...com>

    W dniu 2012-12-22 21:42, Borys Pogoreło pisze:

    > Ale Ty chcesz najwyraźniej odtworzyć proces obsługi formularza

    Nooo... masz rację.

    > w
    > narzędziu, które ma zupełnie inną filozofię działania. Widać to po tych
    > kombinacjach z przekierowaniami. Przyjmij, że masz do dyspozycji tylko
    > zapytanie-odpowiedź i świat stanie się prostszy.

    Musisz mi to na polski przełożyć :-) Prawie wszystko co robię to jest
    formularz: wpisz imię, nazwisko etc. Oczywiście od strony Ajax'a nie
    będę robił submitowania lecz będę zbierał mozolnie dane i wysyłał do
    serwera, co ten może traktować jako dane z formularza właśnie. Odpowiedź
    serwera odpowiednio po tym pseudo-formularzu będę dystrybuował.

    Zależy mi na tym aby serwer zwracał HTML przede wszystkim. Chodzi o
    możliwość budowania i modyfikowania wyglądu okien w edytorach WYSIWYG.
    Zapewne dojdą inne formy komunikacji w miarę potrzeb ale bazą chcę
    uczynić HTML.

    Czy takie podejście może być jeszcze łatwiejsze? Czy nie utrudniam sobie
    czegoś?

    >
    >> No wysyłam do modułu A ale ten w odpowiedzi nie może wygenerować
    >> przekierowania na inny URL bo wysłałby je nie do przeglądarki lecz do JS.
    >
    > Zgadza się, więc całą logikę sterującą formularzem musisz zaszyć w JS (ew.
    > po prostu wyświetlać co zwraca serwer). Nie ma lekko, zachciało się
    > ajaksów, to trzeba cierpieć ;)

    A pewnie, że tak :-) No i podpytuję teraz o minimalizację bólu :-D



  • 25. Data: 2012-12-23 18:54:01
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Marek <p...@s...com>

    W dniu 2012-12-22 19:37, Izaak Goldstein pisze:

    > Cokolwiek robisz, robisz to źle. Serio i bez złośliwości.

    No od tego zacząłem wątek bo czułem, że coś nie jest tak jak powinno.

    > A po przeczytaniu całości dyskusji z Tomaszem stwierdzam, że nie
    > potrafię ci pomóc :)
    >

    A szkoda. Ale wygląda na to, że Tomek i Borys mnie ukierunkowali. Parę
    cennych uwag podsunęli.


  • 26. Data: 2012-12-23 19:15:04
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Marek <p...@s...com>

    P.S.
    Przyszło mi do głowy coś jeszcze. Te nieszczęsne przeładowania stron
    chyba być i tak muszą. Załóżmy, że jakaś strona to tabela HTML z danymi
    wygenerowana przez PHP a Ajax to okienko, które potrafi zmodyfikować
    kliknięty wiersz z tabeli. User klika sobie wiersz, coś tam zmienia i
    zapisuje. Okno Ajaxa znika ale ta tabelka pod spodem pozostaje bez zmian
    (bo to HTML). Aby ją wyświetlić zaktualizowaną i tak jakiś reload jest
    potrzebny. Ajax raczej sam "wiedzieć" nie może jaki kształt ma przyjąć
    zaktualizowany wiersz. Zresztą programistycznie byłoby trudno przysłać
    tylko ten jeden poprawiony wiersz tabeli. bo być może jakieś
    podsumowania trzeba będzie na nowo liczyć więc tym bardziej wydaje się
    to odświeżenie konieczne. Czy dobrze kombinuję?


  • 27. Data: 2012-12-23 20:56:48
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Kviat <kviat@NIE_DLA_SPAMUneostrada.pl>

    W dniu 2012-12-23 19:15, Marek pisze:
    > P.S.
    > Przyszło mi do głowy coś jeszcze. Te nieszczęsne przeładowania stron
    > chyba być i tak muszą. Załóżmy, że jakaś strona to tabela HTML z danymi
    > wygenerowana przez PHP a Ajax to okienko, które potrafi zmodyfikować
    > kliknięty wiersz z tabeli. User klika sobie wiersz, coś tam zmienia i
    > zapisuje.

    Po zapisie, jak rozumiem requeście do serwera, z serwera wysyłasz
    odpowiedź, czy zapis się powiódł, jeżeli nie, wyświetlasz komunikat o
    błędzie. I teraz odpowiednio, w zależności od rodzaju odpowiedzi i
    logiki programu, możesz:

    > Okno Ajaxa znika

    albo zostawić okno z formularzem do poprawy błędnych danych, czy
    ponownej próby zapisu rekordu.

    > ale ta tabelka pod spodem pozostaje bez zmian
    > (bo to HTML).

    Jak dostajesz komunikat z serwera o poprawnym zapisie, to:
    a) dodajesz rekord do tabeli javascriptem
    lub
    b) ciągniesz z serwera rekord ajaxem i javascriptem wstawiasz go do tabeli
    c) ciągniesz z serwera ajaxem (albo przeładowujesz stronę) całą tabelę z
    dodanym rekordem.

    > Aby ją wyświetlić zaktualizowaną i tak jakiś reload jest
    > potrzebny.

    Nie jest. Możesz to zrobić po stronie przeglądarki. Patrz pkt a) i b)

    > Ajax raczej sam "wiedzieć" nie może jaki kształt ma przyjąć
    > zaktualizowany wiersz.

    Tu nie wiem co masz na myśli.

    > Zresztą programistycznie byłoby trudno przysłać
    > tylko ten jeden poprawiony wiersz tabeli. bo być może jakieś
    > podsumowania trzeba będzie na nowo liczyć więc tym bardziej wydaje się
    > to odświeżenie konieczne. Czy dobrze kombinuję?

    Trudno czy nie, to zależy. Masz dwie warstwy: przeglądarkę klienta i serwer.
    Możesz od razu javascriptem (dodany, czy poprawiony) rekord dopisać do
    tabeli i javascriptem sobie przeliczyć podsumowanie - po stronie
    klienta. Możesz ajaxem (albo zwykłym przeładowaniem strony) poprosić o
    to serwer. Możesz mieszać metody, patrz punkt b) dodaj tylko
    przeliczenie tabeli (javascriptem).

    Pozdrawiam
    Piotr


  • 28. Data: 2012-12-23 23:40:59
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Marek <p...@s...com>

    W dniu 2012-12-23 20:56, Kviat pisze:

    > albo zostawić okno z formularzem do poprawy błędnych danych, czy
    > ponownej próby zapisu rekordu.

    Tak właśnie zamierzałem robić. Okna walidują się po stronie serwera,
    wyświetlają komunikaty o błędach lub znikają gdy wszystko jest ok.
    Wydaje mi się to najbardziej intuicyjne rozwiązanie.

    >
    >> ale ta tabelka pod spodem pozostaje bez zmian
    >> (bo to HTML).
    >
    > Jak dostajesz komunikat z serwera o poprawnym zapisie, to:
    > a) dodajesz rekord do tabeli javascriptem
    > lub
    > b) ciągniesz z serwera rekord ajaxem i javascriptem wstawiasz go do tabeli
    > c) ciągniesz z serwera ajaxem (albo przeładowujesz stronę) całą tabelę z
    > dodanym rekordem.

    a) i b) to dość złożony wariant bo wtedy logika np. podsumowania jakiejś
    kolumny musiałaby być zdublowana w Ajaxie. Zresztą to nie tylko
    podsumowania. Jeśli zmianie ulega tylko wiersz po takiej operacji, to
    pół biedy. Czasem jednak trzeba zmian dokonać w różnych miejscach
    layoutu - wyświetlać oprócz podsumowań jakieś alerty, wyróżnienia itp.
    Sądzę, że ten wariant z przeładowaniem będzie ok. A już w szczególności,
    że łatwo można odtworzyć pozycję scrolli więc użytkownik może nawet nie
    zorientować się, że było to przeładowanie.

    >> Ajax raczej sam "wiedzieć" nie może jaki kształt ma przyjąć
    >> zaktualizowany wiersz.
    >
    > Tu nie wiem co masz na myśli.

    Np. jeśli Ajax spowoduje usunięcie jakiegoś wiersza, to inne rekordy w
    całej tabeli się pojawią. A jakie - tego sam Ajax nie wymyśli. A może po
    tej operacji jakiś inny wiersz będzie wyróżniony aby użytkownik na niego
    zwrócił uwagę itp? Logika serwera bada jak ma wygenerować stronę
    odpowiedzi i wysyła ją. Gdyby Ajax miał to robić to musiałby podmienić
    wszystko: łącznie z headem, CSS, kodem JS itp. bo nie chcę zakładać
    żadnych ograniczeń. Częściowo o tym poniżej wspominam.

    >> Zresztą programistycznie byłoby trudno przysłać
    >> tylko ten jeden poprawiony wiersz tabeli. bo być może jakieś
    >> podsumowania trzeba będzie na nowo liczyć więc tym bardziej wydaje się
    >> to odświeżenie konieczne. Czy dobrze kombinuję?
    >
    > Trudno czy nie, to zależy. Masz dwie warstwy: przeglądarkę klienta i
    > serwer.
    > Możesz od razu javascriptem (dodany, czy poprawiony) rekord dopisać do
    > tabeli i javascriptem sobie przeliczyć podsumowanie - po stronie
    > klienta.

    Zaryzykowałbyś? :-) Po jakiejś aktualizacji przeglądarki coś przestanie
    działać i leży podsumowywanie. Jestem zwolennikiem minimalizacji
    funkcjonalności realizowanej po stronie przeglądarki.



  • 29. Data: 2012-12-26 19:55:11
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Borys Pogoreło <b...@p...edu.leszno>

    Dnia Sun, 23 Dec 2012 18:40:48 +0100, Marek napisał(a):

    >> Wystarczy pilnować nagłówka X-Requested-With, wiekszość bibliotek dodaje
    >> go automatycznie.
    >
    > Nie sprawdzałem: goły Ajax też ustawia ten nagłówek? Nie stosuję
    > bibliotek. Metoda wydaje mi się sprytna i w tym kierunku pójdę. Dzięki
    > za podpowiedź :-)

    ZTCP to ten nagłówek trzeba dodać samodzielnie, to chyba taki nieformalny
    standard. Ale znacząco ułatwia identyfikację źrodła zapytania, bez
    konieczności modyfikacji adresu.

    --
    Borys Pogoreło
    borys(#)leszno,edu,pl


  • 30. Data: 2012-12-26 20:01:21
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Borys Pogoreło <b...@p...edu.leszno>

    Dnia Sun, 23 Dec 2012 18:51:49 +0100, Marek napisał(a):

    >> narzędziu, które ma zupełnie inną filozofię działania. Widać to po tych
    >> kombinacjach z przekierowaniami. Przyjmij, że masz do dyspozycji tylko
    >> zapytanie-odpowiedź i świat stanie się prostszy.
    >
    > Musisz mi to na polski przełożyć :-)

    Mam wrażenie, że próbujesz wpleść do tej komunikacji elementy, które nie
    powinny być jej częścią, jak właśnie reakcję na przekierowania. Przyjmij,
    że z serwera zawsze dostaniesz jakieś czytelne dane. Jeśli ich nie ma, to
    wystąpił błąd. A wszelkie dane o przekierowaniach, wynikach operacji, ew.
    komunikatach lub wręcz cała nowa zawartość strony powinny być zawarte w
    tych danych. I już dalej kod po stronie klienta niech sobie z tym radzi.

    > Zależy mi na tym aby serwer zwracał HTML przede wszystkim. Chodzi o
    > możliwość budowania i modyfikowania wyglądu okien w edytorach WYSIWYG.
    > Zapewne dojdą inne formy komunikacji w miarę potrzeb ale bazą chcę
    > uczynić HTML.

    Kombinujesz z rozszerzeniem funkcjonalności edytora WYSIWYG czy operujesz
    na edytowanej zawartości?

    > Czy takie podejście może być jeszcze łatwiejsze? Czy nie utrudniam sobie
    > czegoś?

    Zawsze można poszukać gotowca ;)

    --
    Borys Pogoreło
    borys(#)leszno,edu,pl

strony : 1 . 2 . [ 3 ] . 4


Szukaj w grupach

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: