2012-01-10 13 views
7

मेरे पास एक PHP अनुप्रयोग है जो सत्रों पर बड़े पैमाने पर निर्भर करता है। अब हम अपने उपयोगकर्ताओं के लिए एक एपीआई बनाने पर विचार कर रहे हैं। हमारे शुरुआती विचार यह हैं कि उपयोगकर्ताओं को एपीआई के खिलाफ अपने ईमेल पते, पासवर्ड और एपीआई कुंजी (प्रत्येक उपयोगकर्ता के लिए अद्वितीय) के साथ प्रमाणित करने की आवश्यकता होगी।PHP एपीआई प्रमाणीकरण और सत्र

हालांकि, वर्तमान एप्लिकेशन (मॉडल समेत) उपयोगकर्ता सत्रों पर व्यापक रूप से निर्भर करता है, मुझे सबसे अच्छा तरीका नहीं है।

यह मानते हुए कि एक API अनुरोध को सही प्रमाणित है, यह स्वीकार्य होंगे:

  • प्रारंभ API कॉल के लिए सत्र एक बार उपयोगकर्ता
  • भागो मॉडल प्रमाणीकृत और उपयोगकर्ता के लिए JSON/XML लौट रहा है
  • सत्र

इसका मतलब है कि सत्र प्रत्येक API कॉल के लिए instantiated हो जाता है, और फिर तुरंत प्लावित मार। यह ठीक है? या क्या हमें अन्य विकल्पों पर विचार करना चाहिए?

+0

आप सही हैं, एपीआई स्टेटलेस होना चाहिए और यदि संभव हो तो सत्र/कुकीज़ का उपयोग न करें। लेकिन यह आसानी से किया जा सकता है, कोई समस्या नहीं है। हालांकि, आपको मौजूदा प्रमाणीकरण ढांचे का पुन: उपयोग करना चाहिए, क्योंकि यह वास्तव में जटिल है। उदाहरण के लिए, https://github.com/delight-im/PHP-Auth पर एक नज़र डालें जो ढांचा-अज्ञेयवादी और डेटाबेस-अज्ञेयवादी दोनों है। फिर प्रत्येक अनुरोध के साथ प्रमाण पत्र भेजें और सर्वर (1) लॉग इन करें, (2) वास्तविक कार्य करें और अंत में (3) फिर से लॉग आउट करें। – caw

उत्तर

1

एपीआई बनाने के अपने अनुभव में, मुझे यह पता चला है कि सत्र केवल एक अनुरोध के लिए आखिरी है और प्रत्येक निष्पादन चक्र में सत्र जानकारी को फिर से बनाना है।

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

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