2012-02-13 4 views
9

क्या कोई वर्ग (मुफ़्त, मुक्त स्रोत या वाणिज्यिक) है जो जावा के AccessController के समान पहुंच नियंत्रण करता है? मैं नीतियों का एक गतिशील सेट बनाना चाहता हूं जिसे रनटाइम पर बदला जा सकता है।क्या जावा की अनुमति प्रबंधक या एक्सेस कंट्रोलर कक्षाओं के बराबर डेल्फी है?

लेकिन, मुझे हर जगह कोड करने के लिए

if Allowed(...) then 

होने से बचना चाहते हैं। मुझे पता है कि मुझे शायद अपने प्रोग्राम क्लास पदानुक्रम को समायोजित करने की आवश्यकता है, लेकिन मैं पसंद करता हूं कि जगह पर मैन्युअल रूप से गार्ड जोड़ना।

यदि कोई उपयोग करने योग्य कोड नहीं है, तो एक समझदार दृष्टिकोण क्या होगा? RTTI?

संपादित करें: यहां Security Annotations and Authorization in GlassFish and the Java EE 5 SDK आलेख का एक उदाहरण दिया गया है। के बाद से किसी एक टिप्पणी में एनोटेशन उल्लेख किया है, मुझे लगता है कि यह आदर्श होगा:

@Stateless 
@RolesAllowed("javaee") 
public class HelloEJB implements Hello { 
    @PermitAll 
    public String hello(String msg) { 
     return "Hello, " + msg; 
    } 

    public String bye(String msg) { 
     return "Bye, " + msg; 
    } 
} 

लेख से:

इस उदाहरण में, हैलो() विधि हर किसी के द्वारा पहुँचा जा सकता है, और अलविदा () विधि javaee के उपयोगकर्ताओं द्वारा विधि सुलभ है।

संपादित करें: ठीक है, ऐसा लगता है आम सहमति है कि इस डेल्फी में नहीं किया जा सकता है। दूसरों को लगता है कि यह एक बुरा दृष्टिकोण है।

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

ये मेरे वर्तमान विकल्प हैं:

  1. TMS Security System - यह एक पूर्ण समाधान, कई उपकरणों के साथ की तरह दिखाई देता है। देखने लायक मैं इसे एक उत्तर के रूप में स्वीकार कर रहा हूं भले ही मैं शायद इसके लिए नहीं जा रहा हूं।
  2. यह ऐसा कुछ है जो आशाजनक दिखता है: Delphi virtual method interception। यह केवल आभासी तरीकों पर काम करता है, लेकिन मुझे नहीं लगता कि इसका पालन करना बहुत मुश्किल है। यह और एनोटेशन एक दिलचस्प प्रणाली बना सकता है (ऐसा प्रतीत होता है कि यह मूल रूप से डेटास्नाप प्रमाणीकरण के लिए डिज़ाइन किया गया था)
  3. आपके एप्लिकेशन में केवल एक एक्शन मैनेजर होने के साथ, और सुनिश्चित करें कि सभी कार्रवाइयां केवल वहां से शुरू की जा सकती हैं। इस तरह आप एक्शन मैनेजर OnExecute विधि का उपयोग कर सकते हैं; मैं TAction.Name प्रॉपर्टी को अनुमति नाम ("हैंडलर") के रूप में उपयोग करने का नाटक करता हूं, तालिका से अनुमत कार्यों की एक सूची पढ़ता हूं। मैं एडमिन यूआई में पूरी सूची प्रदर्शित करने के लिए एक्शन मैनेजर से एक्शन लिस्ट का उपयोग कर सकता हूं।
+1

मुझे लगता है कि आप विशेषताओं का उपयोग करके समान कार्यक्षमता प्राप्त कर सकते हैं (यदि मैं गलत हूं तो मुझे क्रूस पर न लगाएं ...) यहां कुछ लिंक हैं: http://robstechcorner.blogspot.com/2009/09/so -what-is-rtti-rtti-is-acronym-for-run.html http://delphi.about.com/od/oopindelphi/a/delphi-attributes-understanding-using-attributes-in-delphi.htm http : //stackoverflow.com/questions/2657502/practical-usage-for-delphis-new-rtti-attributes-values ​​ – ComputerSaysNo

+0

@DorinDuminica - एनोटेशन एकत्र किए जा सकते हैं और एक सूची में रखा जा सकता है ताकि मैं उन्हें एक विशिष्ट भूमिका नियुक्त कर सकूं? –

+0

क्या आप डेल्फी कोड कैसा दिखना चाहिए इस पर नमूना कोड प्रदान कर सकते हैं? आप कहते हैं कि अगर आप अनुमत (...) तो 'नहीं करना चाहते हैं, लेकिन लिंक किए गए दस्तावेज़ों में पहला जावा नमूना' विरासत में मिला है Context.checkPermission (अनुमति); - यह मेरी पुस्तक में समान है। –

उत्तर

1

हाँ, वहाँ एक डेल्फी Access Control Library (lkacl) (OpenSource), JCL (OpenSource) जो एक बहुत व्यापक सुरक्षा features प्रदान करता है, और अंत में अपने मांगों को वास्तव में उच्च सबसे लोकप्रिय वाणिज्यिक समाधान TMS Security System है हो सकता है अगर है।

+0

यह एक "मुझे आपके लिए Google दें" उत्तर है। पहली लिंक्ड प्रोजेक्ट ने अभी तक कोई भी फाइल प्रकाशित नहीं की है, आपके द्वारा लिंक की गई 'फीचर्स' ज्यादातर विन्डोज़ सुरक्षा टोकन के साथ काम करने के लिए फ़ंक्शंस निर्दिष्ट करती हैं। अंतिम लिंक (टीएमएस सुरक्षा प्रणाली) अच्छा लग रहा है, क्या आपने इसका इस्तेमाल किया है? –

+0

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

+0

मुझे वास्तव में लगता है कि टीएमएस लिंक एक बहुत अच्छा जवाब है। यह फैंसी स्वाद जावा इंजेक्शन पैटर्न का उपयोग नहीं कर रहा है, लेकिन यह "जादू" के साथ समस्या को हल करने की कोशिश करने से शायद बेहतर है। +1। –

2

डेल्फी के लिए अभी तक ऐसा कोई ढांचा नहीं है, न ही ईजेबी जैसी अवधारणा जो इसके साथ फिट होगी।DELPHI वर्ग एनोटेशन का समर्थन करता है, और इस तरह के ढांचे को एक क्रिया स्तर पर सुरक्षा प्रदान करने के लिए, टीएक्शन के संयोजन के साथ डिजाइन किया जा सकता है, लेकिन मुझे संदेह है कि इसे विशिष्ट विधि कॉल को अवरुद्ध करने के लिए बढ़ाया जा सकता है। डेल्फी कोड कभी वर्चुअल विधि का आह्वान करने की अनुमति नहीं मांगता है। डेल्फी में प्रत्येक वर्चुअल विधि कॉल में खुद को इंजेक्शन देने वाले कुछ भी, दृश्यों के पीछे एक चेकप्रमिशन कॉल जोड़ना (मेरी राय में) बुरा होगा। यह धीरे-धीरे होगा, और इस तरह के चेक लिखने से भी बदतर होगा।

हालांकि, मॉक डेल्फी कक्षाओं में उपयोग की जाने वाली वही तकनीकों का उपयोग शायद भविष्य में कुछ ऑटो-सुरक्षा रैपर ऑब्जेक्ट बनाने के लिए किया जा सकता है।

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

तो एक संरक्षित संख्या, "भविष्य में सीमित फ्रेमवर्क संभव" खंड के साथ।

+0

एचएम, धन्यवाद। मैं अपने google-fu पर संदेह कर रहा था। –

+0

मुझे लगता है कि मैन्युअल चेकप्रमिशन कॉल आवश्यक होने जा रहे हैं। यदि आप इसके बारे में सोचते हैं, तो TAction.Enable को सक्षम या अक्षम सेट करना होगा, वैसे भी, सही? आमतौर पर acSaveFile.Enabled "FileOpen और FileModified और PermissionToSave" पर सेट किया जाएगा। तो वास्तविक दुनिया में "स्वचालित रूप से" काम करने की अनुमति फ्रेमवर्क कठिन चूसने जा रहा है। एक विशाल ओवरहेड के साथ 99% समाधान। –

+0

संभवतः अधिकतर मामलों के लिए 'सेटएनेबल' अधिभारित करना पर्याप्त होगा। मेरा आवेदन तब जा सकता है जब फ़ाइलमोडाइफाइड तो ACSave.Enabled: = true' लेकिन अनुमति प्रबंधक अभी भी कार्रवाई को सक्षम न करने का निर्णय ले सकता है। कम से कम थोड़ी देर के लिए यह काफी अच्छा होगा। –

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