Omówienie modelu zabezpieczeń programu Flash Player 10 do przesyłania plików

Question

Czytałem o ograniczeniach zabezpieczeń dotyczących przesyłania plików w programie Flash Player 10. Zgodnie z FileReference docs for upload(), przesyłanie nie musi być uruchamiane przez akcję zainicjowaną przez użytkownika (funkcja browse() ma, ale to już inna historia). Jeśli tak, to zmusiłoby to niezręczne wrażenia użytkownika w przypadku wysyłania wielu plików, ponieważ może nastąpić tylko jedno przesyłanie naraz - więc użytkownik musiałby kliknąć (lub nacisnąć przycisk) raz na plik, aby rozpocząć przesyłanie, ale tylko po zakończeniu poprzedniego przesyłania pliku.

documentation for URLLoader.load(), z drugiej strony, stwierdza:

W programie Flash Player 10 i później, jeśli użyty zostanie wieloczęściowy Content-Type (dla przykład "wieloczęściowy/form-data"), które zawiera wczytywania (wskazywane przez parametr „filename” w „content-Disposition” nagłówka w organizmie POST ), operacja POST podlega regułom zabezpieczeń zastosowanym do przesyłanych:

operację POST należy wykonać w odpowiedzi na użytkownika -inicjowana akcja, taka jak kliknięcie myszą lub naciśnięcie klawisza.

This Flash Security article potwierdza dokumentację URLLoader (patrz rozdział "post API").

Oryginalny whitepaper jednak nie wskazuje, to - tylko że FileReference przeglądania musi być w odpowiedzi na działania użytkownika, a nie (potencjalnie URLLoader-driven) przesłać sobie:

Gdy plik SWF używa FileReference.browse() i FileReference.upload() metod, aby przesłać plik na serwer, odtwarzacz Flash wymusza dwie reguły zabezpieczeń:

• FileReference.browse() musi zostać wywołany z poziomu obsługi zdarzeń zdarzeń użytkownika (zdarzenia myszy lub klawiatury).

[...]

Flash Player wymusza te same zasady każdym razem, gdy sieci API jest powołany do wykonywania testu POST, który pojawia się z serwerem aby zawierać przesyłanie.

O ile mogę powiedzieć od rzeczywistego wykorzystania API URLLoader przekazać plik, gdy przesłane rzeczywiście nie muszą pochodzić z działania użytkownika; ale czy to dlatego, że używam wersji debugującej odtwarzacza, czy też dokumentacja jest nieprawidłowa? (Lub coś innego?)

TL; DR: Dokumentacja zawiera sprzeczne informacje i nie ufam moim testom terenowym (w obliczu dokumentów, które mówią, że nie powinny działać). Czy można użyć URLLoader do przesłania pliku bez interakcji użytkownika? Czy tylko FileReference? (To zabiłoby większość możliwości wstępnego przetwarzania plików, i właśnie to mnie zainteresowało!)

Answer 1

Nie masz błędów, ponieważ używasz debugowania. Mam ten sam problem podczas pracy nad moim projektem szybkiego testu.
więc na pytania:

• FileReference nie mogą przesyłać pliki bez interakcji z użytkownikiem.
  

• URLLoader nie może przesyłać pliki bez interakcji z użytkownikiem, jeśli używasz POST, multipart/form-data i filename właściwości.

• Możesz przesyłać pliki z URLLoader, jeśli używasz typu zawartości, takiego jak application/octet-stream i umieszczasz treść pliku (na przykład w base64) we własnym żądaniu. Oznacza to, że jeśli używasz PHP, nie będziesz pracować z $_FILES, ale z tablicą $_POST, aby pobrać swój plik.

• Praca w trybie debugowania na komputerze lokalnym nie spowoduje wyświetlenia błędu ograniczenia URLLoader.

Answer 2

Wierzę, że Adobe chce mieć to, aby NIE można było użyć URLLoader do przesłania pliku bez interakcji. Po prostu uważam, że nie zrobili tego w najlepszy sposób i możesz ominąć to w zależności od tego, jak dokładnie używasz URLLoader'a, aby przesłać plik (jeśli umieścisz plik w POST dla URLLoader, powinien on się pomylić, ale możesz obejść to przez kodowanie pliku Base64 i wysłanie go za pomocą URLLoader do php).

Spójrz na this post. Przeczytaj tam także komentarze, które wydają się rozwiązywać problem. Mam nadzieję, że to trochę pomaga.