Marek <p...@s...com> napisał(a)
> W dniu 2012-12-20 17:24, Tomek Kańka pisze:
>
>> Może wynika to z tego, że nie znam PHP i w związku z tym nie rozumiem
>> Twojego mechanizmu, ale...
>
> W zasadzie jest podobnie jak w ASP, jeśli go znasz.

Też nie:). Pisze w Javie, a osatnio głownie w GWT, więc tematyka
ajax-owa jest mi bliska.

> [...]
> No w zasadzie w poprzednim dialogu dałeś mi do myślenia. W zasadzie Ajax
> może odebrać kod 3xx i przekierować przeglądarkę. Wtedy można nadal
> utrzymywać komunikację na dotychczasowym poziomie, w której tajne dane
> przemieszczają się w obrębie sesji między modułami. Tak więc
> ukierunkowałeś mnie :-)
>

Ciesze się, że trochę pomogłem, choć przyznam, że wciąż mam kłopot ze
zrozumieniem Twojego problemu:). Co ja chciałem głownie przekazać, to że
nie widzę żadnej róznicy ajax vs link vs submit z punktu widzenia
bezpieczeństwa,

--
Tomek

do góry

W dniu 2012-12-20 23:12, Tomek Kańka pisze:
>
> Ciesze się, że trochę pomogłem, choć przyznam, że wciąż mam kłopot ze
> zrozumieniem Twojego problemu:). Co ja chciałem głownie przekazać, to że
> nie widzę żadnej róznicy ajax vs link vs submit z punktu widzenia
> bezpieczeństwa,

Diabeł tkwi w szczegółach. Zupełnie inna jest implementacja obu tych
sposobów przetwarzania treści. Ajaxa używałem do tej pory sporadycznie
do realizacji pierdół typu kalendarze itp. Teraz mam poważniejsze
wyzwanie. Muszę zadbać o kwestie bezpieczeństwa. Nie bardzo potrafiłem
wymyślić koncepcję przepływu informacji po stronie serwera stymulując ją
Ajaxowymi okienkami bez przekazywania do Ajaxa danych, które nie powinny
trafiać do przeglądarki.

do góry

Wiem, że to trochę enigmatyczne. Aby to wyjaśnić musielibyśmy najlepiej
usiąść przy projekcie i zademonstrować na żywym projekcie jakie są
implikacje zastosowania obu tych metod. Wtedy łatwiej byłoby dyskutować.
Tak czy owak nasza rozmowa nakierowała mnie na rozwiązanie niezależnie
od tego czy udało mi się przekazać mimo starań szkic problemu czy nie :-D

do góry

On 2012.12.21 11:10, Marek wrote:

> Tak czy owak nasza rozmowa nakierowała mnie na rozwiązanie
> niezależnie od tego czy udało mi się przekazać mimo starań szkic
> problemu czy nie :-D

A ja myślę że przekombinowałeś, też nie widzę różnicy czy to normalny
request czy przez ajax.


--
Tomek
http://www.ttmath.org

do góry

W dniu 2012-12-21 12:15, Tomasz Sowa pisze:
> On 2012.12.21 11:10, Marek wrote:
>
>> Tak czy owak nasza rozmowa nakierowała mnie na rozwiązanie
>> niezależnie od tego czy udało mi się przekazać mimo starań szkic
>> problemu czy nie :-D
>
> A ja myślę że przekombinowałeś, też nie widzę różnicy czy to normalny
> request czy przez ajax.
>
>

Z pewnością przekombinowałem. Jednakże co do braku różnic w obsłudze
requestów nie zgodzę się. Problem jest w tym, że otwarcie Ajaxa ma
stronie nie zmienia jego URL. A więc w konsekwencji Ajax musi
komunikować się albo z innym URL (wtedy różnica jest oczywista) albo
jeśli z tym samym URL, to od strony skryptu PHP trzeba to uwzględnić.
Przykładowo jeśli przyjmujemy model transakcyjny obsługi formularzy,
gdzie ID transakcji zmienia się przy każdym requeście, to zobacz co się
dzieje:
1. PHP otwiera sobie formularz i ustawia w nim ukryte pole z ID bieżącej
transakcji.
2. Gdy submitujemy ten formularz, to PHP sprawdza czy ID transakcji się
zgadza z bieżącym ID w systemie.
3. Gdy teraz Ajax wtrącimy pomiędzy punkty 1 i 2, który ma za zadanie
zmodyfikować wartość jakiegoś pola tego formularza, to jego request
zmieni ID bieżącej transakcji na kolejny. Próba submitowania formularza
w p. 2 nie powiedzie się.

To pokazuje, że do obsługi równoległych requestów od Ajaxa trzeba
wprowadzić odrębne zarządzanie transakcjami lub w ogóle ich nie
obsługiwać dla tego typu wywołań. A więc taki model programistyczny
będzie wymagał sporych przeróbek.

Gdybyśmy zrezygnowali z Ajaxa na rzecz klasycznego podejścia to sprawa
się upraszcza.

1. PHP otwiera sobie formularz i ustawia w nim ukryte pole z ID bieżącej
transakcji.

2. Klikamy opcję ustawiania pola i zamiast Ajaxa otwiera się nam inny
URL z formularzem i nowym ID transakcji. Formularz z p. 1 znika tym
samym. Submitujemy ten nowy formularz i wracamy do poprzedniego URL.

3. Znów się otwiera formularz z p.1 lecz z aktualnym numerem ID
transakcji - innym niż w p. 1 i w p. 2 oraz z wypełnionym polem będącym
skutkiem pracy formularza z p.2. Submitowanie tego formularza powiedzie
się teraz.

do góry

On 2012.12.21 19:38, Marek wrote:

> Przykładowo jeśli przyjmujemy model transakcyjny obsługi formularzy,
> gdzie ID transakcji zmienia się przy każdym requeście, to zobacz co
> się dzieje: 1. PHP otwiera sobie formularz i ustawia w nim ukryte
> pole z ID bieżącej transakcji.

I tylko przy tym requescie ustawiamy ID formularza.

> 2. Gdy submitujemy ten formularz, to PHP sprawdza czy ID transakcji
> się zgadza z bieżącym ID w systemie.

Ok.

> 3. Gdy teraz Ajax wtrącimy pomiędzy punkty 1 i 2, który ma za
> zadanie zmodyfikować wartość jakiegoś pola tego formularza, to jego
> request zmieni ID bieżącej transakcji na kolejny.

To znaczy że to błąd w logice aplikacji (PHP). Po prostu nie modyfikuj
tutaj tego ID.

> Próba submitowania formularza w p. 2 nie powiedzie się.
>
> To pokazuje, że do obsługi równoległych requestów od Ajaxa trzeba
> wprowadzić odrębne zarządzanie transakcjami lub w ogóle ich nie
> obsługiwać dla tego typu wywołań. A więc taki model programistyczny
> będzie wymagał sporych przeróbek.

No a kto powiedział że programowanie to takie proste jest ;)
Naprawdę nie widzę tu problemu.

--
Tomek
http://www.ttmath.org

do góry

W dniu 2012-12-22 13:42, Tomasz Sowa pisze:
>> To pokazuje, że do obsługi równoległych requestów od Ajaxa trzeba
>> wprowadzić odrębne zarządzanie transakcjami lub w ogóle ich nie
>> obsługiwać dla tego typu wywołań. A więc taki model programistyczny
>> będzie wymagał sporych przeróbek.
>
> No a kto powiedział że programowanie to takie proste jest ;)
> Naprawdę nie widzę tu problemu.
>

No chwila... mówiłeś, że nie ma żadnych różnic w obsłudze requestów, ja
je wykazałem na konkretnym przykładzie a teraz odwracasz kota ogonem i
piszesz, że nie problem zmienić sposób obsługi requestów od Ajaxa aby
działało :-D

do góry

On 2012.12.22 16:39, Marek wrote:

>> No a kto powiedział że programowanie to takie proste jest ;)
>> Naprawdę nie widzę tu problemu.
>>
>
> No chwila... mówiłeś, że nie ma żadnych różnic w obsłudze requestów, ja
> je wykazałem na konkretnym przykładzie a teraz odwracasz kota ogonem i
> piszesz, że nie problem zmienić sposób obsługi requestów od Ajaxa aby
> działało :-D

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 ;)


--
Tomek
http://www.ttmath.org

do góry

W dniu 17.12.2012 o 16:04 Marek <p...@s...com> pisze:

> Witam,
>
> Mam pewien kłopot z zastosowaniem tej technologii przy operacjach
> wymagających bezpieczeństwa. Hipotetyczny przykład:

Cokolwiek robisz, robisz to źle. Serio i bez złośliwości.
A po przeczytaniu całości dyskusji z Tomaszem stwierdzam, że nie potrafię
ci pomóc :)

--
Izaak

do góry

Dnia Sat, 22 Dec 2012 17:02:06 +0100, Tomasz Sowa napisał(a):

> 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

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

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

do góry