আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন দেখুন। তথ্য
RegularExpressionProtection নীতি এমন রেগুলার এক্সপ্রেশনকে সংজ্ঞায়িত করে যা ইনপুট প্যারামিটার বা ফ্লো ভেরিয়েবেলে রানটাইমে মূল্যায়ন করা হয়। আপনি সাধারণত SQL বা জাভাস্ক্রিপ্ট ইঞ্জেকশনের মতো কন্টেন্ট সংক্রান্ত হুমকি থেকে রক্ষা করতে অথবা ইমেল আইডি বা URL-এর মতো ভুল ফর্ম্যাটযুক্ত অনুরোধের প্যারামিটার চেক করতে এই নীতি ব্যবহার করেন।
অনুরোধের পাথ, কোয়েরি প্যারামিটার, ফর্ম প্যারামিটার, হেডার, XML এলিমেন্ট (XPath ব্যবহার করে সংজ্ঞায়িত XML পেলোডে), JSON অবজেক্ট অ্যাট্রিবিউট (JSONPath ব্যবহার করে সংজ্ঞায়িত JSON পেলোডে) ইত্যাদির জন্য রেগুলার এক্সপ্রেশন সংজ্ঞায়িত করা যেতে পারে।
নিম্নলিখিত উদাহরণ RegularExpressionProtection নীতি SQL ইনজেকশন অ্যাটাক থেকে ব্যাকএন্ডকে রক্ষা করে:
<!-- /antipatterns/examples/greedy-1.xml --> <RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="RegexProtection"> <DisplayName>RegexProtection</DisplayName> <Properties/> <Source>request</Source> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> <QueryParam name="query"> <Pattern>[\s]*(?i)((delete)|(exec)|(drop\s*table)| (insert)|(shutdown)|(update)|(\bor\b))</Pattern> </QueryParam> </RegularExpressionProtection>
অ্যান্টিপ্যাটার্ন
ডিফল্ট কোয়ান্টিফায়ার (*, + ও ?) স্বভাবগতভাবে
লোভী হয়: তারা সবচেয়ে বড় সম্ভাব্য সিকোয়েন্সের সাথে ম্যাচ করা শুরু করে। কোনও ম্যাচ খুঁজে না পেলে, প্যাটার্ন ম্যাচ করানোর জন্য
সেগুলি ধীরে ধীরে ব্যাকট্র্যাক করে। প্যাটার্নের সাথে মিলে যাওয়া স্ট্রিংয়ের ফলাফল
খুব ছোট হলে, প্রয়োজনীয় সময়ের চেয়ে বেশি সময় গ্রিডি কোয়ান্টিফায়ার ব্যবহার করতে পারে। পে-লোড বড় হলে (দশ বা শত শত KB) এটি
বিশেষভাবে সত্য।
নিচে দেওয়া উদাহরণ এক্সপ্রেশনে .*-এর একাধিক ইনস্ট্যান্স ব্যবহার করা হয়েছে, এগুলি হল লোভী
অপারেটর:
<Pattern>.*Exception in thread.*</Pattern>
এই উদাহরণে, RegularExpressionProtection নীতি প্রথমে সবচেয়ে বড় সম্ভাব্য
সিকোয়েন্স—সম্পূর্ণ স্ট্রিং—ম্যাচ করার চেষ্টা করে। কোনও মিল খুঁজে না পাওয়া গেলে, নীতিটি ধীরে ধীরে
ব্যাকট্র্যাক করে। ম্যাচ করা স্ট্রিং যদি পেলোডের শুরু বা মাঝামাঝি অংশে থাকে, তাহলে .*-এর মতো গ্রিডি কোয়ান্টিফায়ার ব্যবহার করলে, .*?-এর মতো অনিচ্ছুক কোয়ান্টিফায়ার বা (কম সাধারণ) .*+-এর মতো পজেসিভ কোয়ান্টিফায়ারের তুলনায় অনেক বেশি সময় ও প্রসেসিং পাওয়ার লাগতে পারে।
অনিচ্ছুক কোয়ান্টিফায়ার (যেমন X*?, X+?, X??) পে-লোডের শুরু থেকে একটি অক্ষর ম্যাচ করার চেষ্টা করে
এবং ধীরে ধীরে অক্ষর যোগ করে।
মালিকানাধীন কোয়ান্টিফায়ার (যেমন X?+, X*+, X++) শুধুমাত্র একবার
সম্পূর্ণ পেলোড ম্যাচ করার চেষ্টা করে।
উপরের প্যাটার্নের জন্য নিম্নলিখিত নমুনা টেক্সট দেওয়া হল:
Hello this is a sample text with Exception in thread with lot of text after the Exception text.
এই ক্ষেত্রে লোভী .* ব্যবহার করলে ভাল পারফর্ম্যান্স পাওয়া যায় না। প্যাটার্নটি
.*Exception in thread.* ম্যাচ করতে ১৪১টি ধাপ লাগে। আপনি যদি এর পরিবর্তে প্যাটার্ন
.*?Exception in thread.* (যা অনিচ্ছুক কোয়ান্টিফায়ার ব্যবহার করে) ব্যবহার করতেন, তাহলে ফলাফল
শুধুমাত্র ৫৫টি ধাপ হত।
প্রভাব
RegularExpressionProtection নীতি-এর সাথে ওয়াইল্ডকার্ডের (*) মতো লোভী কোয়ান্টিফায়ার ব্যবহার করলে এগুলি হতে পারে:
- API অনুরোধের জন্য মাঝারি পে-লোড সাইজের (১ এমবি পর্যন্ত) ক্ষেত্রে সামগ্রিক লেটেন্সি বৃদ্ধি
- RegularExpressionProtection নীতি এক্সিকিউট করতে বেশি সময় লাগা
- Edge রাউটারে আগে থেকে নির্ধারিত টাইম-আউট পিরিয়ড শেষ হয়ে গেলে, বড় পে-লোড (>১ এমবি) সহ API অনুরোধ 504 Gateway Timeout Error সহ ব্যর্থ হয়
- প্রসেসিংয়ের পরিমাণ বেশি হওয়ার কারণে মেসেজ প্রসেসরের সিপিইউ খুব বেশি ব্যবহার হচ্ছে, যা অন্যান্য API অনুরোধের উপর প্রভাব ফেলতে পারে
পেশাদার পদ্ধতি
- RegularExpressionProtection policy-এর সাথে রেগুলার এক্সপ্রেশনে
.*-এর মতো লোভী কোয়ান্টিফায়ার ব্যবহার করা এড়িয়ে চলুন। পরিবর্তে, যেখানে সম্ভব সেখানে.*?-এর মতো অনিচ্ছুক কোয়ান্টিফায়ার বা.*+-এর মতো পজেসিভ কোয়ান্টিফায়ার (কম সাধারণ) ব্যবহার করুন।