W piątek ESRI wypuściło nowe API dla JavaScript, poprawiające pewne funkcje jak i w końcu wykonujące odpowiednie operacje – przy query zamiast robić POST zaczęli robić GET, tak jak należy :)

Jak się jednak okazało, zupełnie przypadkiem zmiana ta spowodowała, że przestała działać nasza aplikacja. Dosłownie, wystarczyło zmienić numerek wersji API i wszystko śmigało. Co lepsze na innej aplikacji wykorzystującej ten sam kod nowe API działało.

Po trzech godzin analizy znaleźliśmy powód, który uszedł by naszym oczom gdyby nie to, że przypuszczaliśmy, że jest coś nie tak z ciągiem znaków w URLu.

Wprowadzenie

Ogólnie dla wyśnienia kilku spraw, wy dostać się do zabezpieczonego serwera map, w aplikacji należy stworzyć proxy, które następnie przez API od JavaScript jest wykorzystywane – każdy request z API idzie przez to proxy do serwera i z powrotem. Proxy głównie służy przekazywaniu Tokenu autoryzacji jak i przy programowaniu autentykuje użytkownika z systemami dostępnymi w innej domenie. To ostatnie jest potrzebne jedynie przy developmencie i nie ma wpływu na to jak wygląda URL requestu. Wyszikiwanie w ESRI polega na przekazywaniu polecenia WHERE SQL Like – na przykład X LIKE ‘%ala%’ – tak działa każde API ESRI czy to SL czy WPF, innego sposobu przeszukiwania nie ma.

Problem

Okazało się, że jak JavaScript wywoływała nasze proxy, my tworzyliśmy nowy WebRequest za pomocą metody:

WebRequest.Create(url)

Która modyfikowała nasz URL – dokładnie mówiąc query parameters. O dziwo nie było to stricte UrlEncode ale jakieś dziwna podmiana znaków, mianowicie w naszym przypadku mieliśmy styczność z punktami, które w ID posiadają string EFF i tylko te punktu nas interesowały. Więc zgodnie z zasadami ESRI API query wyglądało tak:

SomeID LIKE '%EFF%'

Url przekazywany do naszego proxy wyglądał tak:

http://some.domain/MapServer/Layer/query?WHERE=SomeID+LIKE+'%EFF%'   

wrzucenie go w przeglądarkę zwracało dobre wyniki zarówno dla GET ja i dla POST, jednak WebRequest.Create() zamieniał url na (część query string):

WHERE=SomeID%20LIKE%20'îF%25'
  • %20 – spacja
  • %25 – %
  • î – WTF??????

To WTF okazało się tłumaczeniem %EF.

Naprawdę nie wiem czemu tak się dzieje. To znaczy wiem, że %EF oznacza dany znak, ale czemu %EF jest zamieniany na znak pierwotny a % na %25 tego już nie rozumiem.

Rozwiązanie

Więc jeżeli natraficie na podobny problem to rozwiązaniem jest dość proste, wystarczy zrobić Server.UrlEncode na query string.

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA

3 KOMENTARZE

  1. To ja już się zgubiłem. Wiesz, że %EF to ten dziwny znak, % to %25 to co jest niezrozumiałe w tym wszystkim? % też musi być encodowany jeśli po nim nie ma dwóch ‘liter’ szesnastkowych czyni nie jest już zakodowanym znakiem.

    Paweł

  2. to, ze %EF jest juz zakodowanym znakiem, wiec czemu ktos robi na tym decode? a nastepnie na % robi encode. tego nie rozumiem.

    w sensie albo powinno byc robione encode na calosci albo decode a nie encode na jednym a decode na drugim – tak przynajmniej uwarzam.

Comments are closed.