सुरक्षा GWT RPC

Question

का उपयोग करते समय सुरक्षा मेरे पास Google वेब टूलकिट में एक POJO है, जैसे कि मैं सर्वर से पुनर्प्राप्त कर सकता हूं।

class Person implements Serializable { 
    String name; 
    Date creationDate; 
} 

ग्राहक परिवर्तन करता है, मैं वापस सहेज सर्वर इस तरह GWT RemoteServiceServlet का उपयोग कर रहे हैं:

rpcService.saveObject(myPerson,...) 

समस्या यह है कि उपयोगकर्ता creationDate बदलने में सक्षम नहीं होना चाहिए। चूंकि RPC विधि वास्तव में सर्वर पर एक HTTP पोस्ट है, इसलिए POST अनुरोध को बदलकर creationDate को संशोधित करना संभव होगा।

changeName(String newName) इत्यादि जैसे आरपीसी कार्यों की एक श्रृंखला बनाने के लिए एक साधारण समाधान होगा, लेकिन कई क्षेत्रों वाले वर्ग के साथ प्रत्येक फ़ील्ड के लिए कई विधियों की आवश्यकता होगी, और कई क्षेत्रों को एक बार में बदलने में अक्षम होगा।

मुझे एक एकल POJO होने की सादगी पसंद है जिसे मैं सर्वर और जीडब्ल्यूटी क्लाइंट दोनों पर उपयोग कर सकता हूं, लेकिन इसे सुरक्षित तरीके से करने का एक तरीका चाहिए। कोई विचार?

संपादित

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

संपादित 2

इसके अलावा, स्पष्ट होना, मैं क्षेत्र creationDate समस्या के एक उदाहरण के रूप में इस्तेमाल किया। हकीकत में जिस कोड के साथ मैं काम कर रहा हूं वह कई अलग-अलग क्षेत्रों के साथ अधिक जटिल है।

Answer 1

मैं आपको अपनी एकल आरपीसी विधि रखने की सलाह देता हूं, और Dozer या Gilead जैसे POJO/बीन मैपर का उपयोग करने की सलाह देता हूं।

डोजर के साथ
• , आप एक class-mapping है कि एक और करने के लिए एक वस्तु से गुण कॉपी करने के लिए प्रयोग किया जाता है पैदा करते हैं। यदि आप कक्षा-मानचित्रण में कोई संपत्ति निर्दिष्ट नहीं करते हैं, तो इसकी प्रतिलिपि नहीं बनाई जाएगी।
• गिलाद के साथ, @ReadOnly transport annotation पर्याप्त होना चाहिए।

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

Answer 2

अच्छी तरह से ... एक अकादमिक (यानी सैद्धांतिक रूप से संभव है, लेकिन काफी अव्यवहारिक) समाधान ऑब्जेक्ट की स्थिति को फेंकने वाली सार्वजनिक कुंजी का उपयोग कर हो सकता है जो निजी कुंजी सर्वर पर है। यह कुछ इस तरह जाना हो सकता है:

1. सर्वर सर्वर क्लाइंट
2. ग्राहक के लिए वास्तविक डेटा के साथ सार्वजनिक कुंजी भेजता सार्वजनिक-निजी कुंजी युग्म
3. उत्पन्न पूर्ण वस्तु के एक हैश की गणना करता है एक साथ सार्वजनिक कुंजी
4. ग्राहक के साथ राज्य सर्वर
5. सर्वर हैश पुनर्गणना पैकेज की अखंडता की पुष्टि करने के लिए वस्तु और हैश भेजता

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

फिर, इस विचार को एक विचार प्रयोग से ज्यादा कुछ नहीं मानें ... मैं आपको इस तरह के दृष्टिकोण को लागू करने का सुझाव नहीं दूंगा। आम तौर पर, आपको डेटा को सुरक्षित करने से पहले क्लाइंट पर तर्क की गारंटी देने में सक्षम होना चाहिए।

Answer 3

यदि क्लाइंट सृजनडेट को बदलने में सक्षम नहीं होना चाहिए और इसे छड़ी है, तो अपना क्रमबद्धता बदलें (उदा।उस विशिष्ट फ़ील्ड को सहेजने के लिए आपका SQL UPDATE कथन)। इसे केवल INSERT से सेट किया जाना चाहिए (जहां यह आरपीसी एंडपॉइंट सर्वर से आएगा, या यदि आप स्वचालित डिफ़ॉल्ट सेट करते हैं तो आपका डेटाबेस सर्वर)।

Answer 4

मैं एक अनुमतियाँ आधारित दृष्टिकोण का उपयोग करेंगे:

• उपयोगकर्ताओं को भूमिकाएं (जैसे व्यवस्थापक उपयोगकर्ता में लॉग इन, अतिथि उपयोगकर्ता, ...) असाइन करें, और
• सहयोगी अनुमति के साथ उन भूमिकाओं (जैसे व्यक्ति के नाम पढ़ सकते हैं, उस व्यक्ति का नाम संशोधित कर सकते हैं - हो सकता है आगे कि कुछ व्यक्तियों आदि)

ग्राहक से प्रत्येक अनुरोध पर करने के लिए सीमित,, सर्वर पर एक जांच उपयोगकर्ता प्रदर्शन करने के लिए अनुमति दी है अगर वह कार्रवाई "निर्माण तिथियों" के मामले में, शायद किसी के लिए यह कभी अनुमति नहीं है। तो

• यदि अनुरोध एक निर्माण तिथि है, तो आपको एक त्रुटि संदेश दिखाने या अनुरोध अनदेखा कर सकते हैं ...
• यदि अनुरोध एक निर्माण तिथि (सामान्य मामले) शामिल नहीं है, आप की तारीख बनाने सर्वर पर - या यदि व्यक्ति के पास पहले से ही एक सृजन तिथि है, तो इसका पुन: उपयोग करें।

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

विशेष स्थिति:

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

Answer 5

फ़ील्ड्स को निजी क्यों नहीं बनाते हैं और केवल एक getCreationDate() और कोई सेटक्रिएशनडेट() प्रदान नहीं करते हैं?

Answer 6

आप केवल अपरिवर्तनीय फ़ील्ड के मानों को अनदेखा कर सकते हैं।
यदि सर्वर पर आपका दृढ़ता तंत्र कैसे स्थापित किया जाता है, तो यह संभव नहीं है, तो जब अनुरोध सर्वर पर जाता है, तो लगातार स्टोर से POJO का एक और उदाहरण पुनर्प्राप्त करें और उन फ़ील्ड को पॉप्युलेट करें जो आपके द्वारा अपरिवर्तनीय हैं मिला है।किसी ऐसे व्यक्ति के साथ छेड़छाड़ की जिस तरह से आप परवाह नहीं है।

बेशक एन्क्रिप्शन छेड़छाड़ से बचने में मदद करने के लिए एक समाधान भी हो सकता है।

Answer 7

अपनी वस्तुओं को दो भागों में विभाजित करें। इनमें से केवल वे फ़ील्ड होते हैं जिन्हें क्लाइंट संपादित कर सकता है। क्लाइंट को दोनों ऑब्जेक्ट्स भेजें, लेकिन क्लाइंट इसे लौटाते समय केवल संपादन योग्य ऑब्जेक्ट को सेव करें। आप अपने जीवन को और अधिक सरल बनाने के लिए यहां विरासत का उपयोग कर सकते हैं।

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