2011-10-16 26 views
9

मैं वर्तमान में एक ऐसी साइट विकसित कर रहा हूं जो स्टैंडअलोन चलाता है और एक आईफ्रेम पर एक फेसबुक ऐप के रूप में मैं सोच रहा था कि क्या मेरी जांच करने के लिए "सर्वोत्तम अभ्यास" पृष्ठ लोड होने से पहले फेसबुक आईफ्रेम में पृष्ठ चलाया जाता है, इसलिए मैं प्रासंगिक सीएसएस और अन्य चरकैसे पता चलेगा कि मेरा पृष्ठ किसी फेसबुक आईफ्रेम में चल रहा है या नहीं

धन्यवाद प्रस्तुत कर सकता हूं।

उत्तर

5

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

एक और तरीका है कि साइन-इन अनुरोध का उपयोग चर्चा के रूप में किया जाए, एक कुकी (या सत्र) सेट करना, जब यह फेसबुक पहुंच को इंगित करने के लिए मौजूद हो। यह चाल सुनिश्चित करने के लिए कि प्रत्येक पृष्ठ आईफ्रेम के भीतर है, प्रत्येक पृष्ठ के शीर्ष पर थोड़ा सा जावास्क्रिप्ट कोड भी शामिल करना है। यदि नहीं, तो कोड तुरंत "पेज? Clearfb = 1" जैसे पैरामीटर के साथ वर्तमान पृष्ठ पर रीडायरेक्ट करता है जो सर्वर को कुकी/सत्र को साफ़ करने और पृष्ठ को बाहरी प्रारूप में आउटपुट करने के लिए बताएगा।

+0

मुझे लगता है कि "जावास्क्रिप्ट कोड का थोड़ा सा" आप विंडो.top == विंडो का संदर्भ लेते हैं? –

+3

हां, 'if (window.location == top.location) window.location = 'thispage.php? Clearfb = 1'; 'प्रत्येक पृष्ठ के शीर्ष पर' के साथ कुछ, लेकिन * केवल * यदि सर्वर है वर्तमान में iframe प्रारूप में outputting। और निश्चित रूप से clearfb पैरामीटर का पता लगाने के लिए उचित सर्वर-साइड कोड और उचित प्रतिक्रिया दें। –

+0

@ फ्लॉइड विल्बर्न, बीटीडब्लू 'टॉप.लोकेशन' तक पहुंच रहा है अगर 'विंडो! = Window.top' क्रॉस डोमेन पॉलिसी के कारण डोमेन भिन्न होने पर सुरक्षा चेतावनी बढ़ाएगा। –

2

यहाँ यदि वर्तमान पृष्ठ एक फेसबुक iframe के भीतर चल रहा है परीक्षण करने के लिए कुछ php कोड है:

if(strpos($_SERVER[ 'HTTP_REFERER' ], "apps.facebook.com") !== false){ 
    // Page is running in Facebook iframe 
} 
+4

HTTP_REFERER ब्राउज़र द्वारा भेजा जाता है और बिल्कुल सटीक या बिल्कुल विश्वसनीय होने पर भरोसा नहीं किया जाना चाहिए। – 472084

+0

यह बहुत सच है - बुराई उपयोगकर्ता;) – Lix

+0

यह मेरे लिए सबसे अच्छा और संक्षिप्त दृष्टिकोण है जो केवल सीएसएस की एक पंक्ति जोड़ना चाहता है। –

3

अगर एक signed_request वर्तमान भी एक अच्छा परीक्षण किया जाएगा है देखने के लिए जाँच ...

+2

Sign_request की जांच करना यह जानने का सबसे अच्छा तरीका है कि पृष्ठ फेसबुक फ्रेमवर्क के अंदर है (जैसा कि केवल किसी आइफ्रेम के अंदर होना है) लेकिन याद रखें कि यह केवल पहले लोड पर सेट है। सेटिंग को "जारी रखने" के लिए आपको कुछ रास्ता तय करना होगा क्योंकि उपयोगकर्ता नए पृष्ठों के लिंक का अनुसरण करता है। –

+0

क्यों 'केवल पहले लोड पर सेट करें'? मुझे इस व्यवहार का कोई संदर्भ नहीं मिल रहा है। क्या आप हमें इस जानकारी से लिंक कर सकते हैं? – Lix

+1

मुझे नहीं पता कि यह कहीं भी स्पष्ट रूप से कहा गया है, यह वही तरीका है जिस पर आईफ्रेम सेटअप काम करता है। जब पृष्ठ ढांचे का निर्माण किया जाता है, तो iframe को पैरामीटर के रूप में sign_request के साथ कैनवास यूआरएल में एक पोस्ट भेजकर पॉप्युलेट किया जाता है। यह एकमात्र समय साइन_request स्वचालित रूप से भेजा जाएगा। उसके बाद फेसबुक को फिर से भेजने का कोई तरीका नहीं है, क्योंकि आईफ्रेम तब ऐप के नियंत्रण में है। Sign_request को फिर से भेजा जाने का एकमात्र तरीका पूरे पृष्ठ को पुनः लोड करना है (शीर्ष स्थान या इसी तरह का उपयोग करना) जो वास्तव में कुछ लोग करते हैं, लेकिन यह निश्चित रूप से अनुशंसित नहीं है। –

6
$signed_request = $_POST['signed_request']; 

if(empty($signed_request)) 
     die('No direct access.'); 
1

window.top==window की तुलना करके इसके लिए एकमात्र असली चेक क्लाइंट-साइड पर किया जा सकता है यदि यह सही है तो iframe के बाहर एप्लिकेशन चलाया जाता है।

कोई सर्वर साइड चेक नहीं है जो यह सुनिश्चित कर सकता है क्योंकि ब्राउज़र HTTP_REFERRER के अलावा अन्य सर्वर पर पैरेंट फ्रेम के बारे में जानकारी नहीं दे रहा है जिसे विश्वसनीय नहीं किया जा सकता है।

फेसबुक अपने आवेदन करने के लिए signed_request गुजर अगर पृष्ठ टैब कैनवास की कैनवास पर चल रहा है, लेकिन यह कुछ आप पूरी तरह से भरोसा कर सकते हैं, क्योंकि यह भी उपयोगकर्ता द्वारा मजाक उड़ाया जा सकता है नहीं है।

अद्यतन:

बयान है कि यह केवल वास्तविक जांच मतलब यह नहीं है कि आप इसे का उपयोग करना चाहिए है! आप बेहतर signed_request आधारित समाधान से चिपके रहते हैं, क्योंकि फेसबुक आपके ऐप्स के साथ इंटरैक्ट करने का एक तरीका है, उपयोगकर्ताओं को साइन_रेक्वेस्ट का उपयोग करने का इरादा नहीं है और यह किसी भी परिस्थिति में नहीं होना चाहिए क्वेरी स्ट्रिंग के भाग के रूप में पास किया जाना चाहिए! यदि उपयोगकर्ता इसे नकल कर रहा है, तो शायद कुछ गलत है, मैं उस मामले में गलत स्टाइल प्रदान करने से परेशान नहीं हूं।

+0

यदि इस चेक को करने का एकमात्र कारण अलग-अलग सीएसएस फाइल है, तो आप 'window.top == window' की जांच के बाद से पूरी तरह से लोड होने से पहले सही' लिंक 'टैग इंजेक्शन करके क्लाइंट पक्ष पर लोड कर सकते हैं, किसी भी समय ईवेंट पर काम करेगा डीओएम लोड होने से पहले। –

+0

असल में साइन_रेक्वेस्ट * केवल * विधि है जिसे पूरी तरह भरोसा किया जा सकता है। मुझे नहीं लगता कि मूल प्रश्न वास्तव में सुरक्षा के बारे में है क्योंकि यह विशेष रूप से सीएसएस परिवर्तनों का उल्लेख करता है, लेकिन यह कहना गलत है कि sign_request HTTP_REFERER या जावास्क्रिप्ट विंडो परीक्षणों के समान श्रेणी में है। –

+0

@ फ्लॉइड विल्बर्न, यह उपयोगकर्ता पहचान के लिए भरोसा किया जा सकता है यह सुनिश्चित न करें कि ऐप 'iframe' में चल रहा है। निश्चित रूप से यह अलग श्रेणी है, यह आपके द्वारा भरोसा प्राधिकारी द्वारा सत्यापित है - फेसबुक। –

0

मैं आज सुबह इसी प्रश्न में भाग गया - मैं डेस्कटॉप उपयोगकर्ताओं को फेसबुक के माध्यम से अपने ऐप तक पहुंचने के लिए चाहता हूं लेकिन मैं चाहता हूं कि मोबाइल उपयोगकर्ता सीधे यूआरएल के माध्यम से ऐप तक पहुंच सकें।फ़्लॉइड विल्बर्न की तरह, विभिन्न यूआरएल के माध्यम से ऐप के विभिन्न संस्करणों तक पहुंच एक अच्छा विकल्प है, लेकिन ऐप की दो प्रतियां (बनाए रखने में कठोर) होने के बजाय मैंने ऐप रूट में/फेसबुक निर्देशिका को फिर से लिखने के लिए mod_rewrite का उपयोग किया:

# rewrite both /facebook and/to same place so you 
# can tell if your request came from facebook or from direct URL access :) 
RewriteEngine on 
RewriteBase/
RewriteCond %{REQUEST_URI} /facebook* 
RewriteRule (.*) /index.php [L] 

अपने फेसबुक पेज टैब यूआरएल को/facebook उपनिर्देशिका में जमीन पर सेट करना सुनिश्चित करें। अब, आप यह देखने के लिए ब्राउज़र स्नीफ कर सकते हैं कि वे मोबाइल या डेस्कटॉप उपयोगकर्ता हैं या नहीं, और आप अनुरोध किए गए यूआरएल का परीक्षण कर सकते हैं कि वे फेसबुक के माध्यम से ऐप तक पहुंच रहे हैं या सीधे :)

मुझे जोड़ने दें कि वहां है क्लाइंट प्रकार या एक्सेस पॉइंट को निर्धारित करने के लिए कोई मूर्ख तरीका नहीं है - दोनों को किसी ऐसे व्यक्ति द्वारा धोखा दिया जा सकता है जो जानता है कि वे क्या कर रहे हैं - इसलिए इसे अपने ऐप की सुरक्षा और प्रमाणीकरण तंत्र को डिज़ाइन करते समय ध्यान में रखें।

संबंधित मुद्दे

 संबंधित मुद्दे