Přesměrování na stejný presenter/akci s ne-rawurldecodovanými parametry?

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
pavelplzak
Člen | 21
+
0
-

Zdravím, mám takový podivný problém, který zřejmě souvisí s nějakým vnitřním fungováním Nette.

Máme na portále API pro mobilní aplikaci, aplikace posílá požadavky na určitou URL. Mám pro to vyčleněn ApiModule s konkrétními presentery s akcemi pro jednotlivé požadavky. Problém je v tom, že při zavolání požadavku ze strany aplikace, konkrétně např. vložení objednávky, se objednávka vloží 2×. První mě napadlo, že aplikace posílá požadavek 2×, ale při zkopírování adresy požadavku do prohlížeče se vloží 2× taky. Když nechám v metodě pro vložení objednávky něco vypsat, vypíše se to pouze 1× (objednávka se ale vloží 2x), když ale skript na konci metody zabiju, vloží se objednávka pouze jednou. Z čehož jsem usoudil, že tam někde dojde k nějakému přesměrování na ten samý presenter/akci.

Požadavek, který se volá vypadá takto:

http://example.com/api/order/add-order?token=6a7cf6e9bd94739f9f549a40a5f18ba3ed0a79bde813775868258d0d1d827446&providerId=2&customerId=56&placeId=2&datetime=2013-08-30 00:00:00&duration=30&services[]=193&note=&address=praha

Tuším, že by to mělo nějak souviset s podobou toho požadavku. Když ho zavolám přes prohlížeč, změní se v adresním řádku na

http://example.com/api/order/add-order?token=6a7cf6e9bd94739f9f549a40a5f18ba3ed0a79bde813775868258d0d1d827446&providerId=2&customerId=56&placeId=2&datetime=2013-08-30+00%3A00%3A00&duration=30&services[0]=193&address=praha

hádám, že tam dojde tedy k nějakému escapování parametrů a přesměrování? Když pak tuto upravenou URL zavolám znovu, objednávka už se vloží jenom jednou. Co jsem si s tou URL zkoušel hrát, musí být escapovaná hodnota parametru datetime, pole services musí mít vyplněný klíč a nesmí tam být prázdný parametr (zde např. „note“). Dá se toto chování nějak ošetřit u mě, nebo vyžadovat po vývojáři aby posílal parametry URL v požadovaném tvaru? Je nějaká možnost takhle upravit celou url požadavku naráz (nějakou funkcí)?

Díky.

Editoval pavelplzak (8. 8. 2013 12:25)

frosty22
Člen | 373
+
0
-

Řekl bych že jde o kanonizaci URL tj. aby na každou stránku vedl pouze jeden link, kvůli duplicitě obsahu z hlediska vyhledáváčů – z pohledu tedy nette aby na každou stránku se stejnými parametry byl jeden link v případě že není přesměruje na správnou URL.

Přesto však toto se přesměrovává ještě před zavolání action, neměníš náhodou parametry presenteru uvnitř dané action? Pokud například máš persistentní parametr (ale měli by to dělat asi všechny) a poté ho změníš uvnitř action tak se přesměruje znovu sama na sebe s konkrétní hodnotou.

Edit: Případně toto jde vypnout, což tedy jelikož se u tebe jedná o API tak by to nemělo ničemu vadit přes: $presenter->autoCanonicalize = FALSE

PS: Příště polož tu otázku jednodušeji na způsob volá se mi 2× action, přesměrovává sama na sebe .. tím si zaručíš rychlejší odpověď, když vidím dlouhou otázku, tak se mi většinou to nechce číst :)

Editoval frosty22 (11. 8. 2013 1:58)

Elijen
Člen | 171
+
0
-

frosty22 napsal(a):
Pokud například máš persistentní parametr (ale měli by to dělat asi všechny) a poté ho změníš uvnitř action tak se přesměruje znovu sama na sebe s konkrétní hodnotou.

Na tohle už jsem taky narazil a je to teda dost WTF pro někoho, kdo o tom neví.

frosty22
Člen | 373
+
0
-

Lol, staří známý s firmy se sešli že Péťo, Pavle :)

No na jednu stránku to asi určitě může překvapit, zvláště když je to v nějakém procesu, který by se neměl replikovat, ale na druhou stránku by se měla udržovat konzistence URL a requestu, právě kvůli duplicitě obsahu.

Řešením by mohlo být buď výrazná informace v dokumentaci, ikdyž tu zase každý nečte a se na to hned zapomene, ikdyž lepší řešení mě moc nenapadá. Leda že by nešlo persistentní parametry přímo měnit čili by museli být někde uvnitř nette a nastavovat je přes nějaký setter, který by měl výstižnější jméno setPersistentParameterAndRedirectIfIsChanged($parameter) :D No bohužel mě nenapadá řešení.