2011-01-07 17 views
16

मैं एक प्रणाली विकसित कर रहा हूं जो बहाव का उपयोग करता है। मैं ग्राहकों की पहचान की जांच करना चाहता हूं और ऑपरेशन एसीएलड होना चाहता हूं। क्या थ्रिफ्ट उन लोगों के लिए कोई समर्थन प्रदान करता है?बहाव के साथ प्रमाणीकरण और प्रमाणीकरण कैसे संभालें?

उत्तर

13

सीधे नहीं। ऐसा करने का एकमात्र तरीका एक प्रमाणीकरण विधि है जो सर्वर पर एक (अस्थायी) कुंजी बनाता है, और फिर अपने सभी तरीकों को बदलता है ताकि पहला तर्क यह कुंजी हो और वे सभी अतिरिक्त रूप से एक प्रमाणीकृत त्रुटि नहीं उठाते हैं। उदाहरण के लिए:

exception NotAuthorisedException { 
    1: string errorMessage, 
} 

exception AuthTimeoutException { 
    1: string errorMessage, 
} 

service MyAuthService { 
    string authenticate(1:string user, 2:string pass) 
     throws (1:NotAuthorisedException e), 

    string mymethod(1:string authstring, 2:string otherargs, ...) 
     throws (1:AuthTimeoutException e, ...), 
} 

हम इस विधि का उपयोग और एक 30 मिनट का समय समाप्त के साथ एक सुरक्षित memcached उदाहरण के लिए हमारी कुंजी को बचाने कुंजी सब कुछ "तेज़" रखने के लिए के लिए। AuthTimeoutException प्राप्त करने वाले ग्राहकों को पुनः प्राधिकरण और पुनः प्रयास करने की उम्मीद है और हमारे पास ब्रूट-फोर्स हमलों को रोकने के लिए कुछ फ़ायरवॉल नियम हैं।

+0

आप तार पर साफ़ टेक्स्ट में पासवर्ड भेज रहे हैं diff उत्पन्न? – JensG

+2

@ जेन्सजी नहीं, आप पासवर्ड को एन्क्रिप्टेड प्रारूप में भेजना चाहते हैं और उस एन्कोडेड स्ट्रिंग सर्वर-साइड को जांचना चाहते हैं। Bcrypt इसके लिए अच्छा है, क्योंकि वायर पर भेजे गए स्ट्रिंग को संग्रहीत स्ट्रिंग से बिल्कुल मेल नहीं मिल सकता है, लेकिन जब bcrypt एल्गोरिदम का उपयोग करके चेक किया जाता है तब भी सत्यापित हो सकता है। –

+0

यदि ऐसा है तो आप स्पष्ट टेक्स्ट पासवर्ड नहीं भेज रहे हैं, लेकिन यदि कोई हमलावर हैश पासवर्ड को पढ़ने में सक्षम है तो वह प्रमाणीकरण कॉल को फिर से चला सकता है और आपकी सेवाओं तक पहुंच प्राप्त कर सकता है। – cjungel

1

स्वायत्तता और अनुमतियों जैसे कार्यों को थ्रिफ्ट के हिस्से के रूप में नहीं माना जाता है, अधिकांशतः क्योंकि ये चीजें आम तौर पर सामान्य आरपीसी/क्रमबद्धता अवधारणा की तुलना में एप्लिकेशन तर्क से अधिक संबंधित होती हैं। एकमात्र बात यह है कि थ्रिफ्ट अभी बॉक्स से बाहर निकलता है TSASLTransport है। मैं उस बारे में ज्यादा कुछ नहीं कह सकता, सिर्फ इसलिए कि मैंने इसे इस्तेमाल करने की आवश्यकता महसूस नहीं की।

दूसरा विकल्प THeaderTransport का उपयोग करना हो सकता है, दुर्भाग्य से लेखन के समय केवल सी ++ के साथ लागू किया जाता है। इसलिए, यदि आप इसे किसी अन्य भाषा के साथ उपयोग करने की योजना बना रहे हैं तो आपको कुछ अतिरिक्त काम निवेश करना पड़ सकता है। कहने की जरूरत नहीं है कि हम योगदान स्वीकार करते हैं ...

0

थोड़ा देर हो चुकी है (मुझे बहुत देर हो चुकी है) लेकिन मैंने कुछ साल पहले इस के लिए थ्रिफ्ट सोर्स कोड संशोधित किया था।

बस पैच के साथ https://issues.apache.org/jira/browse/THRIFT-4221 पर टिकट जमा करें।

उस पर एक नज़र डालें। असल में प्रस्ताव "पहले एक्शन" हुक जोड़ना है जो वास्तव में करता है।

उदाहरण Golang

+  // Called before any other action is called 
+  BeforeAction(serviceName string, actionName string, args map[string]interface{}) (err error) 
+  // Called if an action returned an error 
+  ProcessError(err error) error 
} 

type MyServiceClient struct { 
@@ -391,7 +395,12 @@ func (p *myServiceProcessorMyMethod) Process(seqId int32, iprot, oprot thrift.TP 
     result := MyServiceMyMethodResult{} 
     var retval string 
     var err2 error 
-  if retval, err2 = p.handler.MyMethod(args.AuthString, args.OtherArgs_); err2 != nil { 
+  err2 = p.handler.BeforeAction("MyService", "MyMethod", map[string]interface{}{"AuthString": args.AuthString, "OtherArgs_": args.OtherArgs_}) 
+  if err2 == nil { 
+    retval, err2 = p.handler.MyMethod(args.AuthString, args.OtherArgs_) 
+  } 
+  if err2 != nil { 
+    err2 = p.handler.ProcessError(err2) 
संबंधित मुद्दे