2012-09-01 28 views
8

मैं पिरामिड सुरक्षा मॉड्यूल में अपना पहला प्रयास कर रहा हूं। मैं auth_tkt स्थापित करने के लिए इस लॉगिन कोड का उपयोग कर रहा:पिरामिड। सुरक्षा प्रश्न: डबल कुकीज़? असुरक्षित कुकीज़? समय सीमा समाप्ति?

@view_config(route_name='LoginForm', request_method='POST', renderer='string') 
class LoginForm(SimpleObject): 
    def __call__(self): 

     emailAddress = self.request.params.get('emailAddress') 
     password = self.request.params.get('password') 

     if emailAddress != '[email protected]' or password != 'testpassword': 
      errorDictionary = { 'message' : "Either the email address or password is wrong." } 
      self.request.response.status = 400 
      return json.dumps(errorDictionary, default=json_util.default) 

     testUserGUID = '123123123' 

     headers = remember(self.request, testUserGUID) 
     return HTTPOk(headers=headers) 

ठीक काम करने लगता है, लेकिन कुछ पेचीदा विवरण हैं:

सबसे पहले, 2 कुकीज़ वास्तव में एक के बजाय तैयार हो जाओ। 2 कुकीज़ समान हैं (दोनों नाम "auth_tkt" के साथ) एक अंतर को छोड़कर: किसी के पास ".www.mydomain.com" का होस्ट मान होता है जबकि अन्य कुकी के पास "www.mydomain.com" का होस्ट मान होता है एक के बजाय 2 कुकीज़ सेट की जा रही है? अंतर मेजबान मूल्यों का महत्व क्या है?

प्रश्न 2, वेब उपकरण रिपोर्ट करता है कि न तो कुकी सुरक्षित है। यह सुनिश्चित करने के लिए मैं क्या कर सकता हूं कि कुकी सुरक्षित हैं?

प्रश्न 3: दोनों कुकीज के पास "सत्र के अंत में" का समापन मूल्य होता है। इसका क्या अर्थ है और मैं खुद को समाप्ति मूल्य को कैसे अनुकूलित कर सकता हूं? लॉगिन कुकी समाप्ति समय के लिए अनुशंसित अभ्यास क्या है?

प्रश्न 4: मुझे समझ में नहीं आता कि क्यों "याद रखें" का पहला तर्क self.request.response की बजाय self.request है। क्या प्रतिक्रिया ऑब्जेक्ट पर डेटा याद नहीं किया जाना चाहिए, अनुरोध ऑब्जेक्ट नहीं?

+0

संभवतः आपका मतलब 'serverUserGUID =' 1123123123'' था; आप उस चर नाम के साथ 'याद रखें' कहते हैं। –

+0

धन्यवाद ... मैंने त्रुटि तय की है। – zakdances

उत्तर

11
  1. वास्तव में, 3 कुकीज़ उत्पन्न होती हैं; एक Domain कुंजी के बिना, एक के साथ, और एक तिहाई आपके डोमेन (वाइल्ड डॉट) के वाइल्डकार्ड संस्करण के साथ। आपका ब्राउज़र आमतौर पर दोनों को विलीन करता है या उनमें से किसी एक को अनदेखा करता है (जो ब्राउज़र द्वारा अलग होता है, यही कारण है कि 2 सेट हैं)।

    वह अंतिम कुकी उत्पन्न होती है जब wild_domain विकल्प AuthTktAuthenticationPolicy (डिफ़ॉल्ट रूप से सही) पर सेट होता है; AuthTktAuthenticationPolicy API देखें। आपको इसकी आवश्यकता है यदि आपकी प्रमाणीकरण कुकी को विभिन्न सबडोमेन के बीच साझा किया जाना है (लगता है app1.domain, app2.domain); आपका ब्राउज़र वाइल्डकार्ड कुकी के बिना सबडोमेन में कुकीज़ साझा नहीं करेगा।

  2. आपको सुरक्षित ध्वज सेट प्राप्त करने के लिए कुकीज़ के लिए अपनी लेख नीति पर secure विकल्प सेट करने की आवश्यकता है। फिर, API देखें।

  3. कोई समाप्ति सेट नहीं है, जिसका अर्थ यह है कि जब आप अपना ब्राउज़र बंद करते हैं तो कुकीज हटा दी जाती है (सत्र का अंत आपका ब्राउज़र आपको दिखाता है)। यदि आप ब्राउज़र को बंद करते समय अपने उपयोगकर्ताओं को लॉग आउट करना चाहते हैं, तो इसे डिफ़ॉल्ट के रूप में छोड़ दें।

    केवल यदि आप सत्रों ब्राउज़र बंद भर में पिछले एक कुकी अधिकतम आयु निर्धारित करते हैं, API में max_age विकल्प दिखाई चाहते हैं। यह विकल्प ब्राउजर बंद करने के दौरान ब्राउज़र को डिस्क पर कुकी स्टोर करने के लिए कारण देगा, और अधिकतम आयु बीत जाने पर उन्हें हटा दें।

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

    timeout और reissue_time विकल्पों को API documentation में इस पर कॉन्फ़िगर करने के तरीके के बारे में अधिक जानकारी के लिए देखें।

  4. पॉलिसी ऑब्जेक्ट को कुकीज़ उत्पन्न करने में सक्षम होने के अनुरोध से जानकारी के कई टुकड़ों की आवश्यकता होती है, कम से कम आपके सर्वर के सभी होस्ट नामों में से।

+1

आपके स्पष्टीकरण के लिए धन्यवाद। एक बात जो मैं जानना चाहता हूं, क्या एथटीके प्रमाणीकरण नीति सीएसआरएफ हमलों के खिलाफ सुरक्षित है ?? यदि नहीं, तो हम इसे कैसे सुरक्षित बना सकते हैं। और एक और बात यह है कि हम इसे क्लाइंट मोबाइल ऐप से कनेक्ट करने वाले सर्वर के लिए कैसे उपयोग कर सकते हैं। मुझे लगता है कि कुकी चीज मुश्किल होगी। और टोकन विकल्प बेहतर नहीं होगा ?? –

+1

जावास्क्रिप्ट से कुकी को छिपाने के लिए ब्राउज़र को बताने के लिए 'true_only' 'True' पर सेट करें; यह सीएसआरएफ हमलों को बनाता है जो कुकी को अप्रभावी चुरा लेते हैं। कुकीज़ केवल HTTP शीर्षलेख हैं, आपके मोबाइल क्लाइंट को उन्हें प्रबंधित करना होगा जैसे वे किसी अन्य साइट के लिए करेंगे। टोकन विकल्पों से आपका क्या मतलब है इसका कोई मतलब नहीं है। –

+0

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