2012-01-27 8 views
14

मैं एक वेब-आधारित उपकरण पर काम कर रहा हूं जो हमारे कार्यालय में किए गए कार्यों को सुव्यवस्थित करता है। हमारे साथी द्वारा प्रदान किए गए टूल में एक सामान्य लॉगिन होता है जो हमारी पूरी मंजिल का उपयोग करता है, लेकिन यह हर 30 मिनट में समाप्त होता है, जो पूरे दिन फिर से लॉग-इन करने के लिए परेशान होता है।

जो मैंने पहले किया था, वह मेरे उपकरण के अंदर एक छिपा हुआ आईफ्रेम बना रहा था जो पृष्ठ लोड पर एक छिपी हुई फॉर्म सबमिट करके इसमें लॉग इन करता है, और टाइमआउट को रोकने के लिए हर 30 मिनट में फॉर्म जमा करना जारी रखता है। फिर वे मेरे टूल से सीधे पार्टनर टूल में खोज सबमिट कर सकते हैं (दूसरे के माध्यम से, दृश्यमान फॉर्म)।

मैं छिपे हुए आईफ्रेम से छुटकारा पाने के लिए jQuery $.post() का उपयोग करना चाहता हूं, और इसे एकमात्र बार लॉगिन जानकारी सबमिट करने का एकमात्र समय है जब कोई खोज हो रही है। इस तरह यह उपयोग में नहीं होने पर लगातार अनुरोध भेज नहीं रहा है, लेकिन आप अभी भी लॉगिन समय के बारे में चिंता किए बिना खोज चला सकते हैं।

ऐसा लगता है कि AJAX समान मूल नीति इसे रोक रही है, इसलिए फिलहाल मैं इसे एक नई नाम वाली विंडो खोल रहा हूं, और फिर एक दूसरे के बाद एक लक्ष्य विंडो में दो छिपे हुए फॉर्म जमा कर रहा हूं।

इसके साथ समस्या यह है कि अगर लॉगिन अनुरोध समाप्त नहीं हुआ है, तो खोज अनुरोध नहीं जाता है, और उन्हें फिर से लॉगिन पृष्ठ पर लाया जाता है। अगर वे खिड़की को बंद करते हैं और फिर से खोज करते हैं तो यह काम करेगा, लेकिन यह भी कष्टप्रद है, जितना मूल स्थिति उतना ही नहीं।

तो इस तथ्य के अलावा कि आपको वास्तव में पृष्ठ को खोलना है (जब तक कि यह एक छिपी हुई आईफ्रेम में न हो) $.post() के माध्यम से पैरामीटर सबमिट करने और POST विधि का उपयोग करके फ़ॉर्म सबमिट करने के बीच क्या अंतर है? वे फायरबग में समान दिखते हैं। क्या कोई तरीका है कि मैं फॉर्म सबमिशन पर कॉलबैक स्थापित कर सकता हूं, तो यह दूसरा शुरू करने से पहले पूरा करने के पहले अनुरोध की प्रतीक्षा करता है?

उत्तर

21

$। पोस्ट डेटा भेजने के लिए xmlhttprequest का उपयोग करता है। Xhr कोर के माध्यम से प्रतिबंधित है। सीधे HTTP पोस्ट अनुरोध भेजना नहीं है।

+0

मुझे नहीं लगता कि यह क्यों मतदान किया गया था। मुझे सही लगता है। +1 –

+0

डाउनवोट हटा दिया गया।मैंने सोचा था कि उपयोगकर्ता एक स्पष्टीकरण मांग रहा था * क्यों * केवल एक्सएचआर के पास प्रतिबंध हैं - यह समस्या है यदि विषय एक पूर्ण प्रश्न है जो शरीर से अलग है और लोग केवल विषय को ध्यान से पढ़ते हैं: पी – ThiefMaster

+0

सीधे ऊपर भेजने का तरीका है वास्तव में पृष्ठ खोलने के बिना HTTP POST अनुरोध? – sicks

-2

AJAX समान मूल नीति नेट पर आपकी जानकारी को अपने निजी सर्वर पर भेजने को रोकना है, बिना आपको इसके बारे में पता होना चाहिए। अन्य सर्वरों के लिए पेज पोस्ट की अनुशंसा नहीं की जाती है, और विफल हो सकती है।

क्या आप इसे हल कर सकते हैं? आप लॉगिन स्थिति को पूरा होने के लिए jq के साथ जमा फॉर्म को प्रतिस्थापित कर सकते हैं, और फिर फॉर्म सबमिट कर सकते हैं, हालांकि, मुझे यकीन नहीं है कि यह एक अच्छा विचार है - स्पिन लूप आमतौर पर एक डिज़ाइन त्रुटि इंगित करता है।

आपके पास कोड पर कितना नियंत्रण है? क्या आप सबमिट कर सकते हैं एक लॉगिन करते हैं, और बदले में खोज भेजते हैं? या खोज को लॉगिन की आवश्यकता नहीं है?

+0

अभी यह लॉगिन सबमिट करता है, और फिर खोज, लेकिन यह जानने का कोई तरीका नहीं है कि खोज करने से पहले लॉगिन अनुरोध पूरा हो गया है या नहीं। – sicks

+0

"अन्य सर्वरों के लिए पृष्ठ पोस्ट की अनुशंसा नहीं की जाती है, और विफल हो सकती है।" <कई सारे पेज (और वास्तव में प्रोटोकॉल, जैसे कि SAML) अन्य सर्वरों पर फॉर्म पोस्ट का उपयोग करते हैं। यह सिफारिश कहां है? – metadaddy

15

किसी अन्य डोमेन पर POST अनुरोध करते समय, आप जावास्क्रिप्ट के साथ प्रतिक्रिया तक पहुंच नहीं पाएंगे (भले ही आप फॉर्म को iframe में सबमिट करते हैं)।

एक्सएचआर का उपयोग करते समय, आपके पास प्रतिक्रिया तक पूर्ण पहुंच है, इसलिए आप कई बुरी चीजें कर सकते हैं - उदा। उन पृष्ठों तक पहुंचना जहां उपयोगकर्ता लॉग इन है, अपने कॉर्पोरेट इंट्रानेट इत्यादि में घूमते हुए

तो एक्सएचआर प्रतिबंध सीएसआरएफ से बचने के लिए नहीं बल्कि विशेषाधिकार प्राप्त जानकारी के प्रकटीकरण से बचने के लिए हैं।

+0

क्या आप इसे वापस कर सकते हैं? अगर मैं एक कच्चे http क्लाइंट (जैसे कर्ल) में एक पोस्ट अनुरोध भेजता हूं तो मुझे प्रतिक्रिया तक पहुंच है और मैंने अभी तक आपके द्वारा वर्णित अवसरों को देखना नहीं है। अधिक संसाधनों तक पहुंच के साथ जावास्क्रिप्ट को http लाइब्रेरी पर कैसे लाभ होगा? और क्या होगा यदि मैंने बस एक ब्राउज़र का उपयोग किया जो समान मूल नीति को लागू नहीं करता है, जो क्लाइंट स्तर पर लगाया गया है, सर्वर नहीं? – Anthony

+0

एक HTTP क्लाइंट का उपयोग करते समय * आप * अनुरोध शुरू करते हैं और नियंत्रित करते हैं कि कौन सा डेटा (जैसे लॉगिन कुकीज़) आप भेजते हैं। लेकिन आमतौर पर वेबसाइट पर उपयोग की जाने वाली जावास्क्रिप्ट पर आपका नियंत्रण नहीं होता है। उदाहरण के लिए, यहां स्टैक ओवरफ़्लो पर एक साधारण जीईटी अनुरोध मेरे लिए केवल विशेषाधिकार प्राप्त जानकारी को देखने के लिए पर्याप्त है। अब एक और वेबसाइट (यदि इसे एक्स-फ्रेम-पॉलिसी हेडर के माध्यम से अस्वीकृत नहीं किया गया था) तो ऐसी जानकारी वाले यूआरएल को इंगित करने वाले आईफ्रेम का उपयोग करें - लेकिन उसी मूल-नीति के लिए धन्यवाद, इस पर डेटा तक पहुंचने का कोई तरीका नहीं है पृष्ठ। – ThiefMaster

+0

हां, लेकिन यही कारण है कि वही मूल नीति अच्छी और जगह पर है। आपने इंगित किया है कि AJAX पर फ़ॉर्म पोस्ट किसी भी xhr हमले से अधिक खतरे में सर्वर डालने के जवाब में जेएस पहुंच के कारण अधिक कमजोर थे। मुझे लगता है कि आपका मतलब था कि वही मूल नीति (सामान्य रूप से और ओपी प्रश्न के लिए विशिष्ट नहीं) सर्वर जितनी अधिक उपयोगकर्ता की सुरक्षा करती है। एक वैध बिंदु, लेकिन आपका उत्तर बताता है कि यह पोस्ट बनाने के लिए विशिष्ट है, जो पाठकों को यह सोचने में गुमराह कर सकता है कि समान मूल नीति के अलावा कुछ अन्य तंत्र भी है। – Anthony