1. Brak pliku
Najczęstsza i najprostsza przyczyna, to brak pliku na serwerze. Na serwerze dostarczającym usługi dla aplikacji Silverlight i Flash musi znajdować się plik xml określający dostęp do usług. Dodam tu jeszcze kwestię lokalizacji pliku. Musi się on znajdować w głównym katalogu serwera, bezpośrednio na domenie. Czyli jeśli usługa znajduje się pod adresem:http://domena.com/cos/tam/usluga.aspxto plik powinien znajdować się pod adresem:
http://domena.com/clientaccesspolicy.xml2. Dostępność pliku
Nieco mniej prawdopodobne, ale warte sprawdzenia jest, czy plik jest dostępny z poziomu klienta. Wystarczy sprawdzić, czy nie istnieją jakieś przekierowania dla zapytań klienta. To raczej sporadyczne, ale może się zdarzyć. Znacznie częściej może się zdarzyć, że zapytania o ten plik są przechwytywane przez jakiś Dispatcher i plik nie jest poprawnie serwowany.3. Format pliku
Należy pamiętać, że jest to plik xml i musi być poprawny. Stosunkowo łatwo to sprawdzić, otwierając go w przeglądarce. Zwykle nie ma z tym najmniejszego kłopotu i przeglądarka wskaże czy jest z nim jakiś problem. Odpowiedź na pytanie, gdzie problemu szukać będzie jednak raczej sugestią. Na szczęście zwykle ten plik nie jest duży, więc jego analiza nie powinna nastręczać kłopotów.4.Certyfikaty
Jeśli próbujemy dostać się do usługi na serwerze korzystając z bezpiecznego protokołu https, plik clientaccesspolicy.xml lub crossdomain.xml będzie również pobierany bezpiecznym protokołem. Tutaj może się pojawić problem z certyfikatami. W przypadku problemów z poprawnością certyfikatu serwera, żądanie zostanie anulowane. W aplikacji zostanie wtedy zwrócony wyjątek SecurityException. Jest to spowodowane szansą na wykrycie próby podszycia pod serwer. To samo tyczy się usługi. Z racji jednak, że plik i usługa znajdują się na tej samej domenie, nie ma raczej szans, że certyfikat dla pliku uprawnień się zgodzi, ale nie zgodzi się później dla usługi. No przynajmniej są małe szanse.5. Uprawnienia w pliku
Wreszcie na koniec, ale nie mniej ważne. Sama zawartość pliku ma ogromne znaczenie. Plik clientaccesspolicy.xml może na przykład dopuszczać jedynie żądania przy pomocy bezpiecznego protokołu https, albo dopuszczać wyłącznie żądania z konkretnych domen. Jeśli nie dostaniemy dostępu, również pojawi się wyjątek SecurityException. Nie ma jak stwierdzić z poziomu kodu, że takie ograniczenia istnieją i nie można na nie w locie zareagować. Można najwyżej przyjąć jakieś założenia i spróbować dostępu ponownie, po uprzedniej zmianie adresu, protokołu, portu, itp. Trudności testowania tej sytuacji uważam za dostateczny argument, aby plik dostępu był możliwie najbardziej liberalny.Wyjątek SecurityException należy rozumieć jako brak dostępu do usługi. Niestety nie ma możliwości sprawdzenia z poziomu kodu aplikacji sprawdzić, jaki z przypadków zaistniał. Zwykle każda z przyczyn jest związana ze stałym stanem zasobów po stronie serwera, co oznacza, że powtórzenie błędu nie będzie trudne. Dopiero analiza wyników takiego testu pozwala na znalezienie wszystkich przyczyn takiej sytuacji.
Czytaj też:
Brak komentarzy:
Prześlij komentarz