2013-01-31 35 views
9

मुझे क्रॉस-डोमेन AJAX अनुरोधों के साथ कोई समस्या है।

इस मुद्दे में तीन सर्वर शामिल हैं। हम उन्हें ए 1, ए 2, और बी पर कॉल कर सकते हैं।

A1 और ए 2 एक ही आवेदन कोड चल रहे हैं। वे एक ही वेब अनुप्रयोग के दो चरणबद्ध उदाहरण हैं। बी एक और वेब अनुप्रयोग है।

हम बी आवेदन करने के लिए एक वेब अनुप्रयोग से एक क्रॉस-डोमेन AJAX अनुरोध करने के लिए की जरूरत है। हमने सीओआरएस को सक्षम करने के साथ प्रयोग किया लेकिन आईई < = 8 में संतोषजनक ढंग से काम करने में कठिनाइयों का सामना करना पड़ा, इसलिए अब हम एक nginx proxying नियम का उपयोग कर रहे हैं। प्रवाह इसलिए है: ब्राउज़र ajax अनुरोध ->A1 या ए 2 -> nginx प्रॉक्सी ->बी

बी स्टेटफुल है और कार्य करने के लिए उपयोगकर्ता के सत्र कुकी की आवश्यकता है।

हम जो देख रहे हैं कि इस ठीक से काम करता है जब सर्वर A1 का उपयोग कर, लेकिन जब सर्वर ए 2, बी का उपयोग कर कुकीज़ बाहर खींच नहीं कर सकता है।

मैं अनुरोध A1 और से आने वाले ए 2 के लिए हेडर पर ध्यान दिया है और वे एक ही हैं। दोनों शीर्ष लेख में कुकीज़ लाइन आदि

है, दोनों एक ही मूल है, बी पर क्या हम देखते हैं कि $ _COOKIE [ 'session_key'] खाली जब अनुरोध से आता है ए 2 लेकिन ठीक से भर जाता है जब अनुरोध ए 1 से आता है।

अजीब बात यह है कि हेडर में कुकीज़ से बाहर एक विशेष कुकी कुंजी खींचने में केवल गायब है, और केवल तभी जब अनुरोध ए 2 से आता है। यह ए 2 ठीक से हेडर में हर दूसरी कुकी को पार करता है, यह किसी कारण से उपयोगकर्ता की सत्र कुकी को पार्स नहीं कर सकता है, लेकिन अगर अनुरोध ए 1 से आता है तो यह ठीक हो सकता है।

मैंने टीसीपीडम्प का उपयोग किया है और इनमें से प्रत्येक का पीसी लिया है और उन्हें अलग किया है और हेडर में कुछ भी विशेष रूप से अलग दिखता है।

मुझे यह स्टैक ओवरफ़्लो प्रश्न मिला और लोगों ने कहा कि ऐसा इसलिए था क्योंकि उनकी कुकी हेडर स्ट्रिंग बहुत लंबी थी: What could cause cookie to not be set in $_COOKIE when it's in $_SERVER मुझे नहीं लगता कि यह बहुत लंबा है क्योंकि मेरा सफल और असफल दोनों मामले में केवल 24 9 वर्ण लंबा है।

मैं बिंदु जहां मैं उन्हें पार्स करने $ _SERVER से बाहर कुकीज़ फाड़ पर विचार कर रहा हूँ और मैन्युअल रूप से कर रहा हूँ लेकिन वह वास्तव में बेवकूफ लग रहा है और मैं अंतर्निहित मुद्दे यह पता लगाने की पसंद करेंगे।

+0

उपयोगकर्ता को ए 1 और ए 2 सर्वर दोनों पर सेट करने के लिए सेट नहीं किया जाता है? सर्वर पर सत्र डेटा कैसे बनाया जा रहा है? क्या वे एक ही मशीन हैं? – voncox

उत्तर

0

पीएचपी गलती यहाँ नहीं था।

हम Kohana का उपयोग कर रहे थे और यह प्रारंभ में कुछ कोड रन सत्र कुकी के लिए अतिरिक्त सुरक्षा जोड़ने के लिए प्रयास करने के लिए किया था। प्रश्न में कोड सत्यापित किया गया है कि सर्वर पक्ष में सत्र में दर्ज आईपी पता अनुरोध शीर्षकों में भेजे गए आईपी पते से मेल खाता है।

हमारे नेटवर्क कॉन्फ़िगरेशन के कारण, सर्वर बी से संपर्क करते समय मुझे एक बाहरी आईपी प्राप्त हुआ, ए 2 से संपर्क करते समय एक आंतरिक आईपी, और ए 1 से संपर्क करते समय बाहरी आईपी।

जब ए 2 ने आंतरिक आईपी के साथ अनुरोध को अग्रेषित किया, तो उसने कोहाना की आईपी-आधारित कुकी सुरक्षा को ट्रिगर किया क्योंकि कुकी मेरे बाहरी आईपी के साथ बनाई गई थी लेकिन अब मेरे आंतरिक आईपी द्वारा उपयोग करने की कोशिश की जा रही है।

0

आईई < = 8 का उपयोग करते समय एक समस्या कुछ है जिसे P3P कहा जाता है। मैं ने पाया है कि जिन पृष्ठों पर आपके AJAX/JSON अनुरोध (अपने उदाहरण में सर्वर बी) को स्वीकार में एक पी 3 पी शीर्षक में गिर इस समस्या का समाधान होगा:

header('P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"'); 

server A2server B करने के लिए $_COOKIE अनुरोध भेजने नहीं के रूप में, मैं सिफारिश करेंगे _GET का उपयोग init पृष्ठ पर server B पर किसी भी प्रकार के अनुरोध से अनुरोध भेज रहा है। इस तरह इसे संसाधित किया जा सकता है, और server B पर संग्रहीत किया जा सकता है। फिर सभी शेष पृष्ठों के लिए जहां यह जानकारी मौजूद होनी चाहिए, आप यह निर्धारित करने के लिए server B देख सकते हैं कि जानकारी भेजी गई है या लगातार _GET डेटा प्रत्येक पृष्ठ पर भेजती है और इसे पहले से ही जानकारी के साथ तुलना करें। एक अनुस्मारक के रूप में, इस जानकारी की सख्ती से निगरानी की जानी चाहिए क्योंकि इसे संशोधित करना बहुत आसान होगा।

मैं क्षमा चाहता हूं, मुझे एहसास है कि यह इस मुद्दे को ठीक नहीं करता है, लेकिन वैकल्पिक समाधान प्रदान कर सकता है।

+1

यह केवल आईई नहीं, सभी ब्राउज़रों में होता है। मुझे लगता है कि एक वर्कअराउंड मैन्युअल रूप से $ _SERVER ['HTTP_COOKIE_VARS'] को पार्स कर देगा, केवल अगर अनुरोध ए 2 द्वारा अग्रेषित किया गया था, लेकिन मैं अंतर्निहित समस्या – ashgromnies

+0

ढूंढना पसंद करूंगा अन्य कारणों से पी 3 पी हेडर परिवर्तन काम नहीं करेगा क्योंकि हम ' उस परिस्थिति में फिर से चलना आईई की XDomainRequest वस्तु की एक सीमा है। यह * सभी * पर कुकीज़ का समर्थन नहीं करता है। यह नरक के रूप में टूटा हुआ है, इसलिए हमें इसके बजाय प्रॉक्सी करना है। – ashgromnies

0

कुछ समय पहले, मुझे क्रॉस-डोमेन AJAX अनुरोध करना था। जाहिर है, मेरे पास एक ही समस्या थी जब मैंने आईई के साथ "एक्स-डोमेन AJAX" की अनुमति देने के लिए हेडर सेट करने का प्रयास किया (बिल्कुल हेडर नाम याद नहीं है)।

इस सॉर्ट किए जाने के लिए मैंने क्या किया, सर्वर के AJAX के बीच CURL का उपयोग करना है। तो इस तरह, मेरी AJAX स्क्रिप्ट (PHP में लिखी गई), जेएसओएन + कर्ल के माध्यम से सर्वर के माध्यम से डेटा का आदान-प्रदान करने में सक्षम थीं, एक कर्ल पोस्ट करके भेजकर, और कर्ल जीईटी के माध्यम से डेटा को रिटायर करने में सक्षम थे, भले ही डोमेन शामिल थे।

कृपया मुझे क्षमा करें, शायद यह वास्तव में आपको आवश्यक उत्तर नहीं है, लेकिन, आईएमओ, यह किसी को क्रॉस-साइट AJAX की तलाश करने में मदद कर सकता है।

0

सर्वर के बीच जीईटी का उपयोग करें; बस इतना ही। और हैश प्राप्त करने का एक तरीका बनाएं ताकि यदि कोई सर्वर अनुरोध पूरा करने में विफल रहता है, तो उपयोगकर्ता को वास्तविक कुकी सामग्री को