स्प्रिंग सुरक्षा प्रलेखन के अनुसार /** का मुख्य उद्देश्य कैच-ऑल वाइल्डकार्ड के लिए है:
व्यवहार में हमारी सलाह है कि आप अपनी सेवा परत पर विधि सुरक्षा का उपयोग करें, अपने आवेदन के लिए उपयोग को नियंत्रित करने के लिए, और वेब-एप्लिकेशन स्तर पर परिभाषित सुरक्षा बाधाओं के उपयोग पर पूरी तरह से भरोसा न करें। यूआरएल बदलते हैं और उन सभी संभावित यूआरएल का विवरण लेना मुश्किल है जो एक एप्लिकेशन का समर्थन कर सकते हैं और अनुरोधों का उपयोग कैसे किया जा सकता है। आपको कुछ साधारण चींटी पथों का उपयोग करने के लिए स्वयं को आजमाएं और प्रतिबंधित करना चाहिए जो समझने में आसान हैं। हमेशा "deny-by-default" दृष्टिकोण का उपयोग करने का प्रयास करें जहां आपके पास कैच-ऑल वाइल्डकार्ड (/ ** या **) अंतिम रूप से परिभाषित किया गया है और पहुंच को अस्वीकार कर रहा है।
हम यह भी नहीं भूलना चाहिए कि
पैटर्न हमेशा क्रम में वे परिभाषित कर रहे हैं में मूल्यांकन कर रहे हैं। इस प्रकार यह महत्वपूर्ण है कि कम विशिष्ट पैटर्न की तुलना में सूची में अधिक विशिष्ट पैटर्न को उच्च परिभाषित किया गया हो।
इस प्रकार हम कुछ इस तरह हो सकता है:
<security:http pattern="/rest-service/**" authentication-manager-ref="authenticationManager" auto-config="false" access-decision-manager-ref="accessDecisionManager">
<security:intercept-url pattern="/rest-service/report/export/xml" access="AUTH_REPORT_EXPORTXML" />
<security:intercept-url pattern="/**" access="AUTH_SYSTEM_LOGIN" />
<security:http-basic />
</security:http>
जिसका मतलब है कि सभी अनुरोधों के लिए हम AUTH_SYSTEM_LOGIN अधिकार आवश्यकता होगी, लेकिन विशेष रूप से के लिए/बाकी-सेवा/रिपोर्ट/निर्यात/xml उपयोगकर्ता की आवश्यकता होगी AUTH_REPORT_EXPORTXML प्राधिकरण भी क्योंकि यह ऊपर परिभाषित किया गया है। वे यह भी कहना है के रूप में यह बेहतर है केवल इस सुरक्षा constrains जिसका अर्थ है कि यह इस तरह सुरक्षित टिप्पणी के साथ सेवा के तरीकों में उन लोगों के नकल करने भी अच्छा है पर भरोसा नहीं:
@Secured("AUTH_REPORT_EXPORTXML")
सामान्य में के रूप में मैं समझता हूँ कि वहाँ कोई अंतर नहीं है /* और /** सिवाय इसके कि आखिरी व्यक्ति सभी वाइल्डकार्ड पकड़ लेता है।