2012-01-27 8 views
14

Pracuję nad internetowym narzędziem, które usprawnia pracę, którą wykonujemy w moim biurze. Narzędzia dostarczone nam przez naszego partnera mają ogólny login, którym posługuje się cała nasza podłoga, ale wygasa co 30 minut, co jest denerwujące, że trzeba się ponownie logować przez cały dzień.

To, co zrobiłem w przeszłości, było stworzenie ukrytego elementu iframe w moim narzędziu, który loguje się do niego, przesyłając ukryty formularz przy ładowaniu strony i kontynuując przesyłanie formularza co 30 minut, aby zapobiec przekroczeniu limitu czasu. Następnie mogą przesłać zapytania do narzędzia partnera bezpośrednio z mojego narzędzia (za pomocą innego widocznego formularza).

Chciałbym użyć jQuery $.post(), aby pozbyć się ukrytego elementu iframe i sprawić, aby jedyny moment, w którym przesyła on dane logowania, jest po przeprowadzeniu wyszukiwania. W ten sposób nie wysyła ciągłych żądań, gdy nie są używane, ale nadal możesz uruchomić wyszukiwanie bez martwienia się o limit czasu logowania.

Wygląda na to, że polityka ajaxowa tego samego pochodzenia uniemożliwia to, więc w tej chwili mam tylko otwarcie nowego nazwanego okna, a następnie przesłanie dwóch ukrytych formularzy w oknie docelowym jeden po drugim.

Problem polega na tym, że prośba o zalogowanie się nie zakończyła, zapytanie wyszukiwania nie przechodzi, a następnie są one ponownie wyświetlane na stronie logowania. Jeśli zamkną okno i wyszukają ponownie, będzie działać, ale jest to również denerwujące, ale nie tak bardzo jak sytuacja oryginalna.

Czyli poza faktem, że strona musi się otwierać (chyba że znajduje się w ukrytym elemencie iframe), jaka jest różnica między przesyłaniem parametrów za pośrednictwem $.post() a przesyłaniem formularza za pomocą metody POST? Wyglądają identycznie w firebugu. Czy istnieje sposób, w jaki mogę skonfigurować wywołanie zwrotne przy składaniu formularza, więc czeka na zakończenie pierwszego żądania przed rozpoczęciem drugiego?

Odpowiedz

21

$ .post używa xmlhttprequest do wysyłania danych. Xhr jest ograniczone przez cors. Wysłanie prostego żądania HTTP POST nie jest.

+0

Nie mogę zgadnąć, dlaczego ten głos został odrzucony. Wydaje mi się to poprawne. +1 –

+0

Dowolne usunięcie.Myślałem, że użytkownik prosi o wyjaśnienie * dlaczego * tylko XHR ma ograniczenia - to jest problem, jeśli temat jest pełnym pytaniem, które różni się od ciała i ludzie tylko uważnie czytają ten temat: p – ThiefMaster

+0

to sposób na wysłanie prosto Żądanie HTTP POST bez otwierania strony? – sicks

-2

Polityka ajaxowego samopoczucia polega na tym, że przestaniesz wysyłać informacje przez Internet na swój osobisty serwer, bez świadomości, że to się dzieje. Wpisy na strony do innych serwerów nie są zalecane i mogą zawieść.

Czy możesz to rozwiązać? Możesz zastąpić formularz przy pomocy jq, aby poczekać na zakończenie statusu logowania, a następnie przesłać formularz, jednak nie jestem pewien, czy to dobry pomysł - pętla spinowa zwykle wskazuje błąd projektowy.

Ile masz kontroli nad kodem? Czy możesz przesłać logowanie, a po powrocie wysłać zapytanie? Czy może wyszukiwanie nie wymaga logowania?

+0

Teraz przesyła login, a następnie wyszukiwanie, ale nie ma możliwości sprawdzenia, czy żądanie logowania zostało zakończone przed wykonaniem wyszukiwania. – sicks

+0

"Wpisy na strony do innych serwerów nie są zalecane i mogą zawieść." metadaddy

15

Podczas wykonywania żądania POST w innej domenie, nie będzie można uzyskać dostępu do odpowiedzi za pomocą JavaScript (nawet jeśli przesłać formularz do elementu iframe).

Podczas korzystania z XHR masz pełny dostęp do odpowiedzi, więc możesz zrobić wiele złych rzeczy - np. uzyskiwanie dostępu do stron, na których zalogowany jest użytkownik, śledzenie w jego firmowym intranecie itp.

Ograniczenia XHR nie mają na celu uniknięcia CSRF, ale uniknięcia ujawnienia uprzywilejowanych informacji.

+0

Czy możesz z powrotem to zrobić? Jeśli wyślę żądanie postu do surowego klienta http (takiego jak curl), mam dostęp do odpowiedzi i jeszcze nie widzę możliwości, które opisujesz. W jaki sposób javascript ma przewagę nad biblioteką http z dostępem do większej ilości zasobów? A co, gdybym po prostu użył przeglądarki, która nie wymusiłaby tej samej reguły pochodzenia, która jest nałożona na poziomie klienta, a nie na serwer? – Anthony

+0

Podczas korzystania z klienta HTTP * Ty * inicjujesz żądanie i kontrolujesz, jakie dane (np. Pliki cookie do logowania) wysyłasz. Ale zazwyczaj nie masz kontroli nad JavaScriptem, którego używa strona internetowa. Na przykład tutaj, w przepełnieniu stosu, wystarczy proste żądanie GET, aby wyświetlić uprzywilejowane informacje dostępne tylko dla moderatorów. Teraz inna strona mogłaby (jeśli nie została zabroniona przez nagłówek zasad x-frame) użyć iframe wskazującego adres URL zawierający takie informacje - ale dzięki polityce tego samego pochodzenia nie ma możliwości uzyskania dostępu do danych na tej stronie strona. – ThiefMaster

+0

Tak, ale właśnie dlatego polityka tego samego pochodzenia jest dobra i działa. Wskazałeś, że posty w formularzu nad ajaxem są bardziej podatne na ataki ze względu na dostęp Js do odpowiedzi, co naraża serwer na ryzyko bardziej niż jakikolwiek atak Xhr. Myślę, że chodziło Ci o to, że ta sama polityka początkowa (ogólnie rzecz biorąc, a nie specyficzna dla pytania OP) chroni serwer tak samo, jak użytkownika. Prawidłowy punkt, ale twoja odpowiedź sugeruje, że jest to specyficzne dla postów na formularzu, które mogłyby wprowadzić czytelników w błąd, że istnieje inny mechanizm poza tymi samymi regułami pochodzenia. – Anthony