Regarding translations: My native language is English. Because this is a free and open-source hobby project which generates zero income, and translatable content is likely to change as the features and functionality supported by the project changes, it doesn't make sense for me to spend money for translations. Because I'm the sole author/developer/maintainer for the project and I'm not a ployglot, any translations I produce are very likely to contain errors. Sorry, but realistically, that won't ever change. If you find any such errors/typos/mistakes/etc, your assistance to correct them would be very much appreciated. Pull requests are invited and encouraged. Otherwise, if you find these errors too much to handle, just stick with the original English source. If a translation is irredeemably incomprehensible, let me know which, and I can delete it. If you're not sure how to perform pull requests, ask. I can help.
CIDRAM (غیر طبقاتی انٹر ڈومین روٹنگ رسائی مینیجر) بشمول (لیکن تک محدود نہیں) غیر انسانی رسائی اختتامی پوائنٹس کے، کلاؤڈ سروسز سے ٹریفک ناپسندیدہ ٹریفک کے ہونے کی وجہ سے ذرائع، کے طور پر شمار IP پتوں سے شروع کی درخواستوں کو مسدود کرنے کی طرف سے ویب سائٹس کی حفاظت کے لئے ڈیزائن کیا ایک PHP کی سکرپٹ ہے، اسپیم بوٹس، سکراپارس، وغیرہ یہ باؤنڈ درخواستوں سے فراہم IP پتوں کی ممکنہ CIDR کو شمار کرتے ہیں اور پھر (ان کے دستخط فائلوں ہونے کے ذرائع کے طور پر شمار IP پتوں کی CIDR کی فہرستوں پر مشتمل اس کے دستخط فائلوں کے خلاف ان ممکن CIDR سے ملنے کے لئے کی کوشش کر کے اس کرتا ہے ناپسندیدہ ٹریفک کے)؛ موازنہ نہیں ملا رہے ہیں تو، درخواستوں مسدود ہیں.
یہ سکرپٹ مفت سافٹ ویئر ہے. آپ اسے دوبارہ تقسیم اور / یا ترمیم کے طور پر مفت سافٹ ویئر فاؤنڈیشن کی جانب سے شائع GNU جنرل پبلک لائسنس کی شرائط کے تحت اس پر نظر ثانی کر سکتے ہیں؛ یا تو لائسنس کے ورژن 2، یا (آپ کے اختیارات پر) کسی بھی جدید ورژن. یہ سکرپٹ یہ مفید ہو جائے گا، لیکن کسی بھی وارنٹی کے بغیر امید میں تقسیم کیا جاتا ہے؛ کسی خاص مقصد کے لئے قابل فروختگی یا فٹنس کی بھی تقاضا وارنٹی کے بغیر. مزید تفصیلات کے لئے GNU جنرل پبلک لائسنس، "LICENSE.txt" فائل اور سے بھی دستیاب میں واقع دیکھیں:
- .
- .
یہ دستاویز اور اس کے متعلقہ پیکجوں کے لئے مفت سے ڈاؤن لوڈ کیا جا سکتا ہے:
- GitHub.
- Bitbucket.
- SourceForge.
سب سے پہلے، آپ کو CIDRAM کی ایک تازہ کاپی درکار ہوگی. آپ CIDRAM/CIDRAM ذخیرے سے CIDRAM کے تازہ ترین ورژن کا آرکائیو ڈاؤن لوڈ کر سکتے ہیں. مخصوص ہونے کے لیے، آپ کو "vault" ڈائریکٹری کی ایک تازہ کاپی درکار ہوگی (محفوظ شدہ دستاویزات میں باقی سب کچھ محفوظ طریقے سے حذف یا نظر انداز کیا جا سکتا ہے).
v3 سے پہلے، CIDRAM فرنٹ اینڈ تک رسائی حاصل کرنے کے لیے آپ کے عوامی جڑ کے اندر کہیں CIDRAM انسٹال کرنا ضروری تھا. تاہم، v3 کے بعد سے، یہ ضروری نہیں ہے. سیکیورٹی کو زیادہ سے زیادہ بنانے اور CIDRAM اور اس کی فائلوں تک غیر مجاز رسائی کو روکنے کے لیے، یہ تجویز کیا جاتا ہے کہ CIDRAM کو اپنے عوامی جڑ سے باہر انسٹال کریں. اس سے کوئی فرق نہیں پڑتا کہ آپ CIDRAM کہاں انسٹال کرتے ہیں، جب تک کہ یہ PHP کے ذریعے قابل رسائی، کہیں معقول حد تک محفوظ، اور کہیں آپ خوش ہوں. اب "vault" ڈائرکٹری کے نام کو برقرار رکھنا بھی ضروری نہیں ہے، لہذا آپ "vault" کا نام بدل کر جو چاہیں رکھ سکتے ہیں (لیکن سہولت کی خاطر، دستاویزات اسے "vault" ڈائریکٹری کے طور پر حوالہ دیتی رہیں گی).
جب آپ تیار ہوں تو، "vault" ڈائرکٹری کو اپنے منتخب کردہ مقام پر اپ لوڈ کریں، اور یقینی بنائیں کہ اس میں PHP کے لیے ڈائرکٹری میں لکھنے کے قابل ہونے کے لیے ضروری اجازتیں ہیں (سسٹم پر منحصر ہے، ہو سکتا ہے آپ کو کچھ کرنے کی ضرورت نہ ہو، یا آپ کو ڈائرکٹری میں CHMOD 755 سیٹ کرنے کی ضرورت ہو، یا اگر 755 کے ساتھ مسائل ہیں، تو آپ 777 کو آزما سکتے ہیں، لیکن کم محفوظ ہونے کی وجہ سے 777 کی سفارش نہیں کی جاتی ہے).
اگلا، CIDRAM آپ کے کوڈ بیس یا CMS کی حفاظت کرنے کے قابل ہونے کے لیے، آپ کو ایک "انٹری پوائنٹ" بنانے کی ضرورت ہوگی. اس طرح کا داخلی نقطہ تین چیزوں پر مشتمل ہے:
۱. آپ کے کوڈ بیس یا CMS پر کہیں "loader.php" فائل کو شامل کرنا.
۲. CIDRAM core لانچ کرنا.
۳. "protect" کے طریقہ کار کو کال کرنا.
۲. CIDRAM core لانچ کرنا.
۳. "protect" کے طریقہ کار کو کال کرنا.
ایک سادہ مثال:
<?php
require_once '/path/to/the/vault/directory/loader.php';
(new \CIDRAM\CIDRAM\Core())->protect();اگر آپ Apache ویب سرور استعمال کر رہے ہیں اور آپ کو
php.ini تک رسائی حاصل ہے، تو آپ جب بھی پی ایچ پی کی کوئی درخواست کی جاتی ہے تو آپ CIDRAM کو آگے بڑھانے کے لیے X ہدایت کا استعمال کر سکتے ہیں، جب بھی پی ایچ پی کی درخواست کی جاتی ہے تو آپ CIDRAM کو پہلے سے پینڈ کرنے کے لیے auto_prepend_file ہدایت استعمال کر سکتے. ایسی صورت میں، آپ کا انٹری پوائنٹ بنانے کے لیے سب سے مناسب جگہ اس کی اپنی فائل میں ہوگی، اور پھر آپ اس فائل کا حوالہ دیں گے auto_prepend_file ہدایت پر.مثال:
auto_prepend_file = "/path/to/your/entrypoint.php"
یا یہ
.htaccess فائل میں:php_value auto_prepend_file "/path/to/your/entrypoint.php"
دوسری صورتوں میں، آپ کا داخلی نقطہ بنانے کے لیے سب سے مناسب جگہ آپ کے کوڈ بیس یا CMS کے اندر جلد از جلد ہوگی. یہ یقینی بنانے کے لیے ہے کہ جب بھی آپ کی ویب سائٹ پر کسی صفحہ تک رسائی حاصل کی جائے گی تو یہ لوڈ ہو جائے گا. اگر آپ کا کوڈ بیس ایک "بوٹسٹریپ" استعمال کرتا ہے، تو آپ کی "بوٹسٹریپ" فائل کا آغاز ہی ایک اچھی مثال ہوگی. اگر آپ کے کوڈ بیس میں ایک مرکزی فائل ہے جو آپ کے ڈیٹا بیس سے جڑنے کے لیے ذمہ دار ہے، تو یہ ایک اور اچھی مثال ہوگی.
composer require cidram/cidram
CIDRAM ورڈپریس پلگ ان کے ڈیٹا بیس کے ساتھ ایک پلگ ان کے طور پر رجسٹرڈ ہے، اور آپ کو پلگ ان ڈیش بورڈ سے براہ راست CIDRAM انسٹال کر سکتے ہیں. آپ کسی بھی دیگر پلگ ان کے طور پر اسی انداز میں اسے انسٹال کر سکتے ہیں، اور کوئی اس کے علاوہ اقدامات کی ضرورت ہے.
انتباہ: ایک صاف تنصیب میں پلگ ان ڈیش بورڈ کے نتائج کے ذریعے CIDRAM تازہ کاری ہو رہی! آپ کو آپ کی تنصیب کے اپنی مرضی کے مطابق کیا ہے تو (اپنی ترتیب بدل گیا، نصب ماڈیولز، وغیرہ)، ان کی تخصیصات پلگ ان ڈیش بورڈ کے ذریعے اپ ڈیٹ کر جب ختم ہو جائے گا! لاگ مسلیں بھی ختم ہو جائے گا! لاگ فائلوں اور اصلاح کے تحفظ کے لئے، CIDRAM سامنے کے آخر میں اپ ڈیٹس صفحے کے ذریعے اپ ڈیٹ کریں.
آپ کے لیے سختی سے تجویز کی جاتی ہے کہ آپ اپنی نئی تنصیب کی ترتیب کا جائزہ لیں تاکہ آپ اسے اپنی ضروریات کے مطابق ایڈجسٹ کر سکیں. آپ اضافی ماڈیولز، دستخطی فائلیں انسٹال کرنا، معاون اصول بنانا، یا دیگر تخصیصات کو نافذ کرنا چاہیں گے تاکہ آپ کی تنصیب آپ کی ضروریات کے مطابق ہو سکے. میں ان چیزوں کو کرنے کے لیے فرنٹ اینڈ کو استعمال کرنے کی تجویز کرتا ہوں.
CIDRAM خود کار طریقے سے آپ کی ویب سائٹ کو ناپسندیدہ درخواستوں کسی بھی دستی امداد کی ضرورت کے بغیر، ایک طرف اس کی ابتدائی تنصیب سے مسدود کرنا چاہئے.
آپ کو آپ کی ترتیب اپنی مرضی کے مطابق اور اپنی مرضی کے مطابق جس CIDR آپ کی کنفیگریشن فائل اور/یا آپ کے دستخط کی فائلوں میں تبدیلی کرنے کی طرف سے بلاک کر رہے ہیں کر سکتے ہیں.
آپ کو کسی بھی جھوٹے مثبت سامنا کرتے ہیں، مجھے اس کے بارے میں مطلع کرنے کے لئے مجھ سے رابطہ کریں. (دیکھیں: ایک "جھوٹی مثبت" سے کیا مراد ہے؟).
CIDRAM دستی طور پر یا سامنے کے اختتام کے ذریعے اپ ڈیٹ کیا جا سکتا ہے. CIDRAM بھی Composer یا WordPress کے ذریعہ اپ ڈیٹ کیا جا سکتا ہے، اگر اصل میں ان کے ذریعہ نصب ہوجائے.
سامنے کے آخر میں، برقرار رکھنے کا انتظام، اور آپ CIDRAM تنصیب کو اپ ڈیٹ کرنے کے لئے ایک آسان اور آسان طریقہ فراہم کرتا ہے. آپ صرف مسودہ دیکھ سکتے ہیں، اشتراک، اور نوشتہ صفحے کے ذریعے لاگ مسلیں لوڈ، آپ کی ترتیب کے صفحے کے ذریعے کی ترتیب تبدیل کر سکتے ہیں، آپ کو انسٹال کر سکتے ہیں اور اپ ڈیٹس صفحے کے ذریعے انسٹال اجزاء، اور آپ کو اپ لوڈ کر سکتے ہیں، ڈاؤن لوڈ، اتارنا، اور فائل کے ذریعے آپ کے والٹ میں فائلوں پر نظر ثانی مینیجر.
بالکل پہلے کی طرح، آپ کو فرنٹ اینڈ تک رسائی حاصل کرنے کے لیے ایک انٹری پوائنٹ بنانے کی ضرورت ہوگی. اس طرح کا داخلی نقطہ تین چیزوں پر مشتمل ہے:
۱. آپ کے کوڈ بیس یا CMS پر کہیں "loader.php" فائل کو شامل کرنا.
۲. CIDRAM front-end لانچ کرنا.
۳. "view" کے طریقہ کار کو کال کرنا.
۲. CIDRAM front-end لانچ کرنا.
۳. "view" کے طریقہ کار کو کال کرنا.
ایک سادہ مثال:
<?php
require_once '/path/to/the/vault/directory/loader.php';
(new \CIDRAM\CIDRAM\FrontEnd())->view();"FrontEnd" کلاس "Core" کلاس کو بڑھاتی ہے. اس کا مطلب ہے کہ آپ ممکنہ طور پر ناپسندیدہ ٹریفک کو فرنٹ اینڈ تک رسائی سے روکنے کے لیے "view" کے طریقے کو کال کرنے سے پہلے "protect" طریقہ کو کال کر سکتے ہیں. ایسا کرنا مکمل طور پر اختیاری ہے.
ایک سادہ مثال:
<?php
require_once '/path/to/the/vault/directory/loader.php';
$CIDRAM = new \CIDRAM\CIDRAM\FrontEnd();
$CIDRAM->protect();
$CIDRAM->view();فرنٹ اینڈ کے لیے انٹری پوائنٹ بنانے کے لیے سب سے مناسب جگہ اس کی اپنی مخصوص فائل میں ہے. پہلے کے برعکس، آپ چاہتے ہیں کہ آپ کا فرنٹ اینڈ انٹری پوائنٹ صرف اس مخصوص فائل کے لیے براہ راست درخواست کر کے قابل رسائی ہو جہاں انٹری پوائنٹ موجود ہو، تو اس صورت میں، آپ
auto_prepend_file یا .htaccess استعمال نہیں کرنا چاہیں گے.اپنا فرنٹ اینڈ انٹری پوائنٹ بنانے کے بعد، اس تک رسائی کے لیے اپنے براؤزر کا استعمال کریں. ایک لاگ ان صفحہ ظاہر ہونا چاہئے. لاگ ان صفحہ پر، پہلے سے طے شدہ صارف نام اور پاس ورڈ (admin/password) درج کریں اور لاگ ان بٹن دبائیں.
نوٹ: اگر آپ کو پہلی بار کے لئے لاگ ان کرنے کے بعد، سامنے کے آخر تک غیر مجاز رسائی کو روکنے کے لئے، آپ کو فوری طور پر آپ کا صارف نام اور پاس ورڈ کو تبدیل کرنا چاہئے! یہ بہت اہم ہے، یہ سامنے کے آخر میں کے ذریعے آپ کی ویب سائٹ پر من مانی PHP کوڈ کو اپ لوڈ کرنا ممکن ہے کیونکہ.
اس کے علاوہ، زیادہ سے زیادہ سیکورٹی کے لئے، تمام فرنٹ اینڈ اکاؤنٹس کے لئے 2FA کو مؤثر طریقے سے سفارش کی جاتی ہے (ذیل میں دی گئی ہدایات).
ہدایات یہ اور اس مقصد کو استعمال کرنے کا صحیح طریقہ کی وضاحت کے لئے سامنے کے آخر میں کے ہر صفحے پر فراہم کی جاتی ہیں. اگر آپ کو مزید وضاحت یا کوئی خاص مدد کی ضرورت ہے، کی مدد سے رابطہ کریں. متبادل طور پر، یو ٹیوب پر دستیاب کچھ ویڈیوز مظاہرے کی راہ کی طرف مدد کر سکتا ہے جس میں موجود ہیں.
2FA کو چالو کرنے کے ذریعہ front-end کو مزید محفوظ بنانے کے لئے ممکن ہے. جب 2FA کے ساتھ اکاؤنٹ میں لاگ ان ہو تو، اس اکاؤنٹ سے منسلک ای میل ایڈریس پر ایک ای میل بھیجا جاتا ہے. اس ای میل میں "2FA کوڈ" شامل ہے، جو اس صارف کا استعمال کرتے ہوئے لاگ ان کرنے کے لۓ صارف کا نام اور پاسورڈ کے علاوہ صارف کو داخل ہونا ضروری ہے. اس کا مطلب یہ ہے کہ اکاؤنٹ اکاؤنٹ پاس ورڈ حاصل کرنے کے لئے کسی بھی ہیکر یا ممکنہ حملہ آور کو اس اکاؤنٹ میں لاگ ان کرنے کے قابل نہیں ہو گا، کیونکہ انہیں وصول کرنے کے قابل ہونے کے لئے ان اکاؤنٹ سے منسلک ای میل ایڈریس تک رسائی حاصل ہوگی. اور سیشن کے ساتھ منسلک 2FA کوڈ استعمال کریں.
سب سے پہلے، 2FA کو چالو کرنے کے لئے، PHPMailer اجزاء کو انسٹال کرنے کے لئے front-end اپ ڈیٹس کا صفحہ استعمال کریں. ای میل بھیجنے کے لئے CIDRAM PHPMailer کا استعمال کرتا ہے.
PHPMailer نصب کرنے کے بعد، آپ کو CIDRAM ترتیب کے صفحے یا ترتیب کی فائل کے ذریعے PHPMailer کے لئے ترتیب ہدایات کو آباد کرنے کی ضرورت ہوگی. ان ترتیبات کے ہدایات کے بارے میں مزید معلومات اس دستاویز کے ترتیب کے حصے میں شامل ہیں. PHPMailer ترتیب ہدایات آبادی کے بعد،
enable_two_factor true سیٹ کریں. 2FA اب فعال ہونا چاہئے.اگلا، آپ کو ایک ای میل ایڈریس کو اکاؤنٹ کے ساتھ منسلک کرنے کی ضرورت ہوگی، تاکہ CIDRAM کو معلوم ہے کہ اس اکاؤنٹ کے ساتھ لاگ ان کرتے وقت 2FA کوڈ بھیجنے کے لئے. ایسا کرنے کے لئے، اکاؤنٹ کے صارف نام کے طور پر ای میل پتہ استعمال کریں (کچھ
[email protected] کی طرح)، یا اس صارف کے صارف کے حصے کے طور پر ای میل ایڈریس بھی شامل ہے جس طرح آپ عام طور پر ای میل بھیجیں گے (کچھ Foo Bar <[email protected]> کی طرح).نوٹ: غیر مجاز رسائی کے خلاف vault کی حفاظت خاص طور پر اہم ہے (مثال کے طور پر، آپ کے سرور کی سیکیورٹی کو مضبوط کرنا، عوامی رسائی کی اجازت محدود)، کیونکہ غیر مجاز رسائی آپ کے SMTP ترتیبات کو بے نقاب کر سکتا ہے (اس میں SMTP صارف کا نام اور پاس ورڈ بھی شامل ہے). آپ کو اس بات کو یقینی بنانا چاہئے کہ 2FA کو چالو کرنے سے پہلے vault مناسب طریقے سے محفوظ ہو. اگر آپ ایسا کرنے میں قاصر ہیں تو، کم سے کم، آپ کو ایک نیا ای میل اکاؤنٹ بنانا چاہئے، اس مقصد کیلئے وقف کردہ SMTP ترتیبات کے خطرات کو کم کرنے کے لئے.
ندرجہ ذیل ان ہدایات کے مقصد کی وضاحت کے ساتھ ساتھ،
"config.yml" ترتیب فائل میں CIDRAM کو دستیاب ہدایات کی ایک فہرست ہے.کنفگریشن (v3)
│
├───general
│ stages [string]
│ fields [string]
│ timezone [string]
│ time_offset [int]
│ time_format [string]
│ ipaddr [string]
│ http_response_header_code [int]
│ silent_mode [string]
│ silent_mode_response_header_code [int]
│ lang [string]
│ lang_override [bool]
│ numbers [string]
│ emailaddr [string]
│ emailaddr_display_style [string]
│ ban_override [int]
│ default_dns [string]
│ default_algo [string]
│ statistics [string]
│ force_hostname_lookup [bool]
│ allow_gethostbyaddr_lookup [bool]
│ disabled_channels [string]
│ default_timeout [int]
│ sensitive [string]
│ email_notification_address [string]
│ email_notification_name [string]
│ email_notification_when [string]
├───components
│ ipv4 [string]
│ ipv6 [string]
│ modules [string]
│ imports [string]
│ events [string]
├───logging
│ standard_log [string]
│ apache_style_log [string]
│ serialised_log [string]
│ error_log [string]
│ outbound_request_log [string]
│ report_log [string]
│ truncate [string]
│ log_rotation_limit [int]
│ log_rotation_action [string]
│ log_banned_ips [bool]
│ log_sanitisation [bool]
├───frontend
│ frontend_log [string]
│ signatures_update_event_log [string]
│ max_login_attempts [int]
│ theme [string]
│ magnification [float]
│ custom_header [string]
│ custom_footer [string]
│ remotes [string]
│ enable_two_factor [bool]
├───signatures
│ shorthand [string]
│ default_tracktime [string]
│ infraction_limit [int]
│ tracking_override [bool]
│ conflict_response [int]
├───verification
│ search_engines [string]
│ social_media [string]
│ other [string]
│ adjust [string]
├───recaptcha
│ usemode [int]
│ lockip [bool]
│ lockuser [bool]
│ sitekey [string]
│ secret [string]
│ expiry [float]
│ recaptcha_log [string]
│ signature_limit [int]
│ api [string]
│ show_cookie_warning [bool]
│ show_api_message [bool]
│ nonblocked_status_code [int]
├───hcaptcha
│ usemode [int]
│ lockip [bool]
│ lockuser [bool]
│ sitekey [string]
│ secret [string]
│ expiry [float]
│ hcaptcha_log [string]
│ signature_limit [int]
│ api [string]
│ show_cookie_warning [bool]
│ show_api_message [bool]
│ nonblocked_status_code [int]
├───legal
│ pseudonymise_ip_addresses [bool]
│ privacy_policy [string]
├───template_data
│ theme [string]
│ magnification [float]
│ css_url [string]
│ block_event_title [string]
│ captcha_title [string]
│ custom_header [string]
│ custom_footer [string]
├───rate_limiting
│ max_bandwidth [string]
│ max_requests [int]
│ precision_ipv4 [int]
│ precision_ipv6 [int]
│ allowance_period [string]
│ exceptions [string]
│ segregate [bool]
├───supplementary_cache_options
│ prefix [string]
│ enable_apcu [bool]
│ enable_memcached [bool]
│ enable_redis [bool]
│ enable_pdo [bool]
│ memcached_host [string]
│ memcached_port [int]
│ redis_host [string]
│ redis_port [int]
│ redis_timeout [float]
│ redis_database_number [int]
│ pdo_dsn [string]
│ pdo_username [string]
│ pdo_password [string]
└───bypasses
used [string]عام ترتیبات (کنفیگریشن جس کا تعلق دوسری قسموں سے نہیں ہے).
- عمل درآمد کے مراحل کے لیے کنٹرول (فعال کرنے کے اقدامات، غلطی لاگنگ، وغیرہ).
stages
├─Tests ("دستخطی فائلوں کے ٹیسٹ پر عمل کریں")
├─Modules ("ماڈیولز پر عمل کریں")
├─SearchEngineVerification ("سرچ انجن کی تصدیق پر عمل کریں")
├─SocialMediaVerification ("سوشل میڈیا کی تصدیق پر عمل کریں")
├─OtherVerification ("دوسری توثیق پر عمل کریں")
├─Aux ("معاون قوانین پر عمل کریں")
├─Tracking ("IP ٹریکنگ پر عمل کریں")
├─RL ("ریٹ محدود کرنے پر عمل کریں")
├─CAPTCHA ("CAPTCHA تعینات کریں (بلاک شدہ درخواستیں)")
├─Reporting ("رپورٹنگ پر عمل کریں")
├─Statistics ("اعداد و شمار کو اپ ڈیٹ کریں")
├─Webhooks ("ویب ہکس پر عمل کریں")
├─PrepareFields ("آؤٹ پٹ اور لاگز کے لیے فیلڈز تیار کریں")
├─Output ("آؤٹ پٹ پیدا کریں (بلاک شدہ درخواستیں)")
├─WriteLogs ("لاگ فائلوں میں لکھیں (بلاک شدہ درخواستیں)")
├─Terminate ("درخواست کو ختم کریں (بلاک شدہ درخواستیں)")
├─AuxRedirect ("معاون قوانین کے مطابق ری ڈائریکٹ کریں")
└─NonBlockedCAPTCHA ("CAPTCHA تعینات کریں (غیر مسدود درخواستیں)")- بلاک ہونے پر فیلڈز کے لیے کنٹرول (جب کوئی درخواست بلاک ہو جاتی ہے).
fields
├─ID ("ID")
├─ScriptIdent ("اسکرپٹ ورژن")
├─DateTime ("تاریخ وقت")
├─IPAddr ("IP پتہ")
├─IPAddrResolved ("IP پتہ (حل کیا)")
├─Query ("طلب")
├─Referrer ("حوالہ دہندہ")
├─UA ("صارف ایجنٹ")
├─UALC ("صارف ایجنٹ (کم کیس)")
├─SignatureCount ("دستخط شمار")
├─Signatures ("دستخط حوالہ")
├─WhyReason ("کیوں بلاک شدہ")
├─ReasonMessage ("کیوں بلاک شدہ (تفصیلی)")
├─rURI ("دوبارہ تعمیر URI")
├─Infractions ("خلاف ورزی")
├─ASNLookup ("** ASN کی تلاش")
├─CCLookup ("** ملک کا کوڈ کی تلاش")
├─Verified ("تصدیق شدہ شناخت")
├─Expired ("میعاد ختم")
├─Ignored ("نظر انداز")
├─Request_Method ("درخواست کا طریقہ")
├─Protocol ("پروٹوکول")
├─SEC_CH_UA_PLATFORM ("!! SEC_CH_UA_PLATFORM")
├─SEC_CH_UA_MOBILE ("!! SEC_CH_UA_MOBILE")
├─SEC_CH_UA ("!! SEC_CH_UA")
├─Hostname ("میزبان کا نام")
├─CAPTCHA ("CAPTCHA کے ریاست")
├─Inspection ("* حالات کا معائنہ")
└─ClientL10NAccepted ("زبان کا حل")- صرف معاون قواعد کو ڈیبگ کرنے کے لیے بنایا گیا ہے. مسدود صارفین کو ظاہر نہیں کیا گیا.
** ASN تلاش کی فعالیت کی ضرورت ہے (مثال کے طور پر، IP-API یا BGPView ماڈیول کے ذریعے).
!! یہ کم اینٹروپی کلائنٹ کا اشارہ ہے. کلائنٹ کے اشارے ایک نئی، تجرباتی ویب ٹیکنالوجی ہے جو ابھی تک تمام براؤزرز اور بڑے کلائنٹس میں وسیع پیمانے پر تعاون یافتہ نہیں ہے. دیکھیں: Sec-CH-UA - HTTP | MDN. اگرچہ کلائنٹ کے اشارے فنگر پرنٹنگ کے لیے کارآمد ثابت ہو سکتے ہیں، کیونکہ وہ وسیع پیمانے پر تعاون یافتہ نہیں ہیں، لیکن درخواستوں میں ان کی موجودگی کو فرض نہیں کیا جانا چاہیے اور نہ ہی ان پر انحصار کیا جانا چاہیے (یعنی، ان کی غیر موجودگی کی بنیاد پر بلاک کرنا ایک برا خیال ہے).
- استعمال کرنے کے لئے ٹائم زون کی وضاحت کرتا ہے (جیسے، Africa/Cairo، America/New_York، Asia/Tokyo، Australia/Perth، Europe/Berlin، Pacific/Guam، وغیرہ). SYSTEM کی وضاحت کریں تاکہ PHP کو آپ کے لئے خود بخود یہ سنبھل سکے.
timezone
├─SYSTEM ("نظام کو پہلے سے طے شدہ ٹائم زون کا استعمال کریں.")
├─UTC ("UTC")
└─…دیگر- ٹائم زون منٹ میں آفسیٹ.
- CIDRAM کی طرف سے استعمال کی تاریخوں کا فارم. اضافی اختیارات درخواست پر شامل کیا جا سکتا ہے.
time_format
├─{Day}, {dd} {Mon} {yyyy} {hh}:{ii}:{ss} {tz} ("{Day}, {dd} {Mon} {yyyy} {hh}:{ii}:{ss} {tz}")
├─{Day}, {dd} {Mon} {yyyy} {hh}:{ii}:{ss} ("{Day}, {dd} {Mon} {yyyy} {hh}:{ii}:{ss}")
├─{Day}, {dd} {Mon} {yyyy} ("{Day}, {dd} {Mon} {yyyy}")
├─{yyyy}.{mm}.{dd} {hh}:{ii}:{ss} {tz} ("{yyyy}.{mm}.{dd} {hh}:{ii}:{ss} {tz}")
├─{yyyy}.{mm}.{dd} {hh}:{ii}:{ss} ("{yyyy}.{mm}.{dd} {hh}:{ii}:{ss}")
├─{yyyy}.{mm}.{dd} ("{yyyy}.{mm}.{dd}")
├─{yyyy}-{mm}-{dd} {hh}:{ii}:{ss} {tz} ("{yyyy}-{mm}-{dd} {hh}:{ii}:{ss} {tz}")
├─{yyyy}-{mm}-{dd} {hh}:{ii}:{ss} ("{yyyy}-{mm}-{dd} {hh}:{ii}:{ss}")
├─{yyyy}-{mm}-{dd} ("{yyyy}-{mm}-{dd}")
├─{yyyy}/{mm}/{dd} {hh}:{ii}:{ss} {tz} ("{yyyy}/{mm}/{dd} {hh}:{ii}:{ss} {tz}")
├─{yyyy}/{mm}/{dd} {hh}:{ii}:{ss} ("{yyyy}/{mm}/{dd} {hh}:{ii}:{ss}")
├─{yyyy}/{mm}/{dd} ("{yyyy}/{mm}/{dd}")
├─{dd}.{mm}.{yyyy} {hh}:{ii}:{ss} {tz} ("{dd}.{mm}.{yyyy} {hh}:{ii}:{ss} {tz}")
├─{dd}.{mm}.{yyyy} {hh}:{ii}:{ss} ("{dd}.{mm}.{yyyy} {hh}:{ii}:{ss}")
├─{dd}.{mm}.{yyyy} ("{dd}.{mm}.{yyyy}")
├─{dd}-{mm}-{yyyy} {hh}:{ii}:{ss} {tz} ("{dd}-{mm}-{yyyy} {hh}:{ii}:{ss} {tz}")
├─{dd}-{mm}-{yyyy} {hh}:{ii}:{ss} ("{dd}-{mm}-{yyyy} {hh}:{ii}:{ss}")
├─{dd}-{mm}-{yyyy} ("{dd}-{mm}-{yyyy}")
├─{dd}/{mm}/{yyyy} {hh}:{ii}:{ss} {tz} ("{dd}/{mm}/{yyyy} {hh}:{ii}:{ss} {tz}")
├─{dd}/{mm}/{yyyy} {hh}:{ii}:{ss} ("{dd}/{mm}/{yyyy} {hh}:{ii}:{ss}")
├─{dd}/{mm}/{yyyy} ("{dd}/{mm}/{yyyy}")
├─{mm}.{dd}.{yyyy} {hh}:{ii}:{ss} {tz} ("{mm}.{dd}.{yyyy} {hh}:{ii}:{ss} {tz}")
├─{mm}.{dd}.{yyyy} {hh}:{ii}:{ss} ("{mm}.{dd}.{yyyy} {hh}:{ii}:{ss}")
├─{mm}.{dd}.{yyyy} ("{mm}.{dd}.{yyyy}")
├─{mm}-{dd}-{yyyy} {hh}:{ii}:{ss} {tz} ("{mm}-{dd}-{yyyy} {hh}:{ii}:{ss} {tz}")
├─{mm}-{dd}-{yyyy} {hh}:{ii}:{ss} ("{mm}-{dd}-{yyyy} {hh}:{ii}:{ss}")
├─{mm}-{dd}-{yyyy} ("{mm}-{dd}-{yyyy}")
├─{mm}/{dd}/{yyyy} {hh}:{ii}:{ss} {tz} ("{mm}/{dd}/{yyyy} {hh}:{ii}:{ss} {tz}")
├─{mm}/{dd}/{yyyy} {hh}:{ii}:{ss} ("{mm}/{dd}/{yyyy} {hh}:{ii}:{ss}")
├─{mm}/{dd}/{yyyy} ("{mm}/{dd}/{yyyy}")
├─{yy}.{mm}.{dd} {hh}:{ii}:{ss} {tz} ("{yy}.{mm}.{dd} {hh}:{ii}:{ss} {tz}")
├─{yy}.{mm}.{dd} {hh}:{ii}:{ss} ("{yy}.{mm}.{dd} {hh}:{ii}:{ss}")
├─{yy}.{mm}.{dd} ("{yy}.{mm}.{dd}")
├─{yy}-{mm}-{dd} {hh}:{ii}:{ss} {tz} ("{yy}-{mm}-{dd} {hh}:{ii}:{ss} {tz}")
├─{yy}-{mm}-{dd} {hh}:{ii}:{ss} ("{yy}-{mm}-{dd} {hh}:{ii}:{ss}")
├─{yy}-{mm}-{dd} ("{yy}-{mm}-{dd}")
├─{yy}/{mm}/{dd} {hh}:{ii}:{ss} {tz} ("{yy}/{mm}/{dd} {hh}:{ii}:{ss} {tz}")
├─{yy}/{mm}/{dd} {hh}:{ii}:{ss} ("{yy}/{mm}/{dd} {hh}:{ii}:{ss}")
├─{yy}/{mm}/{dd} ("{yy}/{mm}/{dd}")
├─{dd}.{mm}.{yy} {hh}:{ii}:{ss} {tz} ("{dd}.{mm}.{yy} {hh}:{ii}:{ss} {tz}")
├─{dd}.{mm}.{yy} {hh}:{ii}:{ss} ("{dd}.{mm}.{yy} {hh}:{ii}:{ss}")
├─{dd}.{mm}.{yy} ("{dd}.{mm}.{yy}")
├─{dd}-{mm}-{yy} {hh}:{ii}:{ss} {tz} ("{dd}-{mm}-{yy} {hh}:{ii}:{ss} {tz}")
├─{dd}-{mm}-{yy} {hh}:{ii}:{ss} ("{dd}-{mm}-{yy} {hh}:{ii}:{ss}")
├─{dd}-{mm}-{yy} ("{dd}-{mm}-{yy}")
├─{dd}/{mm}/{yy} {hh}:{ii}:{ss} {tz} ("{dd}/{mm}/{yy} {hh}:{ii}:{ss} {tz}")
├─{dd}/{mm}/{yy} {hh}:{ii}:{ss} ("{dd}/{mm}/{yy} {hh}:{ii}:{ss}")
├─{dd}/{mm}/{yy} ("{dd}/{mm}/{yy}")
├─{mm}.{dd}.{yy} {hh}:{ii}:{ss} {tz} ("{mm}.{dd}.{yy} {hh}:{ii}:{ss} {tz}")
├─{mm}.{dd}.{yy} {hh}:{ii}:{ss} ("{mm}.{dd}.{yy} {hh}:{ii}:{ss}")
├─{mm}.{dd}.{yy} ("{mm}.{dd}.{yy}")
├─{mm}-{dd}-{yy} {hh}:{ii}:{ss} {tz} ("{mm}-{dd}-{yy} {hh}:{ii}:{ss} {tz}")
├─{mm}-{dd}-{yy} {hh}:{ii}:{ss} ("{mm}-{dd}-{yy} {hh}:{ii}:{ss}")
├─{mm}-{dd}-{yy} ("{mm}-{dd}-{yy}")
├─{mm}/{dd}/{yy} {hh}:{ii}:{ss} {tz} ("{mm}/{dd}/{yy} {hh}:{ii}:{ss} {tz}")
├─{mm}/{dd}/{yy} {hh}:{ii}:{ss} ("{mm}/{dd}/{yy} {hh}:{ii}:{ss}")
├─{mm}/{dd}/{yy} ("{mm}/{dd}/{yy}")
├─{yyyy}年{m}月{d}日 {hh}時{ii}分{ss}秒 ("{yyyy}年{m}月{d}日 {hh}時{ii}分{ss}秒")
├─{yyyy}年{m}月{d}日 {hh}:{ii}:{ss} {tz} ("{yyyy}年{m}月{d}日 {hh}:{ii}:{ss} {tz}")
├─{yyyy}年{m}月{d}日 ("{yyyy}年{m}月{d}日")
├─{yy}年{m}月{d}日 {hh}時{ii}分{ss}秒 ("{yy}年{m}月{d}日 {hh}時{ii}分{ss}秒")
├─{yy}年{m}月{d}日 {hh}:{ii}:{ss} {tz} ("{yy}年{m}月{d}日 {hh}:{ii}:{ss} {tz}")
├─{yy}年{m}月{d}日 ("{yy}年{m}月{d}日")
├─{yyyy}년 {m}월 {d}일 {hh}시 {ii}분 {ss}초 ("{yyyy}년 {m}월 {d}일 {hh}시 {ii}분 {ss}초")
├─{yyyy}년 {m}월 {d}일 {hh}:{ii}:{ss} {tz} ("{yyyy}년 {m}월 {d}일 {hh}:{ii}:{ss} {tz}")
├─{yyyy}년 {m}월 {d}일 ("{yyyy}년 {m}월 {d}일")
├─{yy}년 {m}월 {d}일 {hh}시 {ii}분 {ss}초 ("{yy}년 {m}월 {d}일 {hh}시 {ii}분 {ss}초")
├─{yy}년 {m}월 {d}일 {hh}:{ii}:{ss} {tz} ("{yy}년 {m}월 {d}일 {hh}:{ii}:{ss} {tz}")
├─{yy}년 {m}월 {d}일 ("{yy}년 {m}월 {d}일")
├─{yyyy}-{mm}-{dd}T{hh}:{ii}:{ss}{t:z} ("{yyyy}-{mm}-{dd}T{hh}:{ii}:{ss}{t:z}")
├─{d}. {m}. {yyyy} ("{d}. {m}. {yyyy}")
└─…دیگرپلیس ہولڈر – وضاحت – 2024-04-30T18:27:49+08:00 پر مبنی مثال.
{yyyy} – سال – جیسے، 2024.
{yy} – مختصر سال – جیسے، 24.
{Mon} – مہینے کا مختصر نام (انگریزی میں) – جیسے، Apr.
{mm} – پہلے صفر کے ساتھ مہینے – جیسے، 04.
{m} – مہینے – جیسے، 4.
{Day} – دن کا مختصر نام (انگریزی میں) – جیسے، Tue.
{dd} – پہلے صفر کے ساتھ دن – جیسے، 30.
{d} – دن – جیسے، 30.
{hh} – پہلے صفر کے ساتھ گھنٹہ (24 گھنٹے کا وقت استعمال کرتا ہے) – جیسے، 18.
{h} – گھنٹہ (24 گھنٹے کا وقت استعمال کرتا ہے) – جیسے، 18.
{ii} – پہلے صفر کے ساتھ منٹ – جیسے، 27.
{i} – منٹ – جیسے، 27.
{ss} – پہلے صفر کے ساتھ سیکنڈ – جیسے، 49.
{s} – سیکنڈ – جیسے، 49.
{tz} – ٹائم زون (بغیر رابطہ کے) – جیسے، +0800.
{t:z} – ٹائم زون (رابطہ کے ساتھ) – جیسے، +08:00.
- کہاں درخواستوں منسلک کرنے کے IP ایڈریس کو تلاش کرنے کے لئے؟ (جیسا Cloudflare کے طور پر خدمات اور پسند کرتا ہے کے لئے مفید). پہلے سے طے شدہ = REMOTE_ADDR. انتباہ: جب تک کہ آپ کو پتہ ہے تم کیا کر رہے ہو اس کو تبدیل نہ کریں!
ipaddr
├─HTTP_INCAP_CLIENT_IP ("HTTP_INCAP_CLIENT_IP (Incapsula)")
├─HTTP_CF_CONNECTING_IP ("HTTP_CF_CONNECTING_IP (Cloudflare)")
├─CF-Connecting-IP ("CF-Connecting-IP (Cloudflare)")
├─HTTP_X_FORWARDED_FOR ("HTTP_X_FORWARDED_FOR (Cloudbric)")
├─X-Forwarded-For ("X-Forwarded-For (Squid)")
├─Forwarded ("Forwarded")
├─REMOTE_ADDR ("REMOTE_ADDR (پہلے سے طے شدہ)")
└─…دیگر- درخواستوں کو روکنے پر بھیجنے کے لئے HTTP حیثیت کا پیغام.
http_response_header_code
├─200 (200 OK (ٹھیک ہے)): کم سے کم مضبوط، لیکن سب سے زیادہ صارف دوست.
│ خودکار درخواستیں غالباً اس جواب کی تشریح
│ کریں گی کہ درخواست کامیاب تھی.
├─403 (403 Forbidden (ممنوعہ)): زیادہ مضبوط، لیکن کم صارف دوست. زیادہ تر
│ عام حالات کے لیے تجویز کردہ.
├─410 (410 Gone (چلا گیا)): غلط مثبت کو حل کرتے وقت مسائل پیدا ہوسکتے
│ ہیں، کیونکہ کچھ براؤزر اس اسٹیٹس میسج کو
│ کیش کریں گے اور بعد میں درخواستیں نہیں
│ بھیجیں گے. کچھ سیاق و سباق میں استعمال
│ کرنے کے لیے بہترین ہو سکتا ہے.
├─418 (418 I'm a teapot (میں چائے کا برتن)): اپریل فول کے لطیفے کا حوالہ دیتے ہیں (<a
│ href="https://tools.ietf.org/html/rfc2324" dir="ltr" hreflang="en-US"
│ rel="noopener noreferrer external">RFC 2324</a>). کسی بھی
│ کلائنٹ، بوٹ، براؤزر، یا کسی اور طرح سے
│ سمجھنے کا امکان نہیں ہے. تفریح اور سہولت
│ کے لیے فراہم کی گئی ہے، لیکن عام طور پر
│ تجویز نہیں کی جاتی ہے.
├─451 (451 Unavailable For Legal Reasons (قانونی وجوہات کی بنا پر دستیاب نہیں ہے)): بنیادی طور پر قانونی وجوہات کی بنا پر
│ مسدود کرنے پر تجویز کیا جاتا ہے. دوسرے
│ سیاق و سباق میں سفارش نہیں کی جاتی ہے.
└─503 (503 Service Unavailable (سروس میسر نہیں)): سب سے زیادہ مضبوط، لیکن کم از کم صارف دوست.
حملے کے دوران، یا انتہائی مسلسل ناپسندیدہ
ٹریفک سے نمٹنے کے لیے تجویز کردہ.- خاموشی CIDRAM چاہئے "رسائی مسترد کر دی" کے صفحے کی نمائش سے بلاک رسائی کی کوششوں کو ری ڈائریکٹ کرنے کے بجائے؟ ہاں تو، کو بلاک کر تک رسائی کی کوششوں کو ری ڈائریکٹ کرنے کے محل وقوع کی وضاحت. کوئی تو اس متغیر خالی چھوڑ.
- بلاک شدہ رسائی کی کوششوں کو خاموشی سے ری ڈائریکٹ کرتے وقت CIDRAM کو کون سا HTTP اسٹیٹس پیغام بھیجنا چاہیے؟
silent_mode_response_header_code
├─301 (301 Moved Permanently (مستقل طور پر منتقل ہو گیا)): کلائنٹ کو ہدایت کرتا ہے کہ ری ڈائریکٹ
│ مستقل ہے، اور یہ کہ ری ڈائریکٹ کے لیے
│ استعمال ہونے والا کا طریقہ ابتدائی
│ درخواست کے لیے استعمال کیے جانے والے
│ درخواست کے طریقہ سے مختلف ہو سکتا ہے.
├─302 (302 Found (ملا)): کلائنٹ کو ہدایت کرتا ہے کہ ری ڈائریکٹ
│ عارضی ہے، اور یہ کہ ری ڈائریکٹ کے لیے
│ استعمال ہونے والا درخواست کا طریقہ
│ ابتدائی درخواست کے لیے استعمال کیے جانے
│ والے درخواست کے طریقہ سے مختلف ہو سکتا ہے.
├─307 (307 Temporary Redirect (عارضی ری ڈائریکٹ)): کلائنٹ کو ہدایت کرتا ہے کہ ری ڈائریکٹ
│ عارضی ہے، اور یہ کہ ری ڈائریکٹ کے لیے
│ استعمال ہونے والا درخواست کا طریقہ
│ ابتدائی درخواست کے لیے استعمال کیے جانے
│ والے درخواست کے طریقہ سے مختلف نہیں ہو
│ سکتا.
└─308 (308 Permanent Redirect (مستقل ری ڈائریکٹ)): کلائنٹ کو ہدایت کرتا ہے کہ ری ڈائریکٹ
مستقل ہے، اور یہ کہ ری ڈائریکٹ کے لیے
استعمال ہونے والا درخواست کا طریقہ
ابتدائی درخواست کے لیے استعمال کیے جانے
والے درخواست کے طریقہ سے مختلف نہیں ہو
سکتا.اس بات سے کوئی فرق نہیں پڑتا ہے کہ ہم کلائنٹ کو کیسے ہدایت دیتے ہیں، یہ یاد رکھنا ضروری ہے کہ آخر کار ہمارا اس پر کوئی کنٹرول نہیں ہے کہ کلائنٹ کیا کرنا چاہتا ہے، اور اس بات کی کوئی ضمانت نہیں ہے کہ کلائنٹ ہماری ہدایات کا احترام کرے گا.
- CIDRAM لئے پہلے سے طے شدہ زبان کی وضاحت.
lang
├─af ("Afrikaans")
├─ar ("العربية")
├─bg ("Български")
├─bn ("বাংলা")
├─bs ("Bosanski")
├─ca ("Català")
├─cs ("Čeština")
├─de ("Deutsch")
├─en ("English (AU/GB/NZ)")
├─en-CA ("English (CA)")
├─en-US ("English (US)")
├─es ("Español")
├─fa ("فارسی")
├─fr ("Français")
├─gl ("Galego")
├─gu ("ગુજરાતી")
├─he ("עברית")
├─hi ("हिंदी")
├─hr ("Hrvatski")
├─id ("Bahasa Indonesia")
├─it ("Italiano")
├─ja ("日本語")
├─ko ("한국어")
├─lv ("Latviešu")
├─ml ("മലയാളം")
├─mr ("मराठी")
├─ms ("Bahasa Melayu")
├─nl ("Nederlandse")
├─no ("Norsk")
├─pa ("ਪੰਜਾਬੀ")
├─pl ("Polski")
├─pt-BR ("Português (Brasil)")
├─pt-PT ("Português (Europeu)")
├─ro ("Română")
├─ru ("Русский")
├─sv ("Svenska")
├─sr ("Српски")
├─ta ("தமிழ்")
├─th ("ภาษาไทย")
├─tr ("Türkçe")
├─uk ("Українська")
├─ur ("اردو")
├─vi ("Tiếng Việt")
├─zh-Hans ("中文（简体）")
└─zh-Hant ("中文（傳統）")- جب بھی ممکن ہو HTTP_ACCEPT_LANGUAGE کے مطابق لوکلائز کریں؟ True (سچے) = جی ہاں [پہلے سے طے شدہ]؛ False (جھوٹی) = نہیں.
- آپ کس طرح تعداد میں ظاہر کرنے کے لئے پسند کرتے ہیں؟ مثال کے طور پر منتخب کریں جو آپ کے لئے سب سے زیادہ درست نظر آتے ہیں.
numbers
├─Arabic-1 ("١٢٣٤٥٦٧٫٨٩")
├─Arabic-2 ("١٬٢٣٤٬٥٦٧٫٨٩")
├─Arabic-3 ("۱٬۲۳۴٬۵۶۷٫۸۹")
├─Arabic-4 ("۱۲٬۳۴٬۵۶۷٫۸۹")
├─Armenian ("Ճ̅Ի̅Գ̅ՏՇԿԷ")
├─Base-12 ("4b6547.a8")
├─Base-16 ("12d687.e3")
├─Bengali-1 ("১২,৩৪,৫৬৭.৮৯")
├─Burmese-1 ("၁၂၃၄၅၆၇.၈၉")
├─China-1 ("123,4567.89")
├─Chinese-Simplified ("一百二十三万四千五百六十七点八九")
├─Chinese-Simplified-Financial ("壹佰贰拾叁萬肆仟伍佰陆拾柒点捌玖")
├─Chinese-Traditional ("一百二十三萬四千五百六十七點八九")
├─Chinese-Traditional-Financial ("壹佰貳拾叄萬肆仟伍佰陸拾柒點捌玖")
├─Fullwidth ("１２３４５６７.８９")
├─Geez ("፻፳፫፼፵፭፻፷፯")
├─Hebrew ("א׳׳ב׳קג׳יד׳ךסז")
├─India-1 ("12,34,567.89")
├─India-2 ("१२,३४,५६७.८९")
├─India-3 ("૧૨,૩૪,૫૬૭.૮૯")
├─India-4 ("੧੨,੩੪,੫੬੭.੮੯")
├─India-5 ("೧೨,೩೪,೫೬೭.೮೯")
├─India-6 ("౧౨,౩౪,౫౬౭.౮౯")
├─Japanese ("百万二十万三万四千五百六十七・八九分")
├─Javanese ("꧑꧒꧓꧔꧕꧖꧗.꧘꧙")
├─Khmer-1 ("១.២៣៤.៥៦៧,៨៩")
├─Lao-1 ("໑໒໓໔໕໖໗.໘໙")
├─Latin-1 ("1,234,567.89")
├─Latin-2 ("1 234 567.89")
├─Latin-3 ("1.234.567,89")
├─Latin-4 ("1 234 567,89")
├─Latin-5 ("1,234,567·89")
├─Mayan ("𝋧𝋮𝋦𝋨𝋧.𝋱𝋰")
├─Mongolian ("᠑᠒᠓᠔᠕᠖᠗.᠘᠙")
├─NoSep-1 ("1234567.89")
├─NoSep-2 ("1234567,89")
├─Odia ("୧୨୩୪୫୬୭.୮୯")
├─Roman ("M̅C̅C̅X̅X̅X̅I̅V̅DLXVII")
├─SDN-Dwiggins ("4E6,547;X8")
├─SDN-Pitman ("4↋6,547;↊8")
├─Tamil ("௲௲௨௱௲௩௰௲௪௲௫௱௬௰௭")
├─Thai-1 ("๑,๒๓๔,๕๖๗.๘๙")
├─Thai-2 ("๑๒๓๔๕๖๗.๘๙")
└─Tibetan ("༡༢༣༤༥༦༧.༨༩")- اگر آپ چاہتے ہیں، تو آپ صارفین کو جب انہیں بلاک کر رہے ہیں تو دینے کے لئے ای میل ایڈریس کی فراہمی کر سکتے ہیں.وہ اسے استعمال آپ سے رابطہ کرنے کے لئے کر سکتے ہیں اگر وہ غلطی سے بلاک کر رہے ہیں. انتباہ: آپ جو بھی ای میل ایڈریس پر فراہمی کرتے ہیں، وہ یقینی طور پر سپےمبٹس اور کھرچنی کی طرف سے حاصل کئے جائیں گے. اس کی وجہ سے، اس کی سختی سے سفارش کی جاتی ہے کہ آپ ایک ای میل ایڈریس انتخاب کرتے ہیں جو ڈسپوزایبل یا غیر اہم ہے (یعنی.، آپ کی ذاتی یا کاروباری ای میل ایڈریس کا استعمال نہ کریں).
- آپ کو ای میل ایڈریس کو کس طرح صارفین کو پیش کرنا پسند ہے؟
emailaddr_display_style
├─default ("کلک کرنے والے لنک")
└─noclick ("متن جو کلک نہیں کیا جا سکتا")- "http_response_header_code" کی جگہ لے لے، جب "infraction_limit" حد سے تجاوز کر رہا ہے؟ 200 = جگہ لے لے نہیں ہے [پہلے سے طے شدہ]. دیگر اقدار "http_response_header_code" کے لئے دستیاب اقدار کے طور پر اسی ہیں.
ban_override
├─200 (200 OK (ٹھیک ہے)): کم سے کم مضبوط، لیکن سب سے زیادہ صارف دوست.
│ خودکار درخواستیں غالباً اس جواب کی تشریح
│ کریں گی کہ درخواست کامیاب تھی.
├─403 (403 Forbidden (ممنوعہ)): زیادہ مضبوط، لیکن کم صارف دوست. زیادہ تر
│ عام حالات کے لیے تجویز کردہ.
├─410 (410 Gone (چلا گیا)): غلط مثبت کو حل کرتے وقت مسائل پیدا ہوسکتے
│ ہیں، کیونکہ کچھ براؤزر اس اسٹیٹس میسج کو
│ کیش کریں گے اور بعد میں درخواستیں نہیں
│ بھیجیں گے. کچھ سیاق و سباق میں استعمال
│ کرنے کے لیے بہترین ہو سکتا ہے.
├─418 (418 I'm a teapot (میں چائے کا برتن)): اپریل فول کے لطیفے کا حوالہ دیتے ہیں (<a
│ href="https://tools.ietf.org/html/rfc2324" dir="ltr" hreflang="en-US"
│ rel="noopener noreferrer external">RFC 2324</a>). کسی بھی
│ کلائنٹ، بوٹ، براؤزر، یا کسی اور طرح سے
│ سمجھنے کا امکان نہیں ہے. تفریح اور سہولت
│ کے لیے فراہم کی گئی ہے، لیکن عام طور پر
│ تجویز نہیں کی جاتی ہے.
├─451 (451 Unavailable For Legal Reasons (قانونی وجوہات کی بنا پر دستیاب نہیں ہے)): بنیادی طور پر قانونی وجوہات کی بنا پر
│ مسدود کرنے پر تجویز کیا جاتا ہے. دوسرے
│ سیاق و سباق میں سفارش نہیں کی جاتی ہے.
└─503 (503 Service Unavailable (سروس میسر نہیں)): سب سے زیادہ مضبوط، لیکن کم از کم صارف دوست.
حملے کے دوران، یا انتہائی مسلسل ناپسندیدہ
ٹریفک سے نمٹنے کے لیے تجویز کردہ.- میزبان نام تلاش کرنے کے لیے استعمال کرنے کے لیے DNS سرورز کی فہرست. انتباہ: جب تک کہ آپ کو پتہ ہے تم کیا کر رہے ہو اس کو تبدیل نہ کریں!
FAQ. میں "default_dns" کے لئے کیا استعمال کر سکتا ہوں؟
- اس بات کی وضاحت کرتا ہے جو تمام مستقبل کے پاس ورڈ اور سیشن کے لئے الگورتھم استعمال کرنا ہے.
default_algo
├─PASSWORD_DEFAULT ("PASSWORD_DEFAULT")
├─PASSWORD_BCRYPT ("PASSWORD_BCRYPT")
├─PASSWORD_ARGON2I ("PASSWORD_ARGON2I")
└─PASSWORD_ARGON2ID ("PASSWORD_ARGON2ID (PHP >= 7.3.0)")- کنٹرول کرتا ہے کہ کون سی شماریاتی معلومات کو ٹریک کرنا ہے.
statistics
├─Blocked-IPv4 ("کی درخواستیں بلاک – IPv4")
├─Blocked-IPv6 ("کی درخواستیں بلاک – IPv6")
├─Blocked-Other ("کی درخواستیں بلاک – دیگر")
├─Banned-IPv4 ("کی درخواستیں کالعدم – IPv4")
├─Banned-IPv6 ("کی درخواستیں کالعدم – IPv6")
├─Passed-IPv4 ("درخواستیں گزر گئیں – IPv4")
├─Passed-IPv6 ("درخواستیں گزر گئیں – IPv6")
├─Passed-Other ("درخواستیں گزر گئیں – دیگر")
├─CAPTCHAs-Failed ("کوششیں CAPTCHA – ناکامی!")
├─CAPTCHAs-Passed ("کوششیں CAPTCHA – ایوان کے پاس!")
├─Reported-IPv4-OK ("درخواستوں کی اطلاع بیرونی API کو دی گئی – IPv4 – ٹھیک ہے")
├─Reported-IPv4-Failed ("درخواستوں کی اطلاع بیرونی API کو دی گئی – IPv4 – ناکامی")
├─Reported-IPv6-OK ("درخواستوں کی اطلاع بیرونی API کو دی گئی – IPv6 – ٹھیک ہے")
└─Reported-IPv6-Failed ("درخواستوں کی اطلاع بیرونی API کو دی گئی – IPv6 – ناکامی")نوٹ: معاون قواعد کے اعداد و شمار کو ٹریک کرنا ہے یا نہیں، معاون قواعد کے صفحہ سے کنٹرول کیا جا سکتا ہے.
- تمام درخواستوں کے لئے میزبانی حاصل کریں؟ True (سچے) = جی ہاں؛ False (جھوٹی) = نہیں [پہلے سے طے شدہ]. میزبان نام کی تلاش عام طور پر "ضرورت کی بنیاد" کی بنیاد پر انجام دیا جاتا ہے، لیکن تمام درخواستوں کے لئے مجبور کیا جاسکتا ہے. ایسا کرتے ہوئے لاگ ان میں مزید تفصیلی معلومات فراہم کرنے کے ذریعہ مفید ثابت ہوسکتا ہے، لیکن کارکردگی پر تھوڑا منفی اثر بھی ہوسکتا ہے.
- جب UDP دستیاب نہیں ہے تو gethostbyaddr کی تلاش کی اجازت دیں؟ True (سچے) = جی ہاں [پہلے سے طے شدہ]؛ False (جھوٹی) = نہیں.
نوٹ: ہو سکتا ہے IPv6 تلاش کچھ 32 بٹ سسٹمز پر صحیح طریقے سے کام نہ کرے.
- درخواستوں کو بھیجنے کے لئے خاص طور پر چینلز کا استعمال کے لئے CIDRAM کو روکنے کے لئے یہ استعمال کیا جا سکتا ہے (مثال کے طور پر، جب اپ ڈیٹ کرنا، اجزاء میٹا ڈیٹا، وغیرہ کو پکڑنے کے بعد).
disabled_channels
├─GitHub ("GitHub")
├─BitBucket ("BitBucket")
└─GoogleDNS ("GoogleDNS")- بیرونی درخواستوں کے لئے استعمال کرنے کیلئے پہلے سے طے شدہ ٹائم آؤٹ؟ پہلے سے طے شدہ = 12 سیکنڈ.
- حساس صفحات کے طور پر شمار کرنے کے لیے راستوں کی فہرست. فہرست میں شامل ہر راستے کو ضرورت پڑنے پر دوبارہ تعمیر شدہ URI کے خلاف چیک کیا جائے گا. ایک راستہ جو فارورڈ سلیش سے شروع ہوتا ہے اسے لغوی سمجھا جائے گا، اور درخواست کے پاتھ جزو سے مماثل ہوگا. ایک راستہ جو ایک غیر حروفِ عددی کریکٹر سے شروع ہوتا ہے، اور اسی کریکٹر (یا وہی کریکٹر کے علاوہ ایک اختیاری "i" جھنڈا) پر ختم ہوتا ہے اسے ریگولر ایکسپریشن سمجھا جائے گا. کسی دوسرے قسم کے راستے کو لفظی سمجھا جائے گا، اور URI کے کسی بھی حصے سے مماثل ہو سکتا ہے. ایک پاتھ کو حساس صفحہ کے طور پر سمجھا جا سکتا ہے کچھ ماڈیولز کے برتاؤ کو متاثر کر سکتا ہے، لیکن اس کا کوئی دوسرا اثر نہیں ہوتا ہے.
- اگر آپ نے CIDRAM سے ای میل کے ذریعے اطلاعات موصول کرنے کا انتخاب کیا ہے، مثال کے طور پر، جب مخصوص معاون قوانین کو متحرک کیا جاتا ہے، آپ ان اطلاعات کے لیے وصول کنندہ کا پتہ یہاں بتا سکتے ہیں.
- اگر آپ نے CIDRAM سے ای میل کے ذریعے اطلاعات موصول کرنے کا انتخاب کیا ہے، مثال کے طور پر، جب مخصوص معاون قوانین کو متحرک کیا جاتا ہے، آپ ان اطلاعات کے لیے وصول کنندہ کا نام یہاں بتا سکتے ہیں.
- جنریٹ ہونے کے بعد اطلاعات کب بھیجیں.
email_notification_when
├─Immediately ("فوراً.")
├─After24Hours ("24 گھنٹوں کے بعد، ایک ساتھ بنڈل (یا جب دستی طور پر ٹرگر کیا جاتا ہے، جیسے، cron کے ذریعے).")
└─ManuallyOnly ("صرف اس وقت جب دستی طور پر ٹرگر کیا جائے (جیسے، cron کے ذریعے).")CIDRAM کی طرف سے استعمال ہونے والے اجزاء کو چالو کرنے اور غیر فعال کرنے کے لئے ترتیب. عام طور پر اپ ڈیٹس صفحہ کے ذریعے آباد ہوتا ہے، لیکن بہتر کنٹرول کے لیے اور اپ ڈیٹس صفحہ کے ذریعے پہچانے جانے والے حسب ضرورت اجزاء کے لیے بھی یہاں سے منظم کیا جا سکتا ہے.
- IPv4 دستخطی فائلیں.
- IPv6 دستخطی فائلیں.
- ماڈیولز.
- درآمدات. عام طور پر CIDRAM کو جزو کی ترتیب کی معلومات فراہم کرنے کے لیے استعمال کیا جاتا ہے.
- ایونٹ ہینڈلرز. عام طور پر استعمال کیا جاتا ہے جس طرح سے CIDRAM اندرونی طور پر برتاؤ کرتا ہے یا اضافی فعالیت فراہم کرتا ہے.
لاگنگ سے متعلق کنفیگریشن (اس کو چھوڑ کر جو دیگر زمروں پر لاگو ہوتا ہے).
- تمام بلاک کر تک رسائی کی کوششوں کو لاگ ان کرنے کے لئے انسانی قابل مطالعہ فائل. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.
مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز general➡time_format پر دکھائے جاتے ہیں.
- تمام بلاک کر تک رسائی کی کوششوں کو لاگ ان کرنے کے لئے اپاچی طرز فائل. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.
مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز general➡time_format پر دکھائے جاتے ہیں.
- تمام بلاک کر تک رسائی کی کوششوں کو لاگ ان کرنے کے لئے serialized کی فائل. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.
مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز general➡time_format پر دکھائے جاتے ہیں.
- کسی بھی غیر مہلک غلطیوں کو لاگ کرنے کیلئے ایک فائل کا پتہ چلا. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.
مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز general➡time_format پر دکھائے جاتے ہیں.
- کسی بھی آؤٹ باؤنڈ درخواستوں کے نتائج کو لاگ ان کرنے کے لیے ایک فائل. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.
مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز general➡time_format پر دکھائے جاتے ہیں.
- بیرونی API کو بھیجی گئی کسی بھی رپورٹ کو لاگ ان کرنے کے لیے ایک فائل. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.
مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز general➡time_format پر دکھائے جاتے ہیں.
- وہ ایک خاص سائز تک پہنچنے میں جب صاف لاگ مسلیں؟ ویلیو میں B/KB/MB/GB/TB زیادہ سے زیادہ سائز ہے. جب 0KB، وہ غیر معینہ مدت تک ترقی کر سکتا ہے (پہلے سے طے). نوٹ: واحد فائلوں پر لاگو ہوتا ہے! فائلیں اجتماعی غور نہیں کر رہے ہیں.
- لاگ گرد گردش کسی بھی وقت کسی بھی وقت موجود ہونا لاگ ان کی تعداد محدود کرتا ہے. جب نیا لاگ ان کی تخلیق کی جاتی ہے تو، اگر لاگ ان کی کل تعداد مخصوص حد سے زیادہ ہوتی ہے تو مخصوص کارروائی کی جائے گی. آپ یہاں مطلوبہ حد کی وضاحت کرسکتے ہیں. 0 کی قیمت لاگ گرد گردش کو غیر فعال کرے گی.
- لاگ گرد گردش کسی بھی وقت کسی بھی وقت موجود ہونا لاگ ان کی تعداد محدود کرتا ہے. جب نیا لاگ ان کی تخلیق کی جاتی ہے تو، اگر لاگ ان کی کل تعداد مخصوص حد سے زیادہ ہوتی ہے تو مخصوص کارروائی کی جائے گی. آپ یہاں مطلوبہ کارروائی کی وضاحت کرسکتے ہیں.
log_rotation_action
├─Delete ("قدیم ترین لاگ ان کو حذف کریں، جب تک کہ حد تک زیادہ نہیں ہوسکتی ہے.")
└─Archive ("سب سے پہلے آرکائیو، اور پھر سب سے پرانی لاگ ان کو حذف کریں، جب تک کہ حد زیادہ نہیں ہوسکتی.")- لاگ مسلیں میں کالعدم IP ایس سے مسدود درخواستوں شامل کریں? True (سچے) = جی ہاں [پہلے سے طے شدہ]؛ False (جھوٹی) = نہیں.
- لاگز ڈیٹا دیکھنے کے لئے سامنے کے آخر لاگز صفحے کے کا استعمال کرتے وقت کب، XSS حملوں سے صارفین کی حفاظت کے لئے، یہ نمائش سے پہلے نظر ثانی شدہ ہے. لیکن، ہم ایسا نہیں کرتے جب سب سے پہلے اسے ریکارڈ کرنا پڑتا ہے. اگر یہ مستقبل میں اس کا تجزیہ کرنے کی ضرورت ہے تو اس سے مدد مل سکتی ہے. لیکن خارجہ قارئین کا استعمال کرتے وقت یہ کبھی کبھی غیر محفوظ ہوسکتا ہے. اگر ضرورت ہو تو آپ رویے کو تبدیل کرسکتے ہیں. True (سچے) = کم درست، لیکن کم خطرہ. False (جھوٹی) = زیادہ درست، لیکن زیادہ خطرہ [پہلے سے طے شدہ].
فرنٹ اینڈ کے لیے کنفیگریشن.
- سامنے کے آخر میں لاگ ان کوششوں لاگنگ کے لئے دائر. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.
مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز general➡time_format پر دکھائے جاتے ہیں.
- جب دستخطوں کو اپ ڈیٹ پیج کے ذریعہ اپ ڈیٹ کیا جاتا ہے تو ریکارڈ کرنے کے لئے ایک فائل. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.
مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز general➡time_format پر دکھائے جاتے ہیں.
- لاگ ان کوششوں کی زیادہ سے زیادہ تعداد (سامنے کے آخر میں). پہلے سے طے شدہ = 5.
- فرنٹ اینڈ کے لیے استعمال کرنے کے لیے ڈیفالٹ تھیم.
theme
├─default ("Default")
├─bluemetal ("Blue Metal")
├─fullmoon ("Full Moon")
├─moss ("Moss")
├─primer ("Primer")
├─primerdark ("Primer Dark")
├─rbi ("Red-Blue Inverted")
├─slate ("Slate")
└─…دیگر- فونٹ اضافہ. پہلے سے طے شدہ = 1.
- تمام فرنٹ اینڈ پیجز کے شروع میں HTML کے بطور داخل کیا گیا. اگر آپ ویب سائٹ کا لوگو، پرسنلائزڈ ہیڈر، اسکرپٹس، وغیرہ شامل کرنا چاہتے ہیں، تو یہ مفید ہو سکتا ہے.
- تمام فرنٹ اینڈ پیجز کے آخر میں HTML کے بطور داخل کیا گیا. اگر آپ قانونی نوٹس، رابطہ لنک، کاروباری معلومات، وغیرہ شامل کرنا چاہتے ہیں، تو یہ مفید ہو سکتا ہے.
- اجزاء کے میٹا ڈیٹا کو حاصل کرنے کے لیے اپڈیٹر کے ذریعے استعمال کیے گئے پتوں کی فہرست. نئے بڑے ورژن میں اپ گریڈ کرتے وقت، یا اپ ڈیٹس کے لیے نیا ذریعہ حاصل کرتے وقت اسے ایڈجسٹ کرنے کی ضرورت پڑ سکتی ہے، لیکن عام حالات میں اسے تنہا چھوڑ دیا جانا چاہیے.
- یہ تعین کرتا ہے کہ 2FA استعمال کیا جانا چاہئے.
دستخطوں، دستخط فائلوں، ماڈیولز، وغیرہ کے لئے تشکیل.
- یہ کنٹرول کرتا ہے کہ جب کسی دستخط کے خلاف مثبت مماثلت ہو جس میں دیے گئے شارٹ ہینڈ الفاظ کا استعمال ہوتا ہے تو درخواست کے ساتھ کیا کرنا ہے.
shorthand
├─Attacks ("حملے")
├─Bogon ("⁰ Bogon IP")
├─Cloud ("کلاؤڈ سروس")
├─Generic ("جنرک")
├─Legal ("¹ قانونی")
├─Malware ("میلویئر")
├─Proxy ("² پراکسی")
├─Spam ("سپیم")
├─Banned ("³ کالعدم")
├─BadIP ("³ غلط IP")
├─RL ("³ ریٹ محدود")
├─Conflict ("³ تنازعہ")
└─Other ("⁴ دیگر")0. اگر آپ کی ویب سائٹ کو LAN یا localhost کے ذریعے رسائی کی ضرورت ہے، اسے مسدود نہ کریں. اگر ضرورت نہ ہو تو آپ اسے بلاک کر سکتے ہیں.
1. معیاری دستخطی فائلیں اسے استعمال نہیں کرتی ہیں، لیکن یہ اس صورت میں تعاون یافتہ ہے کہ یہ کچھ صارفین کے لیے کارآمد ہو سکتا ہے.
2. اگر آپ کے صارفین کو پراکسی کے ذریعے آپ کی ویب سائٹ تک رسائی حاصل کرنے کی ضرورت ہے، اسے مسدود نہ کریں. اگر ضرورت نہ ہو تو آپ اسے بلاک کر سکتے ہیں.
3. دستخطوں کے اندر براہ راست استعمال کی حمایت نہیں کی جاتی ہے، لیکن خاص حالات میں اسے دوسرے ذرائع سے استعمال کیا جا سکتا ہے.
4. ایسے معاملات کا حوالہ دیتے ہیں جہاں شارٹ ہینڈ الفاظ بالکل استعمال نہیں ہوتے ہیں، یا CIDRAM کے ذریعہ پہچانے نہیں جاتے ہیں.
ایک فی دستخط. ایک دستخط متعدد پروفائلز کی درخواست کر سکتا ہے، لیکن صرف ایک مختصر لفظ استعمال کر سکتا ہے. یہ ممکن ہے کہ ایک سے زیادہ شارٹ ہینڈ الفاظ موزوں ہوں، لیکن چونکہ صرف ایک ہی استعمال کیا جا سکتا ہے، ہم کوشش کرتے ہیں کہ ہمیشہ صرف سب سے موزوں الفاظ استعمال کریں.
ترجیح. ایک منتخب کردہ آپشن ہمیشہ غیر منتخب کردہ آپشن پر ترجیح لیتا ہے. مثال کے طور پر، اگر ایک سے زیادہ شارٹ ہینڈ الفاظ چل رہے ہیں لیکن ان میں سے صرف ایک کو بلاک کیے جانے کے طور پر سیٹ کیا گیا ہے، تب بھی درخواست کو بلاک کر دیا جائے گا.
ہیومن اینڈ پوائنٹس اور کلاؤڈ سروسز. "کلاؤڈ سروس" ویب ہوسٹنگ فراہم کنندگان، سرور فارمز، ڈیٹا سینٹرز، یا بہت سی دوسری چیزوں کا حوالہ دے سکتی ہے. "ہیومن اینڈ پوائنٹ" سے مراد وہ ذرائع ہیں جن کے ذریعے انسان انٹرنیٹ تک رسائی حاصل کرتا ہے، جیسے کہ انٹرنیٹ سروس فراہم کرنے والے کے ذریعے. نیٹ ورک عام طور پر صرف ایک یا دوسرا فراہم کرتا ہے، لیکن بعض اوقات دونوں فراہم کر سکتا ہے. ہم کوشش کرتے ہیں کہ کبھی بھی ممکنہ انسانی اینڈ پوائنٹ کو کلاؤڈ سروسز کے طور پر شناخت نہ کریں. لہذا، ایک کلاؤڈ سروس کی شناخت کسی اور چیز کے طور پر کی جا سکتی ہے اگر اس کی حد معلوم انسانی اختتامی نقطوں کے ذریعے مشترکہ ہو. اسی طرح، جب کسی بھی معلوم انسانی اینڈ پوائنٹس کے ذریعے رینجز کا اشتراک نہیں کیا جاتا ہے، تو ہم ہمیشہ کلاؤڈ سروسز کے بطور کلاؤڈ سروسز کی شناخت کرنے کی کوشش کرتے ہیں. لہذا، کلاؤڈ سروس کے طور پر شناخت کی گئی درخواست شاید معلوم انسانی اختتامی مقامات کے ساتھ حدود کا اشتراک نہیں کرتی ہے. حملوں یا سپیم کے خطرے سے شناخت شدہ درخواستوں کا معاملہ اس کے برعکس ہے. تاہم، انٹرنیٹ ہمیشہ بہاؤ میں رہتا ہے، نیٹ ورکس کے مقاصد وقت کے ساتھ بدلتے رہتے ہیں، اور رینجز ہمیشہ خریدی یا فروخت ہوتی رہتی ہیں، لہذا غلط مثبتات کے حوالے سے چوکس رہیں.
- وہ دورانیہ جس کے لیے IP پتوں کو ٹریک کیا جانا چاہیے. پہلے سے طے شدہ = 7d0°0′0″ (1 ہفتہ).
- خلاف ورزی کی زیادہ سے زیادہ تعداد ایک IP اس سے پہلے کیا جاتا ہے IP باخبر رہنے کے کی طرف سے پابندی کا اطلاق کرنے کی اجازت ہے. پہلے سے طے شدہ = 10.
- ماڈیولوں کو ٹریکنگ کے اختیارات کو اوور رائڈ کرنے کی اجازت دیں؟ True (سچے) = جی ہاں [پہلے سے طے شدہ]؛ False (جھوٹی) = نہیں.
- جب ایک ہی وسائل تک رسائی کے لیے بیک وقت بہت ساری کوششیں ہوتی ہیں (مثال کے طور پر، ایک ہی مشین پر ایک ہی وسائل کے لیے متعدد پی ایچ پی پروسیسز کے لیے بیک وقت درخواستیں)، ان میں سے کچھ کوششیں ناکام ہو سکتی ہیں. نایاب اور غیر امکانی صورت میں کہ یہ دستخطی فائلوں یا ماڈیولز کو متاثر کرتا ہے، CIDRAM کو درخواست کے بارے میں موثر فیصلہ کرنے سے روکا جا سکتا ہے. اگر ایسا ہوتا ہے، کیا درخواست کو بلاک کر دینا چاہیے، اور CIDRAM کو کون سا HTTP اسٹیٹس پیغام بھیجنا چاہیے؟
conflict_response
├─0 (درخواست کو مسدود نہ کریں.): اگر آپ ترجیح دیتے ہیں کہ درخواستوں کو صرف
│ اس صورت میں مسدود کیا جائے جب آپ کو یقین ہو
│ کہ وہ خراب ہیں، یا غلط مثبتات کے سلسلے میں
│ محتاط رہنے کے لیے (کبھی کبھار غیر مطلوبہ
│ ٹریفک کے گزرنے کے خطرے میں)، یہ منتخب کریں.
│ اگر آپ ترجیح دیتے ہیں کہ درخواستوں کو
│ مسدود کر دیا جائے اگر آپ کو یقین نہیں ہے کہ
│ وہ بے نظیر ہیں، یا چوکس رہنے کے لیے (کبھی
│ کبھار جھوٹے مثبت ہونے کے خطرے میں)، دوسرے
│ دستیاب اختیارات میں سے ایک کا انتخاب کریں.
├─409 (409 Conflict (تنازعہ)): وسائل کے تنازعات کے لیے تجویز کردہ (مثلاً،
│ ضم تنازعات، فائل تک رسائی کے تنازعات،
│ وغیرہ). دوسرے سیاق و سباق میں سفارش نہیں کی
│ جاتی ہے.
└─429 (429 Too Many Requests (بہت ساری درخواستیں)): شرح کو محدود کرنے، DDoS حملوں سے نمٹنے، اور
سیلاب سے بچاؤ کے لیے تجویز کردہ. دوسرے
سیاق و سباق میں سفارش نہیں کی جاتی ہے.اس بات کی تصدیق کے لیے کنفیگریشن کہ درخواستیں کہاں سے آتی ہیں.
- سرچ انجنوں سے درخواستوں کی تصدیق کے لیے کنٹرولز.
search_engines
├─Amazonbot ("Amazonbot")
├─Applebot ("Applebot")
├─Baidu ("* Baiduspider/百度")
├─Bingbot ("* Bingbot")
├─DuckDuckBot ("* DuckDuckBot")
├─Googlebot ("* Googlebot")
├─MojeekBot ("MojeekBot")
├─Neevabot ("* Neevabot")
├─PetalBot ("* PetalBot")
├─Qwantify ("Qwantify/Bleriot")
├─SeznamBot ("SeznamBot")
├─Sogou ("* Sogou/搜狗")
├─Yahoo ("Yahoo/Slurp")
├─Yandex ("* Yandex/Яндекс")
└─YoudaoBot ("YoudaoBot")"مثبت" اور "منفی" کیا ہیں؟ درخواست کے ذریعے پیش کردہ شناخت کی تصدیق کرتے وقت، ایک کامیاب نتیجہ کو "مثبت" یا "منفی" کے طور پر بیان کیا جا سکتا ہے. جب پیش کی گئی شناخت کے حقیقی شناخت ہونے کی تصدیق ہو جاتی ہے، تو اسے "مثبت" کے طور پر بیان کیا جائے گا. جب پیش کردہ شناخت کے جھوٹے ہونے کی تصدیق ہو جاتی ہے، تو اسے "منفی" کے طور پر بیان کیا جائے گا. تاہم، ایک ناکام نتیجہ (مثال کے طور پر، تصدیق ناکام ہو جاتی ہے، یا پیش کردہ شناخت کی سچائی کا تعین نہیں کیا جا سکتا) کو "مثبت" یا "منفی" کے طور پر بیان نہیں کیا جائے گا. اس کے بجائے، ایک ناکام نتیجہ کو محض غیر تصدیق شدہ کے طور پر بیان کیا جائے گا. جب درخواست کے ذریعہ پیش کردہ شناخت کی تصدیق کرنے کی کوئی کوشش نہیں کی جاتی ہے، تو درخواست کو بھی غیر تصدیق شدہ کے طور پر بیان کیا جائے گا. شرائط صرف اس تناظر میں معنی رکھتی ہیں جہاں درخواست کے ذریعہ پیش کردہ شناخت کو تسلیم کیا جاتا ہے، اور اس وجہ سے، جہاں تصدیق ممکن ہے. اگر پیش کردہ شناخت اوپر فراہم کردہ اختیارات سے مماثل نہیں ہے، یا اگر کوئی شناخت پیش نہیں کی گئی ہے، تو اوپر فراہم کردہ اختیارات غیر متعلقہ ہو جاتے ہیں.
"سنگل ہٹ بائی پاس" کیا ہیں؟ کچھ معاملات میں، ایک مثبت تصدیق شدہ درخواست اب بھی دستخط فائلوں، ماڈیولز، یا دیگر عوامل کے نتیجے میں مسدود ہو سکتی ہے، اور غلط مثبت سے بچنے کے لیے بائی پاس ضروری ہو سکتے ہیں. جب ایک بائی پاس کا مقصد بالکل ایک خلاف ورزی سے نمٹنا ہوتا ہے، تو ایسے بائی پاس کو "سنگل ہٹ بائی پاس" کے طور پر بیان کیا جا سکتا ہے.
- اس اختیار میں
used⬅bypassesکے تحت اسی طرح کا بائی پاس ہ. چاہے اس اختیار کی تصدیق کرنے کی کوشش کے لیے چیک باکس منتخب کیا گیا ہو، کی سفارش کی جاتی ہے اس بات کو یقینی بنانے کہ متعلقہ بائی پاس کا چیک باکس ایک جیسا ہو.
- سوشل میڈیا پلیٹ فارمز سے درخواستوں کی تصدیق کے لیے کنٹرولز.
social_media
├─Embedly ("* Embedly")
├─Facebook ("** Facebook")
├─Pinterest ("* Pinterest")
├─Snapchat ("* Snapchat")
└─Twitterbot ("*!! Twitterbot")"مثبت" اور "منفی" کیا ہیں؟ درخواست کے ذریعے پیش کردہ شناخت کی تصدیق کرتے وقت، ایک کامیاب نتیجہ کو "مثبت" یا "منفی" کے طور پر بیان کیا جا سکتا ہے. جب پیش کی گئی شناخت کے حقیقی شناخت ہونے کی تصدیق ہو جاتی ہے، تو اسے "مثبت" کے طور پر بیان کیا جائے گا. جب پیش کردہ شناخت کے جھوٹے ہونے کی تصدیق ہو جاتی ہے، تو اسے "منفی" کے طور پر بیان کیا جائے گا. تاہم، ایک ناکام نتیجہ (مثال کے طور پر، تصدیق ناکام ہو جاتی ہے، یا پیش کردہ شناخت کی سچائی کا تعین نہیں کیا جا سکتا) کو "مثبت" یا "منفی" کے طور پر بیان نہیں کیا جائے گا. اس کے بجائے، ایک ناکام نتیجہ کو محض غیر تصدیق شدہ کے طور پر بیان کیا جائے گا. جب درخواست کے ذریعہ پیش کردہ شناخت کی تصدیق کرنے کی کوئی کوشش نہیں کی جاتی ہے، تو درخواست کو بھی غیر تصدیق شدہ کے طور پر بیان کیا جائے گا. شرائط صرف اس تناظر میں معنی رکھتی ہیں جہاں درخواست کے ذریعہ پیش کردہ شناخت کو تسلیم کیا جاتا ہے، اور اس وجہ سے، جہاں تصدیق ممکن ہے. اگر پیش کردہ شناخت اوپر فراہم کردہ اختیارات سے مماثل نہیں ہے، یا اگر کوئی شناخت پیش نہیں کی گئی ہے، تو اوپر فراہم کردہ اختیارات غیر متعلقہ ہو جاتے ہیں.
"سنگل ہٹ بائی پاس" کیا ہیں؟ کچھ معاملات میں، ایک مثبت تصدیق شدہ درخواست اب بھی دستخط فائلوں، ماڈیولز، یا دیگر عوامل کے نتیجے میں مسدود ہو سکتی ہے، اور غلط مثبت سے بچنے کے لیے بائی پاس ضروری ہو سکتے ہیں. جب ایک بائی پاس کا مقصد بالکل ایک خلاف ورزی سے نمٹنا ہوتا ہے، تو ایسے بائی پاس کو "سنگل ہٹ بائی پاس" کے طور پر بیان کیا جا سکتا ہے.
- اس اختیار میں
used⬅bypassesکے تحت اسی طرح کا بائی پاس ہ. چاہے اس اختیار کی تصدیق کرنے کی کوشش کے لیے چیک باکس منتخب کیا گیا ہو، کی سفارش کی جاتی ہے اس بات کو یقینی بنانے کہ متعلقہ بائی پاس کا چیک باکس ایک جیسا ہو.
** ASN تلاش کی فعالیت کی ضرورت ہے (مثال کے طور پر، IP-API یا BGPView ماڈیول کے ذریعے).
*!! iMessage کی وجہ سے جھوٹے مثبت ہونے کا زیادہ امکان.
- جہاں ممکن ہو دوسری قسم کی درخواستوں کی تصدیق کے لیے کنٹرولز.
other
├─AdSense ("AdSense")
├─AmazonAdBot ("* AmazonAdBot")
├─ChatGPT-User ("!! ChatGPT-User")
├─GPTBot ("!! GPTBot")
└─Grapeshot ("* Oracle Data Cloud Crawler (Grapeshot)")"مثبت" اور "منفی" کیا ہیں؟ درخواست کے ذریعے پیش کردہ شناخت کی تصدیق کرتے وقت، ایک کامیاب نتیجہ کو "مثبت" یا "منفی" کے طور پر بیان کیا جا سکتا ہے. جب پیش کی گئی شناخت کے حقیقی شناخت ہونے کی تصدیق ہو جاتی ہے، تو اسے "مثبت" کے طور پر بیان کیا جائے گا. جب پیش کردہ شناخت کے جھوٹے ہونے کی تصدیق ہو جاتی ہے، تو اسے "منفی" کے طور پر بیان کیا جائے گا. تاہم، ایک ناکام نتیجہ (مثال کے طور پر، تصدیق ناکام ہو جاتی ہے، یا پیش کردہ شناخت کی سچائی کا تعین نہیں کیا جا سکتا) کو "مثبت" یا "منفی" کے طور پر بیان نہیں کیا جائے گا. اس کے بجائے، ایک ناکام نتیجہ کو محض غیر تصدیق شدہ کے طور پر بیان کیا جائے گا. جب درخواست کے ذریعہ پیش کردہ شناخت کی تصدیق کرنے کی کوئی کوشش نہیں کی جاتی ہے، تو درخواست کو بھی غیر تصدیق شدہ کے طور پر بیان کیا جائے گا. شرائط صرف اس تناظر میں معنی رکھتی ہیں جہاں درخواست کے ذریعہ پیش کردہ شناخت کو تسلیم کیا جاتا ہے، اور اس وجہ سے، جہاں تصدیق ممکن ہے. اگر پیش کردہ شناخت اوپر فراہم کردہ اختیارات سے مماثل نہیں ہے، یا اگر کوئی شناخت پیش نہیں کی گئی ہے، تو اوپر فراہم کردہ اختیارات غیر متعلقہ ہو جاتے ہیں.
"سنگل ہٹ بائی پاس" کیا ہیں؟ کچھ معاملات میں، ایک مثبت تصدیق شدہ درخواست اب بھی دستخط فائلوں، ماڈیولز، یا دیگر عوامل کے نتیجے میں مسدود ہو سکتی ہے، اور غلط مثبت سے بچنے کے لیے بائی پاس ضروری ہو سکتے ہیں. جب ایک بائی پاس کا مقصد بالکل ایک خلاف ورزی سے نمٹنا ہوتا ہے، تو ایسے بائی پاس کو "سنگل ہٹ بائی پاس" کے طور پر بیان کیا جا سکتا ہے.
- اس اختیار میں
used⬅bypassesکے تحت اسی طرح کا بائی پاس ہ. چاہے اس اختیار کی تصدیق کرنے کی کوشش کے لیے چیک باکس منتخب کیا گیا ہو، کی سفارش کی جاتی ہے اس بات کو یقینی بنانے کہ متعلقہ بائی پاس کا چیک باکس ایک جیسا ہو.
!! اصلی یا جعلی، کسی بھی طرح سے، زیادہ تر صارفین اس کو بلاک کرنا چاہیں گے. یہ "تصدیق کرنے کی کوشش کریں" کو منتخب نہ کرنے اور "غیر تصدیق شدہ درخواستوں کو مسدود کریں" کو منتخب کرکے حاصل کیا جاسکتا ہے. تاہم، کچھ صارفین ایسی درخواستوں کی تصدیق کرنے کے قابل ہو سکتے ہیں (مثبت کو اجازت دیتے ہوئے منفی کو روکنے کے لیے)، اس لیے ماڈیولز کے ذریعے ایسی درخواستوں کو بلاک کرنے کے بجائے، ایسی درخواستوں کو سنبھالنے کے اختیارات یہاں فراہم کیے گئے ہیں.
- تصدیق کے تناظر میں دیگر خصوصیات کو ایڈجسٹ کرنے کے کنٹرولز.
adjust
├─Negatives ("بلاک شدہ منفی")
└─NonVerified ("بلاک شدہ غیر تصدیق شدہ")ReCaptcha کی ترتیبات (بلاک ہونے پر انسانوں کو دوبارہ رسائی حاصل کرنے کا ایک راستہ فراہم کرتا ہے).
- CAPTCHA کب پیش کیا جائے؟ نوٹ: وائٹ لسٹڈ یا توثیق شدہ اور غیر مسدود درخواستوں کو کبھی بھی CAPTCHA کو مکمل کرنے کی ضرورت نہیں ہے. یہ بھی نوٹ کریں: CAPTCHA بوٹس اور مختلف قسم کی بدنیتی پر مبنی خودکار درخواستوں کے خلاف مفید تحفظ فراہم کر سکتے ہیں، لیکن بدنیتی پر مبنی انسان کے خلاف کوئی تحفظ فراہم نہیں کریں گے.
usemode
├─0 (کبھی نہیں !!!)
├─1 (صرف اس صورت میں جب بلاک ہوجائے، دستخطوں کی حد میں ہو، اور پابندی عائد نہ ہو.)
├─2 (صرف اس صورت میں جب بلاک ہو، استعمال کے لئے خصوصی طور پر نشان زد، دستخطوں کی حد میں ہو، اور پابندی نہیں ہو.)
├─3 (صرف اس وقت جب دستخطوں کی حد میں ہو، اور پابندی عائد نہ ہو (کوئی بات نہیں بلاک ہو یا نہیں).)
├─4 (صرف اس وقت جب بلاک نہیں کیا جاتا ہے.)
├─5 (صرف اس وقت جب بلاک نہ ہوا ہو، یا جب استعمال کے لئے خاص طور پر نشان زد کیا گیا ہو، دستخطوں کی حد میں ہو، اور پابندی نہ ہو.)
└─6 (صرف اس وقت جب بلاک نہ ہوا ہو، حساس صفحہ کی درخواستوں پر.)- ئی پی ایس کے لئے ہیتی لاک؟
- صارفین کے لئے ہیتی لاک؟
- یہ قدر آپ کے CAPTCHA خدمت کے لئے ڈیش بورڈ میں مل سکتی ہے.
بھی دیکھو:
- یہ قدر آپ کے CAPTCHA خدمت کے لئے ڈیش بورڈ میں مل سکتی ہے.
بھی دیکھو:
- گھنٹوں کی تعداد CAPTCHA کے واقعات کو یاد کرنے. پہلے سے طے شدہ = 720 (1 ماہ).
- تمام CAPTCHA کے کوششوں لاگ؟ اگر ہاں، تو لاگ فائل کے لیے استعمال کرنے کے لیے نام کی وضاحت کریں. اگر نہیں، تو اس متغیر کو خالی چھوڑ دیں.
مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز general➡time_format پر دکھائے جاتے ہیں.
- CAPTCHA پیش کش واپس لینے سے پہلے دستخطوں کی زیادہ سے زیادہ تعداد کی اجازت. پہلے سے طے شدہ = 1.
- کون سا API استعمال کرنے کے لئے؟
api
├─V2 ("V2 (چیک باکس)")
└─Invisible ("V2 (پوشیدہ)")- کوکی انتباہ دکھائیں؟ True (سچے) = جی ہاں [پہلے سے طے شدہ]؛ False (جھوٹی) = نہیں.
- API کا پیغام دکھائیں؟ True (سچے) = جی ہاں [پہلے سے طے شدہ]؛ False (جھوٹی) = نہیں.
- غیر مسدود درخواستوں پر CAPTCHA کی نمائش کرتے وقت کون سا اسٹیٹس کوڈ استعمال کرنا چاہئے؟
nonblocked_status_code
├─200 (200 OK (ٹھیک ہے)): کم سے کم مضبوط، لیکن سب سے زیادہ صارف دوست.
│ خودکار درخواستیں غالباً اس جواب کی تشریح
│ کریں گی کہ درخواست کامیاب تھی.
├─403 (403 Forbidden (ممنوعہ)): زیادہ مضبوط، لیکن کم صارف دوست. زیادہ تر
│ عام حالات کے لیے تجویز کردہ.
├─418 (418 I'm a teapot (میں چائے کا برتن)): اپریل فول کے لطیفے کا حوالہ دیتے ہیں (<a
│ href="https://tools.ietf.org/html/rfc2324" dir="ltr" hreflang="en-US"
│ rel="noopener noreferrer external">RFC 2324</a>). کسی بھی
│ کلائنٹ، بوٹ، براؤزر، یا کسی اور طرح سے
│ سمجھنے کا امکان نہیں ہے. تفریح اور سہولت
│ کے لیے فراہم کی گئی ہے، لیکن عام طور پر
│ تجویز نہیں کی جاتی ہے.
├─429 (429 Too Many Requests (بہت ساری درخواستیں)): شرح کو محدود کرنے، DDoS حملوں سے نمٹنے، اور
│ سیلاب سے بچاؤ کے لیے تجویز کردہ. دوسرے
│ سیاق و سباق میں سفارش نہیں کی جاتی ہے.
└─451 (451 Unavailable For Legal Reasons (قانونی وجوہات کی بنا پر دستیاب نہیں ہے)): بنیادی طور پر قانونی وجوہات کی بنا پر
مسدود کرنے پر تجویز کیا جاتا ہے. دوسرے
سیاق و سباق میں سفارش نہیں کی جاتی ہے.HCaptcha کی ترتیبات (بلاک ہونے پر انسانوں کو دوبارہ رسائی حاصل کرنے کا ایک راستہ فراہم کرتا ہے).
- CAPTCHA کب پیش کیا جائے؟ نوٹ: وائٹ لسٹڈ یا توثیق شدہ اور غیر مسدود درخواستوں کو کبھی بھی CAPTCHA کو مکمل کرنے کی ضرورت نہیں ہے. یہ بھی نوٹ کریں: CAPTCHA بوٹس اور مختلف قسم کی بدنیتی پر مبنی خودکار درخواستوں کے خلاف مفید تحفظ فراہم کر سکتے ہیں، لیکن بدنیتی پر مبنی انسان کے خلاف کوئی تحفظ فراہم نہیں کریں گے.
usemode
├─0 (کبھی نہیں !!!)
├─1 (صرف اس صورت میں جب بلاک ہوجائے، دستخطوں کی حد میں ہو، اور پابندی عائد نہ ہو.)
├─2 (صرف اس صورت میں جب بلاک ہو، استعمال کے لئے خصوصی طور پر نشان زد، دستخطوں کی حد میں ہو، اور پابندی نہیں ہو.)
├─3 (صرف اس وقت جب دستخطوں کی حد میں ہو، اور پابندی عائد نہ ہو (کوئی بات نہیں بلاک ہو یا نہیں).)
├─4 (صرف اس وقت جب بلاک نہیں کیا جاتا ہے.)
├─5 (صرف اس وقت جب بلاک نہ ہوا ہو، یا جب استعمال کے لئے خاص طور پر نشان زد کیا گیا ہو، دستخطوں کی حد میں ہو، اور پابندی نہ ہو.)
└─6 (صرف اس وقت جب بلاک نہ ہوا ہو، حساس صفحہ کی درخواستوں پر.)- ئی پی ایس کے لئے ہیتی لاک؟
- صارفین کے لئے ہیتی لاک؟
- یہ قدر آپ کے CAPTCHA خدمت کے لئے ڈیش بورڈ میں مل سکتی ہے.
بھی دیکھو:
- یہ قدر آپ کے CAPTCHA خدمت کے لئے ڈیش بورڈ میں مل سکتی ہے.
بھی دیکھو:
- گھنٹوں کی تعداد CAPTCHA کے واقعات کو یاد کرنے. پہلے سے طے شدہ = 720 (1 ماہ).
- تمام CAPTCHA کے کوششوں لاگ؟ اگر ہاں، تو لاگ فائل کے لیے استعمال کرنے کے لیے نام کی وضاحت کریں. اگر نہیں، تو اس متغیر کو خالی چھوڑ دیں.
مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز general➡time_format پر دکھائے جاتے ہیں.
- CAPTCHA پیش کش واپس لینے سے پہلے دستخطوں کی زیادہ سے زیادہ تعداد کی اجازت. پہلے سے طے شدہ = 1.
- کون سا API استعمال کرنے کے لئے؟
api
├─V1 ("V1")
└─Invisible ("V1 (پوشیدہ)")- کوکی انتباہ دکھائیں؟ True (سچے) = جی ہاں [پہلے سے طے شدہ]؛ False (جھوٹی) = نہیں.
- API کا پیغام دکھائیں؟ True (سچے) = جی ہاں [پہلے سے طے شدہ]؛ False (جھوٹی) = نہیں.
- غیر مسدود درخواستوں پر CAPTCHA کی نمائش کرتے وقت کون سا اسٹیٹس کوڈ استعمال کرنا چاہئے؟
nonblocked_status_code
├─200 (200 OK (ٹھیک ہے)): کم سے کم مضبوط، لیکن سب سے زیادہ صارف دوست.
│ خودکار درخواستیں غالباً اس جواب کی تشریح
│ کریں گی کہ درخواست کامیاب تھی.
├─403 (403 Forbidden (ممنوعہ)): زیادہ مضبوط، لیکن کم صارف دوست. زیادہ تر
│ عام حالات کے لیے تجویز کردہ.
├─418 (418 I'm a teapot (میں چائے کا برتن)): اپریل فول کے لطیفے کا حوالہ دیتے ہیں (<a
│ href="https://tools.ietf.org/html/rfc2324" dir="ltr" hreflang="en-US"
│ rel="noopener noreferrer external">RFC 2324</a>). کسی بھی
│ کلائنٹ، بوٹ، براؤزر، یا کسی اور طرح سے
│ سمجھنے کا امکان نہیں ہے. تفریح اور سہولت
│ کے لیے فراہم کی گئی ہے، لیکن عام طور پر
│ تجویز نہیں کی جاتی ہے.
├─429 (429 Too Many Requests (بہت ساری درخواستیں)): شرح کو محدود کرنے، DDoS حملوں سے نمٹنے، اور
│ سیلاب سے بچاؤ کے لیے تجویز کردہ. دوسرے
│ سیاق و سباق میں سفارش نہیں کی جاتی ہے.
└─451 (451 Unavailable For Legal Reasons (قانونی وجوہات کی بنا پر دستیاب نہیں ہے)): بنیادی طور پر قانونی وجوہات کی بنا پر
مسدود کرنے پر تجویز کیا جاتا ہے. دوسرے
سیاق و سباق میں سفارش نہیں کی جاتی ہے.قانونی تقاضوں کے لئے ترتیبات.
- لاگ ان کرتے وقت پی ایس ڈی نامناسب IP پتے؟ True (سچے) = جی ہاں [پہلے سے طے شدہ]؛ False (جھوٹی) = نہیں.
- کسی بھی پیدا کردہ صفحات کے فوٹر میں ظاہر ہونے والی متعلقہ رازداری کی پالیسی کا پتہ. ایک URL کی وضاحت کریں، یا غیر فعال کرنے کیلئے خالی چھوڑ دیں.
ٹیمپلیٹس اور تھیمز کی ترتیبات.
- CIDRAM لئے استعمال کرنے کے لئے مرکزی خیال، موضوع پہلے سے طے شدہ.
theme
├─default ("Default")
├─bluemetal ("Blue Metal")
├─fullmoon ("Full Moon")
├─moss ("Moss")
├─primer ("Primer")
├─primerdark ("Primer Dark")
├─rbi ("Red-Blue Inverted")
├─slate ("Slate")
└─…دیگر- فونٹ اضافہ. پہلے سے طے شدہ = 1.
- اپنی مرضی کے موضوعات کے لئے سی ایس ایس فائل URL.
- بلاک ایونٹس کے لیے ظاہر کرنے کے لیے صفحہ کا عنوان.
block_event_title
├─CIDRAM ("CIDRAM")
├─denied ("رسائی مسترد کر دی!")
└─…دیگر- CAPTCHA کی درخواستوں کے لیے ظاہر کرنے کے لیے صفحہ کا عنوان.
captcha_title
├─CIDRAM ("CIDRAM")
└─…دیگر- تمام "رسائی مسترد کر دی" صفحات کے شروع میں بطور HTML داخل کیا گیا. اگر آپ ویب سائٹ کا لوگو، پرسنلائزڈ ہیڈر، اسکرپٹس، وغیرہ شامل کرنا چاہتے ہیں، تو یہ مفید ہو سکتا ہے.
- تمام "رسائی مسترد کر دی" صفحات کے آخر میں بطور HTML داخل کیا گیا. اگر آپ قانونی نوٹس، رابطہ لنک، کاروباری معلومات، وغیرہ شامل کرنا چاہتے ہیں، تو یہ مفید ہو سکتا ہے.
شرح کو محدود کرنے کی ترتیبات (عام استعمال کے لئے سفارش نہیں کی جاتی ہے).
- بینڈوڈتھ کی زیادہ سے زیادہ رقم کی اجازت کے عرصے میں اجازت دی گئی ہے. جب سے تجاوز کی گئی، مستقبل کی درخواستوں کی ریٹ محدود ہے. جب 0، اس قسم کی محدود استعمال نہیں کی جائے گی. پہلے سے طے شدہ = 0KB.
- الاؤنس کی مدت کے اندر اندر زیادہ سے زیادہ درخواستوں کی اجازت دی گئی ہے. جب سے تجاوز کی گئی، مستقبل کی درخواستوں کی ریٹ محدود ہے. جب 0، اس قسم کی محدود استعمال نہیں کی جائے گی. پہلے سے طے شدہ = 0.
- IPv4 استعمال کی نگرانی کرتے وقت استعمال کرنے کی صحت سے متعلق. قیمت CIDR بلاک سائز کی عکاسی کرتا ہے. بہترین صحت سے متعلق کے لئے 32 پر مقرر کریں. پہلے سے طے شدہ = 32.
- IPv6 استعمال کی نگرانی کرتے وقت استعمال کرنے کی صحت سے متعلق. قیمت CIDR بلاک سائز کی عکاسی کرتا ہے. بہترین صحت سے متعلق کے لئے 128 پر مقرر کریں. پہلے سے طے شدہ = 128.
- استعمال کو ٹریک کرنے کا دورانیہ. پہلے سے طے شدہ = 0°0′0″.
- مستثنیات (یعنی، درخواستوں کو جس کی ریٹ محدود نہیں ہونی چاہئے). متعلقہ صرف اس وقت جب شرح کی حد بندی قابل ہو.
exceptions
├─Whitelisted ("وائٹ لسٹ کی درخواستیں")
├─Verified ("سرچ انجنوں اور سوشل میڈیا سے تصدیق شدہ درخواستیں")
└─FE ("CIDRAM فرنٹ اینڈ سے درخواستیں")- کیا مختلف ڈومینز اور میزبانوں کے کوٹوں کو الگ یا شیئر کیا جانا چاہیے؟ True = کوٹے الگ کیے جائیں گے. False = کوٹے شیئر کیے جائیں گے [پہلے سے طے شدہ].
ضمنی کیشے کے اختیارات. نوٹ: ان اقدار کو تبدیل کرنے سے آپ ممکنہ طور پر لاگ آؤٹ ہو سکتے ہیں.
- یہاں بیان کردہ قدر کو تمام کیش انٹری کیز کے ساتھ پہلے سے جوڑا جائے گا. پہلے سے طے شدہ = "CIDRAM_". جب ایک ہی سرور پر متعدد تنصیبات موجود ہوں، تو یہ ان کے کیچز کو ایک دوسرے سے الگ رکھنے کے لیے مفید ہو سکتا ہے.
- اس کی وضاحت کرتا ہے کہ کیش کے لئے APCu استعمال کرنا چاہے. پہلے سے طے شدہ = True (سچ).
- اس کی وضاحت کرتا ہے کہ کیش کے لئے Memcached استعمال کرنا چاہے. پہلے سے طے شدہ = False (جھوٹی).
- اس کی وضاحت کرتا ہے کہ کیش کے لئے Redis استعمال کرنا چاہے. پہلے سے طے شدہ = False (جھوٹی).
- اس کی وضاحت کرتا ہے کہ کیش کے لئے PDO استعمال کرنا چاہے. پہلے سے طے شدہ = False (جھوٹی).
- Memcached کے میزبان نام. پہلے سے طے شدہ = "localhost".
- Memcached کے لئے بندرگاہ. پہلے سے طے شدہ = "11211".
- Redis کے میزبان نام. پہلے سے طے شدہ = "localhost".
- Redis کے لئے بندرگاہ. پہلے سے طے شدہ = "6379".
- Redis کے لئے ٹائم آؤٹ. پہلے سے طے شدہ = "2.5".
- Redis ڈیٹا بیس نمبر. پہلے سے طے شدہ = 0. نوٹ: Redis Cluster کے ساتھ 0 کے علاوہ دیگر اقدار استعمال نہیں کر سکتے.
- PDO کے لئے DSN. پہلے سے طے شدہ = "mysql:dbname=cidram;host=localhost;port=3306".
FAQ. "PDO DSN" کیا ہے؟ میں CIDRAM کے ساتھ PDO کیسے استعمال کرسکتا ہوں؟
- PDO کے لئے صارف نام.
- PDO کیلئے پاس ورڈ.
پہلے سے طے شدہ دستخط کو نظرانداز کرنے کیلئے تشکیل.
- کون سے بائی پاس کو استعمال کیا جانا چاہئے؟
used
├─AbuseIPDB ("AbuseIPDB")
├─AmazonAdBot ("AmazonAdBot")
├─Baidu ("Baiduspider/百度")
├─Bingbot ("Bingbot")
├─DuckDuckBot ("DuckDuckBot")
├─Embedly ("Embedly")
├─Feedbot ("Feedbot")
├─Feedspot ("Feedspot")
├─GoogleFiber ("Google Fiber")
├─Googlebot ("Googlebot")
├─Grapeshot ("Grapeshot")
├─Jetpack ("Jetpack")
├─Neevabot ("Neevabot")
├─PetalBot ("PetalBot")
├─Pinterest ("Pinterest")
├─Redditbot ("Redditbot")
├─Skype ("Skype URL Preview")
├─Snapchat ("Snapchat")
├─Sogou ("Sogou/搜狗")
└─Yandex ("Yandex/Яндекс")بھی دیکھو:
"xxx.xxx.xxx.xxx/yy [فنکشن] [پرم]": تمام IPv4 کی دستخط کی شکل کی پیروی.
- "xxx.xxx.xxx.xxx" CIDR بلاک (بلاک میں ابتدائی IP ایڈریس کی آکٹیٹ) کے آغاز کی نمائندگی کرتا ہے.
- "yy" CIDR بلاک سائز [۱-۳۲] نمائندگی کرتا ہے.
- "[فنکشن]" سکرپٹ سگنیچر (دستخط شمار کیا جانا چاہئے کہ کس طرح) کے ساتھ کیا کیا ہدایات.
- "[پرم]" کی نمائندگی کرتا ہے جو کچھ بھی اضافی معلومات "طرف (فنکشن) کی ضرورت ہوسکتی ہے".
"xxxx:xxxx:xxxx:xxxx::xxxx/yy" [فنکشن] [پرم]" تمام IPv6 کی دستخط کی شکل کی پیروی."xxxx:xxxx:xxxx:xxxx::xxxx"CIDR بلاک کے آغاز (بلاک میں ابتدائی IP ایڈریس کی آکٹیٹ) نمائندگی کرتا ہے. مکمل سنکیتن اور مختصر سنکیتن دونوں قابل قبول ہیں (اور ہر ایک IPv6 کی سنکیتن کے مناسب اور متعلقہ معیار پر عمل کرنا ضروری ہے، لیکن ایک رعایت کے ساتھ: ایک IPv6 کی ایڈریس مخفف کے ساتھ اس سکرپٹ کے لئے ایک دستخط میں استعمال کرتے ہیں، کی وجہ سے میں جس طرح کرنے کے لئے شروع نہیں کر سکتی"0::1/128"طور مثلا، ایک دستخط میں استعمال کیا جاتا ہے جب"::1/128"کا اظہار کیا جانا چاہئے، اور"0::/128"کے طور پر اظہار، جس CIDR سکرپٹ کی طرف سے دوبارہ تعمیر کر رہے ہیں"::0/128").- "yy" CIDR بلاک سائز [1-128] نمائندگی کرتا ہے.
- "(فنکشن)" سکرپٹ سگنیچر (دستخط شمار کیا جانا چاہئے کہ کس طرح) کے ساتھ کیا کیا ہدایات.
- "[پرم]" کی نمائندگی کرتا ہے جو کچھ بھی اضافی معلومات "طرف (فنکشن) کی ضرورت ہوسکتی ہے".
ہ دستخط کے CIDRAM یونیکس طرز نیولائنز (
"%0A"، یا "\n") کا استعمال کرنا چاہئے کے لئے فائلوں! دوسری قسم / نیولائنز کے سٹائل (جیسے ونڈوز "%0D%0A" یا "\r\n" نیولائنز، میک "%0D" یا"\r" نیولائنز، وغیرہ) استعمال کیا جا سکتا ہے، لیکن ترجیح نہیں ہیں. غیر یونیکس طرز نیولائنز سکرپٹ طرف یونیکس طرز نیولائنز کو معمول کی جائے گی.عین مطابق اور درست CIDR سنکیتن کی ضرورت ہے، دوسری صورت سکرپٹ دستخط کو تسلیم نہیں کریں گے. مزید برآں، اس سکرپٹ کی تمام CIDR دستخط ایک IP ایڈریس جن IP نمبر، اس کی CIDR بلاک سائز (مثلا طرف سے نمائندگی آپ
"11.127.255.255" کرنا "10.128.0.0" سے تمام IP ایس کو بلاک کرنا چاہتے تھے تو بلاک ڈویژن میں یکساں طور پر تقسیم کر سکتے ہیں کے ساتھ شروع ہونا چاہئے، "10.128.0.0/8" سکرپٹ کی طرف سے تسلیم نہیں کیا جائے گا، لیکن" 10.128.0.0/9" اور "11.0.0.0/9" مل کر میں استعمال کیا جاتا ہے، سکرپٹ کی طرف سے تسلیم کیا جائے گا).دستخط میں کوئی بھی چیز اس وجہ سے جس کا مطلب آپ کو محفوظ طریقے سے ان کو توڑنے کے بغیر اور اسکرپٹ کو توڑنے کے بغیر آپ کے دستخط فائلوں میں چاہتا ہوں کہ کسی بھی غیر دستخط کے اعداد و شمار کو ڈال کر سکتے ہیں، کو نظر انداز کر دیا جائے گا ایک دستخط کے طور پر اور نہ ہی سکرپٹ کی طرف سے دستخط کے متعلق نحو کے طور پر تسلیم نہیں فائلوں. تبصرے کے دستخط فائلوں میں قابل قبول ہیں، اور کوئی خاص فارمیٹنگ ان کے لئے کی ضرورت ہے. تبصرے کے لئے شیل طرز hashing کے ترجیح دی جاتی ہے، لیکن نافذ نہیں؛ مکمل طور پر قابل، یہ آپ کے تبصرے کے لئے شیل طرز hashing کے استعمال کرنے کا انتخاب کرتے ہیں یا نہیں اسکرپٹ کو کوئی فرق نہیں پڑتا، لیکن شیل طرز hashing کے استعمال کر IDEs کے اور سادہ ٹیکسٹ ایڈیٹرز صحیح دستخط کی فائلوں کے مختلف حصوں کو اجاگر کرنے میں مدد ملتی ہے (اور اس طرح، شیل طرز میں ترمیم کرتے ہوئے hashing کے ایک بصری امداد کے طور پر مدد کر سکتے ہیں).
"(فنکشن)" کی ممکنہ اقدار مندرجہ ذیل ہیں:
- Run
- Whitelist
- Greylist
- Deny
تو "Run" استعمال کیا جاتا ہے، دستخط شروع ہوجاتا ہے جب، سکرپٹ پھانسی کے لئے ایک بیرونی PHP اسکرپٹ، کی طرف سے مخصوص ہے (ایک "require_once" بیان کرتے ہوئے) کی کوشش کریں گے" [پرم] "قدر (کام کر ڈائرکٹری ہونا چاہئے "/vault/" اسکرپٹ کی ڈائریکٹری؛ ذیل کی مثالیں ملاحظہ کریں).
127.0.0.0/8 Run example.php
یہ کچھ IP ایڈریس اور CIDR کوڈ کے لئے ایک خاص PHP چلانے کے لئے مفید ہو سکتا ہے.
تو "Whitelist" استعمال کیا جاتا ہے، دستخط شروع ہوجاتا ہے جب اسکرپٹ تمام detections کر (کسی detections کر ہوئی ہے تو) دوبارہ ترتیب دے گا اور ٹیسٹ کی تقریب کو توڑنے. "[پرم]" نظر انداز کر دیا جاتا ہے. اس تقریب کا پتہ چلا جا رہا ہے سے ایک مخصوص IP یا CIDR وائٹ لسٹ کے برابر ہے.
127.0.0.1/32 Whitelist
تو "Greylist" استعمال کیا جاتا ہے، دستخط شروع ہوجاتا ہے جب اسکرپٹ تمام detections کر (کسی detections کر ہوئی ہے تو) دوبارہ ترتیب دے گا اور پروسیسنگ جاری رکھنے کے لئے اگلے کے دستخط کی فائل کو چھوڑ دیں. "[پرم]" نظر انداز کر دیا جاتا ہے.
127.0.0.1/32 Greylist
سگنیچر شروع ہوجاتا ہے جب "Deny" استعمال کیا جاتا ہے،، کوئی وائٹ لسٹ کے دستخط سنبھالنے دی IP ایڈریس اور / یا دی CIDR کے لئے متحرک کیا گیا ہے تو، محفوظ صفحے کی رسائی نہیں دی جائے گی. "Deny" کیا آپ واقعی ایک IP ایڈریس اور / یا CIDR رینج کو بلاک کرنے کے لئے استعمال کرنا چاہتے ہیں کریں گے کیا ہے. کوئی بھی دستخط متحرک کر رہے ہیں جب کے استعمال بنانے کے کہ "Deny"، "رسائی نہیں ہوئی" اسکرپٹ کا صفحہ پیدا کیا جائے گا اور ہلاک محفوظ صفحے کی درخواست.
"[پرم]" "Deny" کی طرف سے قبول کی قیمت، "رسائی نہیں ہوئی" کے صفحے کی پیداوار میں پارس کیا جائے گا کی تردید کی جا رہی مطلوبہ صفحہ تک ان کی رسائی کے لئے حوالہ دیا وجہ کے طور پر کلائنٹ / صارف کے لئے فراہم کی. یہ آپ کو ان کے (کچھ بھی، کافی چاہئے یہاں تک کہ ایک سادہ "میں آپ کو اپنی ویب سائٹ پر چاہتے ہیں نہیں ہے")، یا آشلپی الفاظ کی ایک چھوٹی سی مٹھی بھر کے ایک سے فراہم بلاک کرنے کے لئے منتخب کیا ہے یہی وجہ ہے کہ یا تو ایک مختصر اور سادہ قید کی سزا، کی وضاحت ہو سکتا ہے سکرپٹ کی طرف سے استعمال کیا ہے تو کہ میں کیوں کلائنٹ / صارف مسدود کر دیا گیا ہے ایک پہلے سے تیار وضاحت کے ساتھ سکرپٹ کی طرف سے تبدیل کیا جائے گا.
پہلے سے تیار وضاحتوں L10N حمایت حاصل ہے اور زبان آپ کو سکرپٹ کی ترتیب کے "lang" ہدایت کرنے کی وضاحت کی بنیاد پر سکرپٹ کی طرف سے فراہم کیا جا سکتا. کے علاوہ، آپ کو نظر انداز کی بنیاد پر دستخط "Deny" کرنا سکرپٹ کو ہدایت کر سکتے ہیں ان کے "[پرم]" قدر سکرپٹ کی ترتیب کی طرف سے مخصوص ہدایات کے ذریعے (وہ ان آشلپی الفاظ استعمال کر رہے ہیں) (ہر آشلپی لفظ ایک اسی ہدایت کی ہے یا تو کرنے کے لئے اسی دستخط عملدرآمد یا ان کو نظر انداز کرنے کی). "[پرم]" اقدار، ان آشلپی الفاظ استعمال کرتے ہیں کہ نہیں تاہم L10N حمایت کی ضرورت نہیں ہے اور اس وجہ سے سکرپٹ کی طرف سے فراہم نہیں کیا جائے گا، اور اس کے علاوہ، سکرپٹ کی ترتیب کی طرف سے براہ راست نینترنیی نہیں ہیں آپ آشلپی الفاظ یہ ہیں:
- Attacks
- Bogon
- Cloud
- Generic
- Legal
- Malware
- Proxy
- Spam
آپ کو انفرادی حصوں میں آپ اپنی مرضی کے دستخط کو تقسیم کرنا چاہتے ہیں تو، آپ کو آپ کے دستخط کے سیکشن کے نام کے ساتھ ساتھ فوری طور پر ہر سیکشن کے دستخط کے بعد ایک "سیکشن ٹیگ" انہوں نے مزید کہا کی طرف سے سکرپٹ کے لئے ان کے انفرادی حصوں کی شناخت کر سکتے ہیں (ذیل کی مثال ملاحظہ کریں).
# سیکشن 1.
1.2.3.4/32 Deny Bogon
2.3.4.5/32 Deny Cloud
4.5.6.7/32 Deny Generic
5.6.7.8/32 Deny Spam
6.7.8.9/32 Deny Proxy
Tag: سیکشن 1سیکشن ٹیگنگ توڑنے اور یقینی بنانے کے لئے ٹیگز غلط طریقے سے دستخط کی فائلوں میں پہلے سے دستخط کے حصوں کو شناخت نہیں کر رہے ہیں کہ، صرف آپ کے ٹیگ اور آپ کے شروع کے دستخط حصوں کے درمیان کم از کم دو مسلسل نیولائنز سے ہیں اس بات کا یقین. کوئی غیر ٹیگ شدہ دستخط "IPv4 کی" یا "IPv6 کی" (دستخط کی اقسام کو متحرک کیا جا رہا ہے جس پر منحصر ہے) خواہ کو فطری گا.
1.2.3.4/32 Deny Bogon
2.3.4.5/32 Deny Cloud
4.5.6.7/32 Deny Generic
5.6.7.8/32 Deny Spam
Tag: سیکشن 1اوپر کی مثال میں
"1.2.3.4/32" اور"2.3.4.5/32" "IPv4" کی کے طور پر ٹیگ کیا جائے گا، جبکہ"4.5.6.7/32" اور"5.6.7.8/32" "سیکشن 1" کے طور پر ٹیگ کیا جائے گا.اسی منطق کو بھی دیگر اقسام کے ٹیگ کو الگ کرنے کے لئے لاگو کیا جا سکتا ہے.
خاص طور پر، سیکشن ٹیگ کو ڈیبگنگ کے لئے بہت مفید ثابت ہوسکتا ہے جب غلط مثبت واقع ہوسکتا ہے، اس مسئلے کا صحیح ذریعہ تلاش کرنے کا آسان ذریعہ فراہم کرنے کے ذریعہ، اور وہ لاگ ان کے لاگ ان صفحے کے ذریعے لاگ فولائل کو دیکھتے وقت لاگ ان کی اندراجات کو فلٹر کرنے کے لئے بہت مفید ہوسکتے ہیں (سیکشن کے نام سامنے کے آخر میں لاگ ان صفحے کے ذریعے کلک کی جا سکتی ہے اور فلٹرنگ کے معیار کے طور پر استعمال کیا جا سکتا ہے). اگر کسی خاص دستخط کے لئے سیکشن ٹیگ کو چھوڑ دیا جاتا ہے تو، جب دستخط کئے جائیں گے تو، CIDRAM کے پاس آئیکریس فائل کا نام استعمال ہوتا ہے جس کے ساتھ IP ایڈریس کو بلاک کردیا گیا ہے (IPv4 یا IPv6) کے نتیجے میں، اور اس طرح سیکشن ٹیگ مکمل طور پر اختیاری ہیں. بعض صورتوں میں ان کی سفارش کی جاسکتی ہے، مثلا جب دستخط شدہ فائلوں کو نام نہاد نامزد کیا جاسکتا ہے یا جب یہ دوسری صورت میں واضح طور پر دستخط کرنے کے لئے درخواست کی وجہ سے واضح طور پر دستخط کرنا مشکل ہوسکتا ہے.
آپ دستخط سیکشن ٹیگز کو اسی انداز میں، کچھ وقت کے بعد ختم کرنا چاہتے ہیں تو، آپ کو متعین کرنے کی ایک "ختم ہونے ٹیگ" استعمال دستخط درست نہیں رہے چاہئے جب سکتا. ختم ہونے ٹیگز شکل
"YYYY.MM.DD" استعمال کرتے ہیں (ذیل کی مثال دیکھیں).# سیکشن 1.
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
Expires: 2016.12.31متوقع دستخط کسی بھی درخواست پر کبھی نہیں چلائے جائیں گے، کوئی بات نہیں.
اگر آپ کچھ خاص دستخط کے لئے اصل ملک کی وضاحت کرنا چاہتے ہیں، تو آپ "اصل ٹیگ" کا استعمال کرتے ہوئے کر سکتے ہیں. ایک اصل ٹیگ ایک دستخط "آیزو 3166-1" کو قبول کرتا ہے جو اس پر دستخط ہونے والے دستخط کے لئے اصل ملک سے ملتا ہے. یہ کوڈ اوپر اوپری میں لکھنا ضروری ہے (کم کیس یا مخلوط کیس صحیح طریقے سے فراہم نہیں کرے گا). جب اصل ٹیگ استعمال کیا جاتا ہے، یہ متعلقہ لاگ بلاک کی درخواستوں کے "کیوں بلاک شدہ" فیلڈ میں شامل کیا جاتا ہے.
اگر اختیاری "flags CSS" جزو نصب کیا جاتا ہے، سامنے کے آخر میں لاگ ان کے صفحے کے ذریعے لاگ ان کو لاگو کرتے وقت، اصل ٹیگ کی معلومات کو اس ملک کی پرچم کی طرف سے بدل دیا گیا ہے جو اس معلومات سے متعلق ہے. یہ معلومات کلک کرنے کے قابل ہے، اور جب پر کلک کیا جاتا ہے تو، ملک کے پرچم کی بنیاد پر لاگ ان اندراجوں کو فلٹر کریں گے.
نوٹ: یہ جغرافیہ نہیں ہے. یہ مخصوص مقام کی معلومات کے لئے تلاش نہیں کرتا، لیکن اس کے بجائے، ہمیں کسی بھی درخواست کے لئے بلاک کرنے کے قابل بناتا ہے. ایک ہی دستخط سیکشن کے اندر ایک سے زیادہ اصل ٹیگ جائز ہیں.
سمپوشی مثال:
1.2.3.4/32 Deny Generic
Origin: CN
2.3.4.5/32 Deny Generic
Origin: FR
4.5.6.7/32 Deny Generic
Origin: DE
6.7.8.9/32 Deny Generic
Origin: US
Tag: Foobarکسی ٹیگ کے ساتھ مل کر استعمال کیا جا سکتا ہے، اور تمام ٹیگ اختیاری ہیں (ذیل مثال دیکھیں).
# Example Section.
1.2.3.4/32 Deny Generic
Origin: US
Tag: Example Section
Expires: 2016.12.31جب بڑی تعداد میں دستخط شدہ فائلوں کو انسٹال کیا جاتا ہے اور فعال طور پر استعمال کیا جاتا ہے تو، تنصیبات بہت پیچیدہ ہوسکتے ہیں، اور کچھ دستخط بھی ہوسکتے ہیں جس پر اووریلپ. ان صورتوں میں، بلاک کے واقعات کے دوران ایک سے زائد، زیادہ اوپریپشن دستخط ہونے کی روک تھام کے لۓ، ڈویژن ٹیگز استعمال ہونے والے مخصوص دستخط کے حصوں کو خارج کرنے کے لئے استعمال کیا جا سکتا ہے، جہاں کچھ مخصوص دستخط فائل نصب ہوجائے اور فعال طور پر استعمال کیا جاتا ہے. اس صورت حال میں مفید ثابت ہوسکتا ہے جہاں کچھ دستخط دوسروں سے کہیں زیادہ اپ ڈیٹ ہوتے ہیں، تاکہ زیادہ کثرت سے اپ ڈیٹ کردہ دستخط زیادہ بار بار اپ ڈیٹ کردہ دستخط کے حق میں ہٹائیں.
حوالہ ٹیگ دیگر اقسام کے ٹیگ کے ساتھ اسی طرح استعمال ہوتے ہیں. ٹیگ کی قدر کو نصب شدہ اور فعال طور پر استعمال ہونے والے دستخط فائل سے منسلک ہونا لازمی ہے.
مثال:
1.2.3.4/32 Deny Generic
Origin: AA
2.3.4.5/32 Deny Generic
Origin: BB
Defers to: preferred_signatures.datپروفائل ٹیگز ٹیسٹ پیج پر اضافی معلومات ظاہر کرنے کا ایک ذریعہ فراہم کرتے ہیں، اور زیادہ پیچیدہ سلوک اور بہتر فیصلہ سازی کے لئے استعمال کیا جاسکتا ہے.
دوسرے قسم کے ٹیگز کی طرح ہی پروفائل ٹیگز استعمال ہوتے ہیں. پروفائل ٹیگ کی اقدار کو ماڈیولز اور معاون قواعد کی شرط کے طور پر استعمال کیا جاسکتا ہے. پروفائل ٹیگ ان اقدار کو سیمیکن سے الگ کرکے ایک سے زیادہ اقدار فراہم کرسکتے ہیں. آخری صارف پروفائل ٹیگ کی قدر کبھی نہیں دیکھتا ہے.
مثال:
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
Profile: Example;Just some generic stuff;Foo;Bar
Origin: BBمکمل طور پر اختیاری (یعنی آپ اسے استعمال کرتے ہیں تو آپ کا انتخاب ہے) YAML نشانات استعمال کرتے ہوئے، اور ترتیب میں سے اکثر کا فائدہ اٹھانے کے قابل ہے.
CIDRAM میں، تین ڈیشز ("---") کا استعمال کرتے ہوئے تعین کیا YAML جاتا ہے، اور وہ دو نئے لائنوں کا استعمال کرتے ہوئے ختم. مندرجہ ذیل مثال:
# Foobar 1.
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
4.5.6.7/32 Deny Generic
Tag: Foobar 1
---
general:
http_response_header_code: 403
emailaddr: [email protected]
logging:
standard_log: "logfile.{yyyy}-{mm}-{dd}.txt"
apache_style_log: "access.{yyyy}-{mm}-{dd}.txt"
serialised_log: "serial.{yyyy}-{mm}-{dd}.txt"
recaptcha:
lockip: false
lockuser: true
expiry: 720
recaptcha_log: "recaptcha.{yyyy}-{mm}-{dd}.txt"
enabled: true
template_data:
css_url: "https://domain.tld/cidram.css"
# Foobar 2.
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
4.5.6.7/32 Deny Generic
Tag: Foobar 2
---
general:
http_response_header_code: 503
logging:
standard_log: "logfile.Foobar2.{yyyy}-{mm}-{dd}.txt"
apache_style_log: "access.Foobar2.{yyyy}-{mm}-{dd}.txt"
serialised_log: "serial.Foobar2.{yyyy}-{mm}-{dd}.txt"
# Foobar 3.
1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
4.5.6.7/32 Deny Generic
Tag: Foobar 3
---
general:
http_response_header_code: 403
silent_mode: "http://127.0.0.1/"جب
"usemode" 2 یا 5 ہے، "خاص نشان" reCAPTCHA/hCAPTCHA کے ساتھ استعمال کے لئے دستخط حصوں، ایک اندراج ہے کہ دستخط کے حصے کے لیے YAML طبقہ میں (ذیل کی مثال ملاحظہ کریں) شامل ہے کرنے کے لئے.1.2.3.4/32 Deny Generic
2.3.4.5/32 Deny Generic
Tag: CAPTCHA Marked
---
recaptcha:
enabled: true
hcaptcha:
enabled: trueکے علاوہ، آپ CIDRAM مکمل طور پر دستخط کی فائلوں میں سے کسی کے اندر کچھ مخصوص حصوں کو نظر انداز کرنا چاہتے ہیں تو، آپ "ignore.dat" فائل ہے جس میں حصوں کو نظر انداز کرنے کی وضاحت کرنے کے لئے استعمال کر سکتے ہیں. ایک نئی لائن پر، لکھنا "Ignore"، ایک کی جگہ کے بعد، آپ کو CIDRAM نظر انداز کرنا (ذیل کی مثال ملاحظہ کریں) چاہتے ہیں کہ سیکشن کے نام کے بعد
Ignore سیکشن 1یہ CIDRAM سامنے کے آخر "حصوں کی فہرست" کے صفحے کے ذریعہ بھی حاصل کیا جا سکتا ہے.
اگر آپ محسوس کرتے ہیں کہ آپ اپنی مرضی کے دستخط شدہ فائلوں کو لکھتے ہیں یا اپنی مرضی کے مطابق ماڈیولز آپ کے لئے بہت پیچیدہ ہیں، ایک آسان متبادل سیڈامیم سامنے کے آخر "معاون قواعد" کے صفحے کا استعمال کرنا ہوسکتا ہے. مناسب اختیارات کا انتخاب کرتے ہوئے اور مخصوص قسم کے درخواستوں کے بارے میں تفصیلات کی وضاحت کرکے، آپ ان ہدایات کو جواب دینے کے بارے میں CIDRAM کو ہدایت کرسکتے ہیں. تمام دستخط شدہ فائلوں کے بعد "معاون قواعد" کو معطل کر دیا جاتا ہے اور ماڈیولز نے پہلے سے ہی عملدرآمد مکمل کر لیا ہے.
ماڈیولز CIDRAM کی فعالیت کو بڑھانے کے لئے استعمال کیا جا سکتا ہے، اضافی کاموں کو انجام دینے کے لئے، یا اضافی منطق پر عمل درآمد.
کیونکہ ماڈیولز PHP کی فائلوں کے طور پر لکھی جاتی ہیں، اگر آپ CIDRAM کوڈ بیس کے ساتھ مناسب طریقے سے واقف ہیں تو، آپ اپنی ماڈیول اور ماڈیول دستخط کی تشکیل کرسکتے ہیں تاہم آپ چاہتے ہیں (PHP کے ساتھ کیا ممکن ہے کی مناسب حدود کے اندر اندر).
نوٹ: اگر آپ PHP کے کوڈ کے ساتھ کام کرنے میں آرام دہ اور پرسکون نہیں ہیں تو، آپ کے اپنے ماڈیول لکھنے کی سفارش نہیں کی جاتی ہے.
کچھ فعالیتیں CIDRAM کی طرف سے فراہم کی جاتی ہیں جو اپنے ماڈیولز کو لکھنے کے لئے آسان اور آسان بنانا چاہئے. اس فعالیت کے بارے میں معلومات ذیل میں بیان کی گئی ہے.
ماڈیول دستخط عام طور پر
$this->trigger کے ساتھ لکھا جاتا ہے. زیادہ تر معاملات میں، یہ بندش ماڈیول لکھنے کے مقصد کیلئے کسی اور سے کہیں زیادہ اہم ہو گی.$this->trigger ۴ پیرامیٹرز کو قبول کرتا ہے: $Condition، $ReasonShort، $ReasonLong (اختیاری)، $DefineOptions (اختیاری).$Condition سچائی کا اندازہ کیا جاتا ہے. اگر یہ سچ (true) ہے تو، دستخط چالو ہے. اگر یہ غلط (false) ہے تو، دستخط چالو نہیں ہے. $Condition عام طور پر ایک ایسی شرط پر مشتمل ہے جس کی وجہ سے کسی درخواست کو بلاک کرنا ہوگا.$ReasonShort کو "کیوں بلاک شدہ" فیلڈ میں حوالہ دیا جاتا ہے جب دستخط چالو ہوجاتا ہے.$ReasonLong صارف کو ظاہر ہونے پر ایک پیغام ہے جب وہ روک رہے ہیں، اس وجہ سے وضاحت کریں کہ. ختم ہونے پر معیاری "کیوں بلاک شدہ" پیغام استعمال کرتا ہے.$DefineOptions ایک اختیاری سرنی ہے جس میں کلیدی/قدر شامل ہیں، درخواست کی مثال کے مطابق مخصوص ترتیبات کے اختیارات کی وضاحت کرنے کے لئے استعمال کیا جاتا ہے. جب دستخط چالو ہو تو ترتیب کے اختیارات لاگو کیے جائیں گے.$this->trigger سچ ہے جب دستخط چالو ہوجاتا ہے، اور جب غلط نہیں ہوتا تو غلط ہوتا ہے.دستخط بائی پاسز عام طور پر
$this->bypass کے ساتھ لکھے جاتے ہیں.$this->bypass ۳ پیرامیٹرز کو قبول کرتا ہے: $Condition، $ReasonShort، $DefineOptions (اختیاری).$Condition سچائی کا اندازہ کیا جاتا ہے. اگر یہ سچ (true) ہے تو، بائی پاس چالو ہے. اگر یہ غلط (false) ہے تو، بائی پاس چالو نہیں ہے. $Condition عام طور پر ایک ایسی شرط پر مشتمل ہے جو کسی کو بلاک کرنے کی درخواست نہیں بننی چاہئے.$ReasonShort کو "کیوں بلاک شدہ" فیلڈ میں حوالہ دیا جاتا ہے جب بائی پاس چالو ہوجاتا ہے.$DefineOptions ایک اختیاری سرنی ہے جس میں کلیدی/قدر شامل ہیں، درخواست کی مثال کے مطابق مخصوص ترتیبات کے اختیارات کی وضاحت کرنے کے لئے استعمال کیا جاتا ہے. جب دستخط چالو ہو تو ترتیب کے اختیارات لاگو کیے جائیں گے.$this->bypass سچ ہے جب بائی پاس چالو ہوجاتا ہے، اور جب غلط نہیں ہوتا.یہ ایک IP ایڈریس کے میزبان نام کو حاصل کرنے کے لئے استعمال کیا جا سکتا ہے. اگر آپ میزبانوں کو روکنے کے لئے ماڈیول بنانا چاہتے ہیں، تو یہ بندش مفید ثابت ہوسکتا ہے.
مثال:
<?php
/** Fetch hostname. */
if (empty($this->CIDRAM['Hostname'])) {
$this->CIDRAM['Hostname'] = $this->dnsReverse($this->BlockInfo['IPAddr']);
}
/** Example signature. */
if (strlen($this->CIDRAM['Hostname']) && $this->CIDRAM['Hostname'] !== $this->BlockInfo['IPAddr']) {
$this->trigger($this->CIDRAM['Hostname'] === 'www.foobar.tld', 'Foobar.tld', 'Hostname Foobar.tld is not allowed.');
}ماڈیول ان کے اپنے گنجائش کے اندر عملدرآمد کرتے ہیں، اور کسی ماڈیول کی طرف سے وضاحت کردہ متغیرات، دوسرے ماڈیولز، یا پیراگراف اسکرپٹ تک نہیں پہنچ سکیں گے، جب تک کہ وہ
$CIDRAM صف میں محفوظ نہ ہو جائیں (ماڈیول پھانسی ختم ہونے کے بعد سب کچھ صاف ہو گیا ہے).مندرجہ ذیل فہرست کچھ عام متغیر ہیں جو آپ کے ماڈیول کے لئے مفید ہوسکتے ہیں:
| تفصیل |
متغیر |
|---|---|
| موجودہ تاریخ اور وقت. |
$this->BlockInfo['DateTime'] |
| موجودہ درخواست کے لئے IP ایڈریس. |
$this->BlockInfo['IPAddr'] |
| CIDRAM سکرپٹ ورژن. |
$this->BlockInfo['ScriptIdent'] |
| موجودہ درخواست کے لئے سوال. |
$this->BlockInfo['Query'] |
| موجودہ درخواست کے لئے ریفرر (اگر ایک موجود ہے). |
$this->BlockInfo['Referrer'] |
| موجودہ درخواست کے لئے صارف ایجنٹ (user agent). |
$this->BlockInfo['UA'] |
| موجودہ درخواست کے لئے کم کیس میں صارف ایجنٹ (user agent). |
$this->BlockInfo['UALC'] |
| جب صارف کو بلاک کردیا جاتا ہے تو صارف کو ظاہر کرنے کا پیغام. |
$this->BlockInfo['ReasonMessage'] |
| دستخط کی تعداد موجودہ درخواست کے لئے شروع ہوگئی ہے. |
$this->BlockInfo['SignatureCount'] |
| کسی بھی دستخط کے لئے حوالہ کی معلومات موجودہ درخواست کے لئے تیار ہوئی. |
$this->BlockInfo['Signatures'] |
| کسی بھی دستخط کے لئے حوالہ کی معلومات موجودہ درخواست کے لئے تیار ہوئی. |
$this->BlockInfo['WhyReason'] |
مندرجہ ذیل پیکجوں اور مصنوعات کو CIDRAM کے ساتھ مطابقت پذیر ہونے کے لئے مل گیا ہے:
اس بات کا یقین کرنے کے لئے کہ مندرجہ ذیل پیکجوں اور مصنوعات CIDRAM کے ساتھ مطابقت پذیر ہوں گے ماڈیولز دستیاب کیے گئے ہیں:
- ایک "دستخط" کیا ہے؟
- ایک "CIDR" کیا ہے؟
- ایک "جھوٹی مثبت" سے کیا مراد ہے؟
- بلاک تمام ممالک CIDRAM کر سکتا ہوں؟
- دستخط کیسے بیشتر اپ ڈیٹ کر رہے ہیں؟
- CIDRAM استعمال کرتے ہوئے میں ایک مسئلہ کا سامنا کرنا پڑا ہے اور میں اس کے بارے میں کیا پتہ نہیں ہے! مدد کریں!
- میں نے دورہ کرنا چاہتے ہیں کہ ایک ویب سائٹ سے CIDRAM کی طرف سے بلاک کیا گیا ہے! مدد کریں!
- میں 7.2 سے زیادہ پرانے ایک PHP ورژن کے ساتھ CIDRAM v3 استعمال کرنا چاہتے ہیں؛ کیا آپ مدد کر سکتے ہیں؟
- میں نے ایک سے زیادہ ڈومینز کی حفاظت کے لئے ایک واحد CIDRAM تنصیب کا استعمال کر سکتا ہوں؟
- میں نے اس پر وقت خرچ نہیں کرنا چاہتا (اسے انسٹال، اس کے قیام، وغیرہ)؛ میں نے آپ کو ایسا کرنے کے لئے ادا کر سکتے ہیں؟
- میں ذاتی کام کے لئے آپ کی خدمات حاصل کر سکتے ہیں؟
- مجھے خصوصی ترمیم کی ضرورت؛ کیا آپ مدد کر سکتے ہیں؟
- میں نے ایک ڈویلپر، ویب سائٹ ڈیزائنر، یا پروگرامر ہوں. میں اس منصوبے سے متعلق کام کر سکتے ہیں؟
- میں نے اس منصوبے میں شراکت کے لئے چاہتے ہیں؛ میں یہ کر سکتا ہوں؟
- کیا میں خود کار طریقے سے اپ ڈیٹ کرنے کیلئے cron استعمال کرسکتا ہوں؟
- "خلاف ورزی" کیا ہیں؟
- CIDRAM بلاک میزبانوں کو کر سکتے ہیں؟
- میں "default_dns" کے لئے کیا استعمال کر سکتا ہوں؟
- کیا ویب سائٹس کے علاوہ چیزوں کی حفاظت کے لئے میں CIDRAM استعمال کرسکتا ہوں (مثال کے طور پر، ای میل سرورز، FTP سرورز، SSH سرورز، IRC سرورز، وغیرہ)؟
- مواد ترسیل کے نیٹ ورک یا کیشنگ کی خدمات کا استعمال کرتے ہوئے ایک ہی وقت میں CIDRAM کا استعمال کرتے ہوئے، کیا مسائل ہو گی؟
- کیا CIDRAM DDoS حملوں کے خلاف میری ویب سائٹ کی حفاظت کرتا ہے؟
- جب میں اپ ڈیٹس کے صفحے کے ذریعہ ماڈیولز یا دستخط شدہ فائلوں کو چالو یا غیر فعال کروں تو، یہ انفرادی طور پر ترتیب میں تبدیل کرتا ہے. کیا میں اس راستہ کو تبدیل کر سکتا ہوں جسے وہ ترتیب دیں گے؟
- "PDO DSN" کیا ہے؟ میں CIDRAM کے ساتھ PDO کیسے استعمال کرسکتا ہوں؟
- CIDRAM cronjobs کو مسدود کررہا ہے؛ اس کو کیسے ٹھیک کریں؟
CIDRAM کے تناظر میں، اعداد و شمار کے مخصوص کچھ ہم کے لئے تلاش کر رہے ہیں اس کی شناخت کے لئے استعمال کیا جاتا ہے کے لئے ایک "دستخط" مراد، عام طور پر ایک IP ایڈریس یا CIDR، CIDRAM لئے کچھ ہدایات کے ساتھ (یہ مقابلوں جب ہم کے لئے تلاش کر رہے ہیں کیا جواب دینے کا بہترین طریقہ، وغیرہ). CIDRAM لئے ایک مخصوص دستخط کی کچھ اس طرح دکھائی دیتی ہے:
"دستخط فائلوں" کیلئے:
1.2.3.4/32 Deny Generic
"ماڈیولز" کے لئے:
$this->trigger(strpos($this->BlockInfo['UA'], 'Foobar') !== false, 'Foobar-UA', 'User agent "Foobar" not allowed.');نوٹ: "دستخط فائلوں" کے لئے دستخط، اور "ماڈیولز" کے لئے دستخط وہی چیز نہیں ہیں.
اکثر ایسا ہوتا ہے (لیکن ہمیشہ نہیں)، دستخط "کے دستخط حصوں" میں بنڈل گا، اکثر تبصرے، مارک اپ، اور متعلقہ میٹا ڈیٹا کے ساتھ شامل تھے. یہ دستخط اور مزید ہدایات کے لئے اضافی سیاق و سباق فراہم کر سکتے ہیں.
"CIDR" "Classless Inter-Domain Routing" ("غیر طبقاتی انٹر ڈومین روٹنگ") کے لئے مخفف ہے [۱، ۲]. یہ مخفف اس پیکج، "CIDRAM" کے لئے نام کا حصہ کے طور پر استعمال کیا جاتا ہے. یہ "Classless Inter-Domain Routing Access Manager" (غیر طبقاتی انٹر ڈومین روٹنگ رسائی مینیجر) کے لئے مخفف ہے.
تاہم، CIDRAM کے تناظر میں (جیسا کہ، یہ دستاویزات کے اندر اندر، متعلقہ مباحث میں، یا زبان کے اعداد و شمار کے اندر اندر)، ایک "CIDR" (واحد) یا "CIDR" (جمع) کا ذکر کیا جاتا ہے جب، ہمارے ارادہ معنی ذیلی نیٹ ہے، CIDR سنکیتن کا استعمال کرتے ہوئے اظہار کیا. ذیلی نیٹ کو مختلف مختلف طریقوں سے اظہار کیا جا سکتا ہے کیونکہ اس کی وجہ ہے. CIDRAM، لہذا، ایک "نیٹ رسائی مینیجر" سمجھا جا سکتا ہے.
یہ وضاحت، اور فراہم تناظر، کسی بھی ابہام حل کرنے کے لئے مدد کرنی چاہئے.
اصطلاح "جھوٹی مثبت" (متبادل کے طور پر: "جھوٹی مثبت غلطی"؛ "جھوٹے الارم")، بیان بہت صرف، اور ایک عام سیاق و سباق میں، ایک کی حالت کے لئے جانچ جب، استعمال کیا جاتا ہے کہ ٹیسٹ کے نتائج کا حوالہ دیتے ہیں کے لئے، نتائج مثبت ہیں جب (یعنی حالت "مثبت" یا "سچ" ہونے کا تعین کیا جاتا ہے)، لیکن بننے کی توقع کی جاتی ہے (یا ہونا چاہیئے) منفی (یعنی حالت، حقیقت میں، "منفی"، یا "جھوٹے"). "جھوٹی مثبت" مثل غور کیا جا سکتا کے لئے "رونا بھیڑیا" (جس حالت تجربہ کیا جا رہا، حالت "جھوٹے" کہ میں ریوڑ کے قریب کوئی بھیڑیا ہے، اور شرط کے طور پر رپورٹ کیا جاتا ہے ریوڑ کے قریب ایک بھیڑیا ہے کہ آیا ہے "بھیڑیا، بھیڑیا" بلا کی راہ کی طرف چرواہا کی طرف سے "مثبت")، یا طبی جانچ میں حالات جس میں ایک مریض، کچھ بیماری یا مرض ہونے حقیقت میں، وہ ایسی کوئی بیماری یا مرض ہے جب کے طور پر تشخیص کی جاتی ہے کے مطابق.
ایک شرط کے لئے جانچ جب متعلقہ نتائج "سچ مثبت" کی اصطلاحات کا استعمال کرتے ہوئے، "سچ منفی" اور "جھوٹے منفی" بیان کیا جا سکتا ہے. "سچ مثبت" جب ٹیسٹ کے نتائج اور حالت کی اصل ریاست دونوں حقیقی (یا "مثبت")، اور ایک "حقیقی منفی" ہیں سے مراد ہے سے مراد ہے جب ٹیسٹ کے نتائج اور کی اصل ریاست شرط ہیں دونوں جھوٹے ہیں (یا "منفی")؛ "سچ مثبت" یا "سچ منفی" ایک "صحیح اندازہ" سمجھا جاتا ہے. ایک "جھوٹی مثبت" کے برعکس ایک "جھوٹے منفی" ہے؛ "جھوٹے منفی" سے ٹیسٹ کے نتائج منفی ہیں، جب (یعنی حالت "منفی"، یا "جھوٹے" ہونے کا تعین کیا جاتا ہے)، لیکن بننے کی توقع کی جاتی ہے (یا ہونا چاہیئے) مراد مثبت (یعنی، حالت، حقیقت میں، "مثبت" یا "سچ") ہے.
CIDRAM کے تناظر میں، ان شرائط جسے انہوں بلاک CIDRAM کے دستخط اور کیا / کا حوالہ دیتے ہیں. ایک IP ایڈریس، برا فرسودہ یا غلط دستخطوں کی وجہ CIDRAM بلاکس، لیکن ایسا نہیں کیا جب چاہئے ہے، یا یہ غلط وجوہات کی بناء پر ایسا کرتا ہے جب، ہم نے ایک "جھوٹی مثبت" کے طور پر اس ایونٹ کا حوالہ دیتے ہیں. CIDRAM ایک IP ایڈریس جو، کی وجہ سے غیر متوقع خطرات سے، بلاک کر دیا گیا ہے چاہئے لاپتہ اس کے دستخط میں دستخط یا کمی کو بلاک کرنے میں ناکام ہونے پر، ہم نے ایک "یاد کا پتہ لگانے" (ایک "جھوٹے منفی" کے مطابق ہوتا ہے) کے طور پر اس واقعہ کا حوالہ دیتے ہیں.
یہ مندرجہ ذیل ٹیبل کی طرف سے بیان کیا جا سکتا ہے:
| CIDRAM چاہئے نہیں ایک IP ایڈریس بلاک |
CIDRAM ایک IP ایڈریس مسدود کرنا چاہئے |
|
|---|---|---|
| یہ سچ ہے کہ منفی (صحیح اندازہ) |
فوت شدہ کا پتہ لگانے (جھوٹے منفی کے مطابق) |
CIDRAM نہیں بلاک ایک IP ایڈریس کراسکتا |
| جھوٹی مثبت |
یہ سچ ہے کہ مثبت (صحیح اندازہ) |
CIDRAM ہے ایک IP ایڈریس بلاک |
جی ہاں. اس کا آسان ترین طریقہ BGPView ماڈیول کو انسٹال کرنا اور اپنی ضروریات کے مطابق تشکیل دینا ہے.
اپ ڈیٹ فریکوئنسی سوال میں دستخط کی فائلوں پر منحصر ہوتی ہے. CIDRAM دستخط کی فائلوں کے لئے تمام حاکم عام طور پر اپ ڈیٹ کرنے کے لئے ممکن ہے کے طور پر کے طور پر ان کے دستخط رکھنے کی کوشش کرتے ہیں، لیکن ہم سب کے طور پر مختلف دیگر وعدوں، اس منصوبے سے باہر ہماری زندگی ہے، اور ہم میں سے کوئی اس کو مالی طور پر معاوضہ رہے ہیں (یعنی، ادا کی ) منصوبے پر ہماری کوششوں کے لئے ایک عین مطابق اپ ڈیٹ کے شیڈول کی ضمانت نہیں کیا جا سکتا. ان کو اپ ڈیٹ کرنے کے لئے کافی وقت نہیں ہے جب بھی، اور عام طور پر، حاکم ضرورت پر اور حدود کے درمیان پائے جاتے تبدیلیاں کس طرح اکثر کی بنیاد پر ترجیح دینے کی کوشش کریں عام طور پر، دستخطوں کو اپ ڈیٹ کر رہے ہیں. اگر آپ کو کوئی پیشکش کرنے کو تیار ہیں تو اس سلسلے میں معاونت ہمیشہ تعریف کی ہے.
- آپ نے سافٹ ویئر کا تازہ ترین ورژن استعمال کر رہے ہیں؟ آپ کو آپ کے دستخط فائلوں کا تازہ ترین ورژن استعمال کر رہے ہیں؟ ان دو سوالوں کی یا تو کرنے کے لئے جواب نہیں ہے تو، سب سے پہلے سب کچھ کو اپ ڈیٹ کرنے کی کوشش کریں، اور چاہے وہ مسئلہ برقرار رہتا ہے چیک کریں. یہ برقرار رہتا ہے، پڑھنے جاری رکھیں.
- اگر آپ کو تمام دستاویزات کے ذریعے کی جانچ پڑتال کی ہے؟ اگر نہیں، تو براہ مہربانی. مسئلہ دستاویزات استعمال کر حل نہیں کیا جا سکتا ہے، تو پڑھنے جاری رکھیں.
- اگر آپ کو issues صفحے جانچ پڑتال کی ہے، دیکھنا چاہے مسئلہ پہلے ذکر کیا گیا ہے؟ اس سے پہلے ذکر کیا گیا ہے تو، چاہے وہ کسی بھی تجاویز، خیالات، اور / یا کے حل فراہم کیا گیا جانچ اور مسئلہ حل کرنے کی کوشش کرنے کے لئے ضروری کے مطابق عمل کریں.
- اگر مسئلہ اب بھی جاری رہتا ہے، تو issues کے صفحے پر ایک نیا issue تشکیل دے کر اس کے بارے میں مدد طلب کریں.
CIDRAM ویب سائٹ کے مالکان ناپسندیدہ ٹریفک کو بلاک کرنے کے لئے ایک ذریعہ فراہم کرتا ہے، لیکن یہ وہ CIDRAM استعمال کرنا چاہتے ہیں کہ کس طرح اپنے لئے فیصلہ کرنے کے لئے ویب سائٹ کے مالکان کی ذمہ داری ہے. کے دستخط سے متعلق جھوٹی مثبت عام طور CIDRAM ساتھ شامل فائلوں کی صورت میں، تصحیح بنایا جا سکتا ہے، لیکن مخصوص ویب سائٹس سے غیر مسدود ہونے کے حوالے میں، آپ کے سوال میں ویب سائٹس کے مالکان کے ساتھ کہ اپ لینے کی ضرورت پڑے گی. مقدمات جہاں تصحیح کم سے کم، بنائے جاتے ہیں میں، وہ مثال ہے، وہ ان کی تنصیب ترمیم شدہ گئے ہیں جہاں کے لئے، اس طرح کے طور پر ان کے دستخط فائلوں اور / یا تنصیب، اور دیگر مقدمات میں (اپ ڈیٹ کرنے کی ضرورت ہو گی، ان کی اپنی مرضی کے دستخط پیدا، وغیرہ)، کو حل کرنے کی ذمہ داری آپ کا مسئلہ مکمل طور پر ان کی ہے، اور ہمارے قابو سے باہر مکمل طور پر ہے.
نہیں. CIDRAM v3 کم از کم PHP≥7.2 کی ضرورت ہے.
جی ہاں. CIDRAM ایک سے زیادہ ڈومینز کی حفاظت کے لئے استعمال کیا جا سکتا ہے. ضرورت کی ترتیب مختلف ہے تو، ایسا کرنے کے لئے تحفظ کی ضرورت ہوتی ڈومینز کے مطابق نامی نئی ترتیب فائل، تخلیق کرتے ہیں. CIDRAM یہ ڈومین کیلئے کام کرنا چاہئے کہ کس طرح اس بات کا تعین کرنے کے لئے ان فائلوں کو استعمال کریں گے. سوف تستخدم CIDRAM هذه الملفات لتحديد كيفية تشغيلها للنطاق. ایک مثال کے طور، کے لئے
"https://www.some-domain.tld/"، اس کا نام ہے "some-domain.tld.config.yml". ڈومین نام "HTTP_HOST" سے آتا ہے. "www" نظر انداز کر دیا جاتا ہے.شاید. یہ معاملہ در معاملہ کی بنیاد پر کیا جاتا ہے. کی آپ کو ضرورت ہے ہمیں بتائیں. ہمیں بتائیں کہ آپ کی پیشکش کر رہے ہیں. ہم آپ کو بتا دیں گے ہم مدد کر سکتے ہیں.
اوپر ملاحظہ کریں.
اوپر ملاحظہ کریں.
جی ہاں. ہمارے لائسنس اس کی ممانعت نہیں کرتا.
جی ہاں. اس کا خیر مقدم کیا جاتا ہے. "CONTRIBUTING.md" ملاحظہ کریں مزید معلومات کے لئے.
جی ہاں. بیرونی سکرپٹ کے ذریعہ اپ ڈیٹس صفحہ کے ساتھ بات چیت کرنے کے لئے ایک API سامنے کے آخر میں بنایا جاتا ہے. ایک علیحدہ لکھاوٹ، "Cronable"، دستیاب ہے، اور اس کے اور دیگر معاون پیکجوں کو خود کار طریقے سے اپ ڈیٹ کرنے کے لئے آپ کے cron manager یا cron scheduler کا استعمال کیا جا سکتا ہے (یہ اسکرپٹ اپنی اپنی دستاویزات فراہم کرتا ہے).
"دستخط شمار" اور "خلاف ورزی" دونوں کا تعلق کسی خاص درخواست کے دوران شروع ہونے والے دستخطوں کی شدت اور تعداد سے ہے، چاہے دستخطی فائلوں، ماڈیولز، معاون اصولوں، یا کسی اور وجہ سے. لیکن، جب کہ "دستخط شمار" صرف اس مخصوص درخواست کے لیے برقرار رہتی ہے، "خلاف ورزی" زیادہ سے زیادہ درخواستوں پر برقرار رہ سکتی ہے جیسا کہ
default_tracktime کے ذریعے طے کیا گیا ہے.یہ اس بات کو یقینی بناتا ہے کہ جب ایک درخواست کو کافی تعداد میں خلاف ورزیوں کے ساتھ بلاک کیا جاتا ہے، تو اسی ذریعہ سے آنے والی درخواستوں کو بھی بلاک کیا جا سکتا ہے.
جی ہاں. یہ ایک معاون اصول یا حسب ضرورت ماڈیول بنا کر حاصل کیا جا سکتا ہے.
عام طور پر، کسی قابل اعتماد DNS سرور کا IP کافی ہونا چاہئے. اگر آپ تجاویز کی تلاش کر رہے ہیں تو، public-dns.info اور OpenNIC نام سے جانا جاتا، عوامی DNS سرورز کی وسیع فہرست فراہم کرتے ہیں. متبادل طور پر، ذیل میں میز ملاحظہ کریں:
| IP | آپریٹر |
|---|---|
1.1.1.1 |
Cloudflare |
8.8.4.48.8.8.82001:4860:4860::88442001:4860:4860::8888 |
Google Public DNS |
9.9.9.9149.112.112.112 |
Quad9 DNS |
84.200.69.8084.200.70.402001:1608:10:25::1c04:b12f2001:1608:10:25::9249:d69b |
DNS.WATCH |
208.67.220.220208.67.222.220208.67.222.222 |
OpenDNS Home |
77.88.8.177.88.8.82a02:6b8::feed:0ff2a02:6b8:0:1::feed:0ff |
Yandex.DNS |
8.20.247.208.26.56.26 |
Comodo Secure DNS |
216.146.35.35216.146.36.36 |
Dyn |
64.6.64.664.6.65.6 |
Verisign Public DNS |
37.235.1.17437.235.1.17745.33.97.5172.104.237.57172.104.49.100 |
FreeDNS |
156.154.70.1156.154.71.12610:a1:1018::12610:a1:1019::1 |
Neustar Security |
45.32.36.3645.77.165.194 |
Fourth Estate |
74.82.42.42 |
Hurricane Electric |
195.46.39.39195.46.39.40 |
SafeDNS |
89.233.43.7191.239.100.100 2001:67c:28a4::2a01:3a0:53:53:: |
UncensoredDNS |
208.76.50.50208.76.51.51 |
SmartViper |
نوٹ: میں نجی رازداری کے عمل، سیکورٹی، افادیت، اور کسی بھی DNS کی خدمات، درج کی یا دوسری صورت میں قابل اعتماد کے بارے میں کوئی دعوی نہیں کرتا. جب آپ کے بارے میں فیصلے کرتے ہیں تو براہ کرم خود اپنی تحقیق کریں.
آپ یہ کر سکتے ہیں (قانونی احساس میں)، لیکن آپ کو نہیں ہونا چاہئے (تکنیکی اور عملی احساس میں). ہمارے لائسنس کو CIDRAM کا استعمال کیا ٹیکنالوجی کی حد تک محدود نہیں ہے. تاہم، CIDRAM ایک "ویب ایپلی کیشن فائر وال" (WAF) ہے، جو ویب سائٹس کی حفاظت کے لئے ہے. دوسرے مقاصد کے لئے استعمال ہونے پر یہ مؤثر یا قابل اعتماد ہونے کا امکان نہیں ہے (کیونکہ یہ دماغ میں دیگر ٹیکنالوجیوں کے ساتھ ڈیزائن نہیں کیا گیا تھا)، عملدرآمد مشکل ہوسکتا ہے، اور غلطیوں اور دیگر مسائل کا خطرہ بہت زیادہ ہے.
ممکنہ طور پر. یہ سوال میں خدمت کی نوعیت پر منحصر ہے، اور آپ اس کا استعمال کیسے کر رہے ہیں. عموما، اگر آپ صرف جامد اثاثوں کو پکڑ رہے ہیں تو (تصاویر، CSS، وغیرہ؛ جو وقت کے ساتھ تبدیل نہیں ہوتا ہے)، کوئی مسئلہ نہیں ہونا چاہئے. تاہم، وہاں مسائل ہوسکتے ہیں، اگر آپ ڈیٹا کیشنگ کر رہے ہیں جو عام طور پر متحرک طور پر پیدا ہوجائے تو درخواست کی جاتی ہے، یا اگر آپ POST کی درخواستوں کے نتائج کو پکڑ رہے ہیں (یہ آپ کی ویب سائٹ اور ماحول کو جامد طور پر فراہم کرے گا، اور CIDRAM ایک مستحکم ماحول میں کسی بھی معقول فائدہ فراہم کرنے کے لئے امکان نہیں ہے). اس کے علاوہ، آپ کو استعمال کرنے والے مواد کی ترسیل کے نیٹ ورک یا کیشنگ سروس پر منحصر ہے، اس کے مطابق CIDRAM مخصوص ترتیبات کی ضروریات ہوسکتی ہے (آپ کو اس بات کا یقین کرنے کی ضرورت ہوگی کہ CIDRAM صحیح طریقے سے ترتیب دیا جائے). غلط ترتیب کی وجہ سے غلط جھوٹے مثبت اور دیگر مسائل کا سبب بن سکتا ہے.
یہ نہیں کرے گا.
مزید تفصیل میں: CIDRAM اس اثر کو کم کرنے میں مدد دے گی جو ناپسندیدہ ٹریفک آپ کی ویب سائٹ اور ہارڈ ویئر پر ہوسکتی ہے (اس کا مطلب سستا ویب سائٹ بینڈوڈتھ اخراجات اور صحت مند سرور). تاہم، اس سوال کو سمجھنے کے لۓ دو اہم چیزیں ہیں جو یاد رکھنا ضروری ہے.
۱. CIDRAM ایک PHP پیکیج ہے، اور اس وجہ سے چلاتا ہے جہاں PHP انسٹال ہے. اس کا مطلب یہ ہے کہ سرور پہلے سے موصول ہونے کے بعد CIDRAM صرف درخواستوں کو دیکھ سکتے ہیں اور بلاک کرسکتے ہیں. ۲. DDoS حملے کے ذریعہ ھدف کردہ سرور تک پہنچنے سے قبل مؤثر DDoS کمیشن کو درخواستوں کو فلٹر کرنا چاہئے. مثالی طور پر، وہ ان جگہوں سے پتہ لگانے اور کم کرنے کے قابل ہونا چاہئے جو حملوں کے ساتھ منسلک ٹریفک کو ختم کرنے میں کامیاب ہوسکتی ہیں، اس سے پہلے کہ وہ پہلی جگہ میں ھدف شدہ سرور تک پہنچے.
اس کو نافذ کرنے کے کچھ طریقے: وقف ہارڈ ویئر کے حل. وقف DDoS کمیشن کی خدمات. DDoS مزاحم نیٹ ورک کے ذریعہ ڈومین کے DNS کو روٹنگ. کلاؤڈ پر مبنی فلٹرنگ. متبادل طور پر: اس کا کچھ مجموعہ کسی بھی صورت میں، یہ مضمون پیچیدہ ہے، لہذا اگر آپ اس میں دلچسپی رکھتے ہیں تو میں مزید تحقیق کروں گا. جب DDoS کے حملوں کی صحیح نوعیت مناسب طریقے سے سمجھ گئی ہے، تو یہ جواب زیادہ احساس کرے گا.
جی ہاں. اگر آپ کو مخصوص فائلوں میں عمل درآمد کرنے کے لئے کچھ فائلوں پر مجبور کرنے کی ضرورت ہے تو، آپ ان کے نام سے پہلے ان ترتیبات کو ہدایت دیتے ہیں جہاں وہ فہرست میں درج ہوتے ہیں، ان سے پہلے کسی بھی مباحثہ کے اعداد و شمار کو شامل کرسکتے ہیں. جب اپ ڈیٹس کے صفحے کو بعد میں فائلوں کو دوبارہ ترتیب دیتا ہے، تو اس نے مزید کہا کہ خود مختار اعداد و شمار اس طرح کے حکم کو متاثر کرے گی، جس کے نتیجے میں ان کے نتیجے میں عملدرآمد کرنے کے نتیجے میں عملدرآمد کرنے کے لۓ، بغیر کسی کو تبدیل کرنے کی ضرورت ہے.
مثال کے طور پر، مندرجہ ذیل درج ذیل فائلوں کے ساتھ ایک ترتیب ڈائریکٹری کو فرض کرنا:
modules: |
file1.php
file2.php
file3.php
file4.php
file5.phpاگر آپ چاہتے تھے کہ
file3.php سب سے پہلے عمل کرنے کیلئے، آپ فائل کے نام سے پہلے aaa: کی طرح کچھ شامل کرسکتے ہیں:modules: |
file1.php
file2.php
aaa:file3.php
file4.php
file5.phpپھر، اگر ایک نئی فائل،
file6.php، چالو کر دیا جاتا ہے، جب اپ ڈیٹس صفحہ ان کو دوبارہ دوبارہ تبدیل کرتا ہے، تو اسے اس طرح ختم کرنا چاہئے:modules: |
aaa:file3.php
file1.php
file2.php
file4.php
file5.php
file6.phpایک ہی صورت حال حال ہی میں ایک فائل غیر فعال ہے. اس کے برعکس، اگر آپ چاہتے تھے کہ آخری فائل کو عمل کرنے کے لۓ، آپ فائل کے نام سے پہلے
zzz: کی طرح کچھ شامل کرسکیں. کسی بھی صورت میں، آپ کو سوال میں فائل کا نام تبدیل کرنے کی ضرورت نہیں ہوگی."PHP Data Objects" (PHP ڈیٹا آبجیکٹ)، "PDO" کا مخفف ہے. یہ PHP کو ایک انٹرفیس فراہم کرتا ہے تاکہ وہ PHP کی ایپلی کیشنز کے ذریعہ استعمال ہونے والے ڈیٹا بیس سسٹم سے رابطہ قائم کرسکیں.
"data source name" (ڈیٹا سورس کا نام)، "DSN" کا مخفف ہے. یہ PDO کو بیان کرتا ہے کہ اسے ڈیٹا بیس سے کیسے جڑنا چاہئے.
CIDRAM میں، آپ کیڈیچنگ مقاصد کے لئے PDO استعمال کرسکتے ہیں. تاکہ اسے صحیح طریقے سے کام کیا جاسکے، ترتیب کے ذریعہ اس کو اہل بنائیں، اس کے لئے ایک ڈیٹا بیس بنائیں، اور نیچے بیان کردہ ڈھانچے کے مطابق اپنے ڈیٹا بیس میں ایک نیا ٹیبل بنائیں.
جب ایک ڈیٹا بیس کنکشن کامیابی کے ساتھ ہے، لیکن ضروری جدول موجود نہیں ہے، یہ خود بخود تخلیق کرنے کی کوشش کرے گی. تاہم، اس طرز عمل کا بڑے پیمانے پر تجربہ نہیں کیا گیا ہے اور کامیابی کی ضمانت نہیں دی جاسکتی ہے.
اگر آپ اسے استعمال نہیں کرنا چاہتے ہیں تو، آپ ان ہدایات کو نظرانداز کرسکتے ہیں.
ذیل میں بیان کردہ ڈھانچے میں "cidram" کو اپنے ڈیٹا بیس کے نام کے بطور استعمال کیا گیا ہے، لیکن آپ اپنے ڈیٹا بیس کے لئے جو بھی نام استعمال کرنا چاہ، استعمال کرسکتے ہیں، جب تک کہ وہی نام آپ کی ڈی ایس این ترتیب میں نقل کیا جائے.
╔══════════════════════════════════════════════╗
║ DATABASE "cidram" ║
║ │╔═══════════════════════════════════════════╩═════╗
║ └╫─TABLE "Cache" (UTF-8) ║
║ ╠═╪═FIELD══CHARSET═DATATYPE═════KEY══NULL═DEFAULT═╣
║ ║ ├─"Key"──UTF-8───VARCHAR(128)─PRI──×────× ║
║ ║ ├─"Data"─UTF-8───TEXT─────────×────×────× ║
╚══╣ └─"Time"─×───────INT(>=10)────×────×────× ║
╚═════════════════════════════════════════════════╝pdo_dsn نیچے جیسا کہ بیان کیا جانا چاہئے.ڈیٹا بیس ڈرائیور کس پر استعمال ہوتا ہے اس پر منحصر ہے...
├─4d (انتباہ: تجرباتی، غیر جانچ شدہ، تجویز کردہ نہیں)
│ │
│ │ ╔═══════╗
│ └─4D:host=localhost;charset=UTF-8
│ ╚╤══════╝
│ └رابطہ کرنے کیلئے میزبان
├─cubrid
│ │
│ │ ╔═══════╗ ╔═══╗ ╔═════╗
│ └─cubrid:host=localhost;port=33000;dbname=example
│ ╚╤══════╝ ╚╤══╝ ╚╤════╝
│ │ │ └استعمال کرنے کے لئے ڈیٹا بیس کا نام
│ │ │
│ │ └استعمال کرنے کیلئے پورٹ نمبر
│ │
│ └رابطہ کرنے کیلئے میزبان
├─dblib
│ │
│ │ ╔═══╗ ╔═══════╗ ╔═════╗
│ └─dblib:host=localhost;dbname=example
│ ╚╤══╝ ╚╤══════╝ ╚╤════╝
│ │ │ └استعمال کرنے کے لئے ڈیٹا بیس کا نام
│ │ │
│ │ └رابطہ کرنے کیلئے میزبان
│ │
│ └Possible values: "mssql", "sybase", "dblib".
├─firebird
│ │
│ │ ╔═══════════════════╗
│ └─firebird:dbname=/path/to/database.fdb
│ ╚╤══════════════════╝
│ ├مقامی ڈیٹا بیس فائل کا راستہ ثابت ہوسکتا ہے
│ │
│ ├ایک میزبان اور پورٹ نمبر سے رابطہ کرسکتے ہیں
│ │
│ └اگر آپ اسے استعمال کرنا چاہتے ہیں تو آپ کو Firebird دستاویزات کا حوالہ دینا چاہئے
├─ibm
│ │
│ │ ╔═════╗
│ └─ibm:DSN=example
│ ╚╤════╝
│ └رابطہ کرنے کے لئے کیٹلوجڈ ڈیٹا بیس
├─informix
│ │
│ │ ╔═════╗
│ └─informix:DSN=example
│ ╚╤════╝
│ └رابطہ کرنے کے لئے کیٹلوجڈ ڈیٹا بیس
├─mysql (سب سے زیادہ تجویز کردہ)
│ │
│ │ ╔═════╗ ╔═══════╗ ╔══╗
│ └─mysql:dbname=example;host=localhost;port=3306
│ ╚╤════╝ ╚╤══════╝ ╚╤═╝
│ │ │ └استعمال کرنے کیلئے پورٹ نمبر
│ │ │
│ │ └رابطہ کرنے کیلئے میزبان
│ │
│ └استعمال کرنے کے لئے ڈیٹا بیس کا نام
├─oci
│ │
│ │ ╔═════╗
│ └─oci:dbname=example
│ ╚╤════╝
│ ├مخصوص کیٹلوجڈ ڈیٹا بیس کا حوالہ دے سکتا ہے
│ │
│ ├ایک میزبان اور پورٹ نمبر سے رابطہ کرسکتے ہیں
│ │
│ └اگر آپ اسے استعمال کرنا چاہتے ہیں تو آپ کو Oracle دستاویزات کا حوالہ دینا چاہئے
├─odbc
│ │
│ │ ╔═════╗
│ └─odbc:example
│ ╚╤════╝
│ ├مخصوص کیٹلوجڈ ڈیٹا بیس کا حوالہ دے سکتا ہے
│ │
│ ├ایک میزبان اور پورٹ نمبر سے رابطہ کرسکتے ہیں
│ │
│ └اگر آپ اسے استعمال کرنا چاہتے ہیں تو آپ کو ODBC/DB2 دستاویزات کا حوالہ دینا چاہئے
├─pgsql
│ │
│ │ ╔═══════╗ ╔══╗ ╔═════╗
│ └─pgsql:host=localhost;port=5432;dbname=example
│ ╚╤══════╝ ╚╤═╝ ╚╤════╝
│ │ │ └استعمال کرنے کے لئے ڈیٹا بیس کا نام
│ │ │
│ │ └استعمال کرنے کیلئے پورٹ نمبر
│ │
│ └رابطہ کرنے کیلئے میزبان
├─sqlite
│ │
│ │ ╔════════╗
│ └─sqlite:example.db
│ ╚╤═══════╝
│ └استعمال کرنے کے لئے مقامی ڈیٹا بیس فائل کا راستہ
└─sqlsrv
│
│ ╔═══════╗ ╔══╗ ╔═════╗
└─sqlsrv:Server=localhost,1521;Database=example
╚╤══════╝ ╚╤═╝ ╚╤════╝
│ │ └استعمال کرنے کے لئے ڈیٹا بیس کا نام
│ │
│ └استعمال کرنے کیلئے پورٹ نمبر
│
└رابطہ کرنے کیلئے میزباناگر آپ اپنے DSN کو تبدیل کرنے کے بارے میں یقین نہیں رکھتے ہیں تو، کچھ بھی تبدیل کیے بغیر اسے استعمال کرنے کی کوشش کریں.
pdo_username اور pdo_password آپ کے صارف کے نام اور پاس ورڈ کی طرح ہونا چاہئے جو آپ نے اپنے ڈیٹا بیس کے لئے منتخب کیا ہے.اگر آپ cronjobs کے لئے ایک سرشار فائل استعمال کر رہے ہیں، اگر عام صارف کی درخواستوں کے دوران اس فائل کو کال کرنے کی ضرورت نہیں ہے، اس بات کو یقینی بنانا کہ آپ کے cronjobs کے دوران CIDRAM پر عمل درآمد نہیں کیا جاتا ہے سب سے آسان حل ہے.
اگر یہ ممکن نہیں ہے، اگر آپ کے کرون سرور کا IP ایڈریس مستقل اور پیش گوئی ہے، اپنی مرضی کے مطابق دستخط فائل میں وائٹ لسٹ دستخط بنانے کی کوشش کریں، یا اس کو سفید کرنے کے لئے ایک معاون اصول بنانے کی کوشش کریں. اگر IP ایڈریس اکثر تبدیل ہوتا ہے لیکن اسی نیٹ ورک میں رہتا ہے، آپ اپنے
ignore.dat میں اس فہرست کو روکنے کے لئے ذمہ دار دستخط والے حصے کا نام درج کرنے کی کوشش کرسکتے ہیں.اگر آپ نے ان تمام آئیڈیوں کو آزمایا ہے اور ان میں سے کسی نے بھی آپ کے لئے کام نہیں کیا ہے، یا اگر آپ کو یہ جاننے میں مدد کی ضرورت ہو کہ اسے کیسے کریں، CIDRAM کے issues پیج پر ہم سے بات کریں.
دستاویزات کا یہ حصہ پیکج کے استعمال اور عمل کے بارے میں ممکنہ قانونی مفکوم بیان کرتا ہے، اور کچھ بنیادی متعلق معلومات فراہم کرتی ہے. بعض صارفین کے لئے شکایت کا یقین کرنے کے لئے یہ ممکن ہو سکتا ہے کہ وہ کسی بھی قانونی تقاضے کے ساتھ موجود ممالک میں موجود ہوسکتے ہیں جس میں وہ کام کرتے ہیں، اور کچھ صارفین اس کی معلومات کے مطابق اپنی ویب سائٹ کی پالیسیوں کو ایڈجسٹ کرنے کی ضرورت ہوسکتی ہے.
سب سے پہلے، سب سے اہم، یاد رکھیں کہ میں (پیکیج کا مصنف) ایک وکیل نہیں ہوں. لہذا، میں قانونی مشورہ فراہم کرنے کے لئے قانونی طور پر قابل نہیں ہوں. اس کے علاوہ، کچھ معاملات میں، قانونی ضروریات مختلف ممالک اور دائرہ کاروں کے درمیان مختلف ہوتی ہیں. یہ مختلف قانونی ضروریات کبھی کبھی متفق ہیں (مثلا، ایسے ممالک جو "رازداری کے حقوق" اور "بھول جانے کا حق"، ایسے ممالک کے مقابلے میں جو "ڈیٹا برقرار رکھنے" کا حق رکھتے ہیں). یہ بھی غور کریں کہ پیکیج تک رسائی مخصوص ممالک یا دائرہ کاروں سے محدود نہیں ہے, اور اس وجہ سے، پیکج کے صارفین جغرافیایی متنوع ہونے کا امکان رکھتے ہیں. ان پوائنٹس پر غور کیا گیا ہے، میں ایسی حیثیت میں نہیں ہوں جو یہ سب کے لئے "قانونی طور پر مطابق" ہونے کا مطلب ہے. تاہم، مجھے امید ہے کہ اس معلومات میں آپ کو یہ فیصلہ کرنے میں مدد ملتی ہے کہ پیکج کے تناظر میں قانونی طور پر مطابق رہنے کے لۓ آپ کو کیا کرنا ہوگا. اگر آپ کو کوئی شبہ ہے، یا اگر آپ کو قانونی نقطہ نظر سے اضافی مدد اور مشورہ کی ضرورت ہو تو، میں ایک قانونی پیشہ ورانہ مشاورت کی سفارش کروں گا.
پیکج کسی بھی وارنٹی کے ساتھ فراہم نہیں کی جاتی ہے (لائسنس پہلے ہی اس کا ذکر کرتا ہے). یہ ذمہ داری کے تمام مقاصد پر لاگو ہوتا ہے. پیکج آپ کی سہولت کے لئے فراہم کی جاتی ہے. امید ہے کہ یہ مفید ہو گا، اور یہ آپ کے لئے کچھ فائدہ فراہم کرے گا. تاہم، پیکج کا استعمال کرتے ہوئے یا لاگو آپ کا اپنا فیصلہ ہے. آپ اسے استعمال کرنے یا اسے لاگو کرنے پر مجبور نہیں ہوئے ہیں. جب آپ ایسا کرتے ہو تو، آپ اس فیصلے کے ذمہ دار ہیں. میں اور دوسرا پیکج شراکت دار، آپ کے فیصلوں کے نتائج کے لئے قانونی طور پر ذمہ دار نہیں ہے.
اس پیکیج پر منحصر ہے کہ کس طرح پیکج ترتیب اور لاگو ہوتا ہے، کچھ صورتو میں، یہ تیسری جماعتوں کے ساتھ معلومات کا اشتراک کرسکتا ہے. کچھ قواعد و ضوابط میں، کچھ دائرہ کار کی طرف سے، یہ "ذاتی طور پر شناختی معلومات" کے طور پر بیان کیا جا سکتا ہے.
تیسری جماعتوں کی طرف سے یہ معلومات کس طرح استعمال کی جاتی ہے، ان کی پالیسیوں کے تابع ہے، اور اس دستاویزات کے دائمے سے باہر ہے. تاہم، اس طرح کے معاملات میں، معلومات کا اشتراک معذور ہوسکتا ہے. اس طرح کے معاملات میں، اگر آپ اسے چالو کرنے کا انتخاب کرتے ہیں تو، یہ آپ کی ذمہ داری ہے کہ آپ کو ان خدشات کے بارے میں معلومات کی رازداری، سیکورٹی اور استعمال کے بارے میں کوئی خدشات کی تحقیقات کی جا سکتی ہے. اگر کوئی شبہ موجود ہے، یا اگر آپ ان تیسری جماعتوں کے انعقاد سے ناخوش ہیں تو، ان تیسری جماعتوں کے ساتھ معلومات کے تمام حصول کو غیر فعال کرنے میں یہ سب سے بہتر ہوسکتا ہے.
شفافیت کے مقصد کے لئے، مشترکہ معلومات کی قسم ذیل میں بیان کی گئی ہے.
اگر آپ میزبانوں کے ساتھ کام کرنے کے لئے کسی بھی خصوصیات یا ماڈیولز کا استعمال کرتے ہیں تو، CIDRAM انباؤنڈ درخواستوں کے میزبان نام حاصل کرنے کے قابل ہوسکتا ہے. عام طور پر، یہ ایک DNS سرور سے IP ایڈریس کے میزبان ناموں کی درخواست کرکے یہ کرتا ہے، یا براہ راست نظام کی طرف سے فراہم کی گئی فعالیت کے ذریعے معلومات کی درخواست کی طرف سے. Google DNS سروس پہلے سے طے شدہ طور پر مقرر کیا جاتا ہے (لیکن یہ ترتیب کے ذریعے آسانی سے تبدیل کیا جا سکتا ہے). مطابقت پذیر خدمات کے ساتھ مطابقت پذیری کی جا سکتی ہے، اور ان پر منحصر ہے کہ آپ کس طرح پیکج کو ترتیب دیں گے. نظام کے ذریعے براہ راست درخواست کرتے وقت، آپ کو اپنے نظام کے منتظم سے رابطہ کرنے کی ضرورت پڑے گی جس کا تعین کیا جاسکتا ہے. متاثر ماڈیولز سے بچنے یا اس کے مطابق پیکیج ترتیب میں ترمیم کرکے CIDRAM میں ہوسٹ نام کی تلاش کی جا سکتی ہے.
متعلقہ ترتیب ہدایات:
allow_gethostbyaddr_lookup<-generaldefault_dns<-generalforce_hostname_lookup<-generalother<-verificationsearch_engines<-verificationsocial_media<-verification
جب یہ اختیارات فعال ہوتے ہیں تو، CIDRAM کو تلاش کے انجن اور سوشل میڈیا کی درخواستوں کی صداقت کی توثیق کرنے کی کوشش ہوتی ہے. ایسا کرنے کے لئے، یہ ان پونڈ درخواستوں کے میزبانوں سے IP پتوں کو حل کرنے کی کوشش کرنے کیلئے Google DNS سروس کا استعمال کرتا ہے (اس عمل میں، ان بے حد درخواستوں کے میزبانوں کو سروس کے ساتھ اشتراک کیا جاتا ہے).
متعلقہ ترتیب ہدایات:
other<-verificationsearch_engines<-verificationsocial_media<-verification
reCAPTCHA اور hCAPTCHA پیکیج کے ذریعہ تعاون یافتہ ہیں. ان کو صحیح طریقے سے کام کرنے کیلئے API کیز کی ضرورت ہوتی ہے. وہ بطور ڈیفالٹ غیر فعال ہیں، لیکن مطلوبہ API چابیاں تشکیل دے کر ان کو فعال کیا جاسکتا ہے. جب فعال ہوجائے تو، خدمت اور CIDRAM یا صارف کے براؤزر کے مابین مواصلت ہوسکتی ہے. اس میں ممکنہ طور پر بات چیت کرنے والی معلومات شامل ہوسکتی ہے جیسے صارف کا آئی پی ایڈریس، صارف ایجنٹ، آپریٹنگ سسٹم، اور دیگر تفصیلات.
Stop Forum Spam ایک شاندار، آزادانہ طور پر دستیاب سروس ہے جو اسپیمرز سے فورمز، بلاگز، اور ویب سائٹس کی حفاظت کے لئے مدد کرسکتا ہے. یہ یہ معروف اسپیمرز کے ایک ڈیٹا بیس فراہم کر کے کرتا ہے، اور ایک API جو لیورڈج کیا جا سکتا ہے کہ یہ چیک کرنے کے لئے کہ آیا IP ایڈریس، صارف کا نام، یا ای میل ایڈریس اس کے ڈیٹا بیس پر درج کیا جاتا ہے.
CIDRAM ایک ماڈیول فراہم کرتا ہے جو اس API کو چیک کرنے کے لۓ لیتا ہے کہ آیا درخواستوں کا IP ایڈریس مشتبہ اسپیمر سے تعلق رکھتا ہے. جب ماڈیول انسٹال اور چالو ہوجاتا ہے، صارف IP پتے کو خدمت کے ساتھ اشتراک کیا جا سکتا ہے، ماڈیول کی ترتیب اور مطلوبہ مقصد کے مطابق.
AbuseIPDB API کا استعمال کرتے ہوئے بدسلوکی IP پتے کو بلاک کرنے کے لئے CIDRAM ایک اختیاری ماڈیول فراہم کرتا ہے. جب ماڈیول انسٹال اور چالو ہوجاتا ہے، صارف IP پتے کو خدمت کے ساتھ اشتراک کیا جا سکتا ہے، ماڈیول کی ترتیب اور مطلوبہ مقصد کے مطابق.
BGPView API اور IP-API API کا استعمال کرتے ہوئے ASN اور ملکی کوڈ تلاش کرنے کیلئے CIDRAM لیے اختیاری ماڈیول فراہم کرتا ہے. یہ تلاشیں اپنے ASN یا ملک کے اصل کی بنیاد پر درخواستوں کو مسدود کرنے یا وائٹ لسٹ کرنے کی اہلیت فراہم کرتی ہیں. جب ماڈیول انسٹال اور چالو ہوجاتا ہے، صارف IP پتے کو خدمت کے ساتھ اشتراک کیا جا سکتا ہے، ماڈیول کی ترتیب اور مطلوبہ مقصد کے مطابق.
Project Honeypot API کا استعمال کرتے ہوئے بدسلوکی IP پتے کو بلاک کرنے کے لئے CIDRAM ایک اختیاری ماڈیول فراہم کرتا ہے. جب ماڈیول انسٹال اور چالو ہوجاتا ہے، صارف IP پتے کو خدمت کے ساتھ اشتراک کیا جا سکتا ہے، ماڈیول کی ترتیب اور مطلوبہ مقصد کے مطابق.
لاگنگ کئی وجوہات کے لئے CIDRAM کا ایک اہم حصہ ہے. اس کے بغیر، غلطیوں کو تلاش کرنے اور مسائل کی تشخیص مشکل ہوسکتی ہے. اگر ہمارے پاس یہ معلومات نہیں ہے اور کسی چیز کو تبدیل کرنے کی ضرورت ہے، یہ جاننا مشکل ہوسکتا ہے کہ بالکل وہی چیز جو تبدیل کرنے کی ضرورت ہے. اس کے باوجود، ہر کوئی اس معلومات کو ریکارڈ نہیں کرنا چاہتا، لہذا یہ اختیاری رہتا ہے. CIDRAM میں، یہ ڈیفالٹ کی طرف سے معذور ہے. اسے فعال کرنے کے لئے، CIDRAM کے مطابق ترتیب دیا جانا چاہئے.
یہ یاد رکھنا چاہیے کہ لاگنگ کے لئے عین مطابق قانونی ضروریات دائرہ کاروں کے درمیان مختلف ہو سکتی ہیں. عملدرآمد کا تناظر بھی متعلقہ ہو سکتا ہے (مثال کے طور پر، ایک فرد کے طور پر، ایک کارپوریٹ ادارے کے طور پر، تجارتی بنیاد پر، غیر تجارتی بنیاد پر، وغیرہ). اس کی وجہ سے، یہاں کی معلومات آپ کے لئے مفید ہوسکتی ہے.
بہت سے مختلف قسم کی معلومات درج کی جا سکتی ہیں، مختلف وجوہات کے لئے.
لاگ کا بنیادی قسم جس میں CIDRAM انجام دیتا ہے "بلاک کے واقعات" سے متعلق ہے. اس سے متعلق ہے کہ جب CIDRAM کسی درخواست کو روکتا ہے، اور تین مختلف فارمیٹس میں فراہم کی جاسکتی ہے:
- لاگ جو انسان کی طرف سے پڑھ سکتے ہیں.
- Apache سٹائل لاگ.
- سیریلائزڈ لاگ.
جب ریکارڈ کیا جاتا ہے تو لوگ پڑھ سکتے ہیں، ایک بلاک ایونٹ عام طور پر اس طرح لگ رہا ہے (ایک مثال کے طور):
ID: 1234
اسکرپٹ ورژن: CIDRAM v1.6.0
تاریخ وقت: Day, dd Mon 20xx hh:ii:ss +0000
IP پتہ: x.x.x.x
میزبان کا نام: dns.hostname.tld
دستخط شمار: 1
دستخط حوالہ: x.x.x.x/xx
کیوں بلاک شدہ: کلاؤڈ سروس ("نیٹ ورک کا نام", Lxx:Fx, [XX])!
صارف ایجنٹ: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36
دوبارہ تعمیر URI: https://your-site.tld/index.php
CAPTCHA کے ریاست: فعال کردہ.وہی چیز، جو اپاچی کے انداز میں درج ہوئی ہے، اس کی طرح لگتا ہے:
x.x.x.x - - [Day, dd Mon 20xx hh:ii:ss +0000] "GET /index.php HTTP/1.1" 200 xxxx "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36"ریکارڈ شدہ تقریب عام طور پر اس معلومات میں شامل ہے:
- ایونٹ کے لئے ایک ID نمبر.
- CIDRAM کا ورژن فی الحال استعمال کیا جاتا ہے.
- واقعہ پیش کی تاریخ اور وقت.
- درخواست سے IP ایڈریس.
- درخواست کے میزبان نام (جب دستیاب ہو).
- دستخط کی تعداد متاثر.
- ان دستخط کے بارے میں مزید تفصیلات.
- ایونٹ اور متعلقہ معلومات کی وجوہات.
- درخواست کے لئے "صارف ایجنٹ".
- درخواست کردہ وسائل کے لئے شناخت.
- درخواست کے لئے CAPTCHA کی حیثیت (جب متعلقہ).
متعلقہ ترتیب ہدایات:
apache_style_log<-loggingserialised_log<-loggingstandard_log<-logging
جب یہ ہدایات خالی رہیں تو، اس قسم کی ریکارڈنگ غیر فعال رہیں گے.
جب ایک صارف CAPTCHA مثال کے طور پر مکمل کرنے کی کوشش کرتا ہے، تو ریکارڈ کیا جاتا ہے.
ان ریکارڈوں میں صارف کے IP ایڈریس، تاریخ اور اس وقت کا واقعہ شامل ہے، اور حیثیت. یہ ریکارڈ عام طور پر اس طرح نظر آتے ہیں:
IP پتہ: x.x.x.x - تاریخ وقت: Day, dd Mon 20xx hh:ii:ss +0000 - CAPTCHA کے ریاست: ایوان کے پاس!متعلقہ ترتیب ہدایات:
hcaptcha_log<-hcaptcharecaptcha_log<-recaptcha
یہ سامنے کے آخر میں لاگ ان کرنے کی کوشش کرنے سے متعلق ہے. جب سامنے کے آخر میں رسائی کو فعال کیا جاتا ہے، جب صارف کو سامنے کے آخر میں لاگ ان کرنے کی کوشش ہوتی ہے، تو ریکارڈ کیا جاتا ہے.
اس ریکارڈ میں صارف کے IP ایڈریس، تاریخ اور وقت اور اس کے نتائج شامل ہیں (کامیاب یا ناکامی). یہ عام طور پر اس طرح کچھ نظر آتا ہے:
x.x.x.x - Day, dd Mon 20xx hh:ii:ss +0000 - "admin" - لاگ ان.متعلقہ ترتیب ہدایات:
frontend_log<-frontend
آپ چاہتے ہیں، یا قانونی طور پر ہو سکتا ہے، کچھ وقت کے بعد لاگ ان کو صاف کرنے کے لئے (کتنی دیر تک آپ لاگ ان کو برقرار رکھ سکتے ہیں قانون کی طرف سے محدود ہوسکتے ہیں). یہ لاگ ان کے مطابق لاگ ان کی ترتیب میں تاریخ/وقت مارکر مقرر کرنے کی طرف سے کیا جا سکتا ہے (مثال کے طور پر،
{yyyy}-{mm}-{dd}.log)، اور پھر لاگ گرد گھومنے کو چالو کرنے (لاگ گرد کی گردش آپ کو لاگ ان کی حد سے زیادہ حد تک زیادہ سے زیادہ لاگ ان پر لاگو کرنے کی اجازت دیتا ہے).مثال کے طور پر: اگر مجھے 30 دنوں کے بعد لاگز کو خارج کرنے کی ضرورت ہوتی ہے تو میں
{dd}.log اپنے لاگ ان کے نام میں ڈال سکتا ہوں ({dd} دن کی نمائندگی کرتا ہے)، log_rotation_limit کو 30 مقرر کریں، اور log_rotation_action کو Delete مقرر کریں.اگر آپ کو کچھ وقت کے لئے ریکارڈ رکھنے کی ضرورت ہے تو، آپ کو لاگ گرد گھومنے کا استعمال نہ کرنے کا انتخاب کرسکتے ہیں، یا آپ
log_rotation_action کی قدر Archive پر مقرر کر سکتے ہیں (اس ریکارڈ کو کمپیکٹ کریں گے، اس طرح ڈسک کے استعمال کو کم کرنا ہوگا).متعلقہ ترتیب ہدایات:
log_rotation_action<-logginglog_rotation_limit<-logging
اگر آپ چاہتے ہیں تو، آپ انفرادی ریکارڈز کو چھوٹ سکتے ہیں جب وہ مخصوص سائز سے کہیں زیادہ ہیں.
متعلقہ ترتیب ہدایات:
truncate<-logging
سب سے پہلے، اگر آپ اصطلاح سے واقف نہیں ہیں، "pseudonymisation" ذاتی اعداد و شمار کی پروسیسنگ سے مراد اس طرح سے ہے کہ یہ کسی بھی مخصوص شخص کو بغیر کسی ضمنی معلومات کی نشاندہی نہیں کی جاسکتی ہے، فراہم کی جاتی ہے کہ اس طرح کی اضافی معلومات علیحدہ طریقے سے برقرار رکھی جاتی ہے اور تکنیکی اور تنظیمی تدابیر کے تابع ہوتے ہیں اس بات کو یقینی بنانے کے لئے کہ ذاتی ڈیٹا کسی قدرتی شخص کو نشاندہی نہیں کی جاسکتی ہے.
مندرجہ ذیل وسائل اس سے مزید تفصیل میں وضاحت کرنے میں مدد کرسکتے ہیں:
کچھ حالات میں، آپ کو کسی بھی PII جمع، عملدرآمد، یا ذخیرہ کرنے کے لئے "anonymisation" یا "pseudonymisation" کو لاگو کرنا قانونی طور پر ضروری ہوسکتا ہے. یہ تصور ابھی کچھ وقت تک وجود میں آیا ہے، لیکن GDPR/DSGVO خاص طور پر "pseudonymisation" کا ذکر اور حوصلہ افزائی کرتا ہے.
اگر آپ چاہتے ہیں تو، CIDRAM لاگ ان کرتے وقت لاگ ان کرتے وقت IP پتے کے لئے یہ کر سکتے ہیں. جب لکھنا لکھنا، IPv4 پتے کے آخری آکٹیٹ اور IPv6 پتے کے دوسرے حصے کے بعد سب کچھ، "x" کی طرف سے نمائندگی کی جائے گی.
نوٹ: CIDRAM کی IP ٹریکنگ کی خصوصیت اس کی صلاحیت نہیں ہے. اگر یہ آپ کے لئے ایک مسئلہ ہے، IP ٹریکنگ کو مکمل طور پر غیر فعال کرنے کیلئے یہ سب سے بہتر ہو سکتا ہے.
متعلقہ ترتیب ہدایات:
pseudonymise_ip_addresses<-legal
اگر آپ مخصوص قسم کی معلومات کو مکمل طور پر لاگ ان کرنے سے روکنا چاہتے ہیں تو، آپ ایسا کرسکتے ہیں. کنفیگریشن پیج پر، براہ کرم
fields کنفیگریشن ڈائریکٹیو سے رجوع کریں تاکہ یہ کنٹرول کیا جا سکے کہ کون سے فیلڈز لاگ انٹریز میں ظاہر ہوتے ہیں اور "رسائی نہیں ہوئی" صفحہ پر.
نوٹ: IP پتے کے لئے pseudonymisation کا استعمال کرنے کی کوئی وجہ نہیں ہے جب IP پتے کو مکمل طور پر لاگ ان سے لے کر.
متعلقہ ترتیب ہدایات:
fields<-general
CIDRAM اعداد و شمار کو ٹریک کر سکتے ہیں، جیسے کہ کسی مخصوص وقت سے کتنے بلاک واقعات یا CAPTCHA مثال موجود ہیں. یہ خصوصیت ڈیفالٹ کے ذریعہ غیر فعال ہے، لیکن پیکیج کی ترتیب کے ذریعے فعال کیا جا سکتا ہے. یہ خصوصیت صرف واقعات کی تعداد کو ٹریک کرتا ہے. اس میں کوئی مخصوص معلومات شامل نہیں ہے، لہذا اسے PII کے طور پر نہیں جانا چاہئے.
متعلقہ ترتیب ہدایات:
statistics<-general
CIDRAM اس کے لاگ ان یا کیش کو خفیہ نہیں کرتا. یہ مستقبل میں متعارف کرایا جا سکتا ہے، لیکن فی الحال اس کی کوئی مخصوص منصوبہ نہیں ہے. اگر آپ غیر قانونی شدہ تیسری جماعتوں کے بارے میں فکر مند ہیں تو CIDRAM میں حساس معلومات تک رسائی حاصل ہے، میں سفارش کرتا ہوں کہ عام طور پر قابل رسائی مقام پر CIDRAM انسٹال نہیں کیا جائے گا (مثال کے طور پر،
public_html میں انسٹال نہ کریں) اور اس بات کو یقینی بنائیں کہ مناسب حد تک محدود پابندیوں کو نافذ کیا جائے. اگر یہ آپ کے خدشات کو حل کرنے کے لئے کافی نہیں ہے تو پھر CIDRAM کو ترتیب دیں تاکہ حساس معلومات جمع نہیں کی جائے گی (جیسے جیسے، لاگ ان کو غیر فعال کرکے).CIDRAM کو دو مقامات پر کوکیز کا تعین کرتا ہے. سب سے پہلے، CAPTCHA مکمل کرنے کے بعد "CIDRAM" کوکیز سیٹ کرتا ہے (اگر
lockuser کو true میں مقرر کیا جاتا ہے تو)، لہذا یہ ہر درخواست پر ایسا کرنے کے لئے صارف سے پوچھنا جاری رکھنے کی ضرورت نہیں ہوگی. دوسرا، صارف کو سامنے کے آخر میں لاگ ان ہونے پر CIDRAM ایک کوکی سیٹ کرتا ہے (تصدیق کے مقاصد کے لئے).دونوں صورتوں میں، صارف کو پہلے سے ہی کوکیز کے بارے میں خبردار کیا جاتا ہے. کوکیز کہیں اور نہیں بنائے جاتے ہیں.
نوٹ: "پوشیدہ" CAPTCHA APIs کو کچھ علاقوں میں کوکی قوانین سے مطابقت نہیں ہوسکتی ہے اور ایسے قوانین کے تابع کسی بھی ویب سائٹ سے ان کو پرہیز کرنا چاہئے. اس کے بجائے دوسرے فراہم کردہ API استعمال کرنے کا انتخاب کرنا، یا صرف مکمل طور پر CAPTCHA کو غیر فعال کرنا بہتر ہوگا.
متعلقہ ترتیب ہدایات:
lockuser<-recaptchaapi<-recaptchalockuser<-hcaptchaapi<-hcaptcha
CIDRAM مارکیٹنگ یا اشتہارات کے مقاصد کے لئے کسی بھی معلومات جمع یا عمل نہیں کرتا ہے. یہ کسی جمع کردہ یا لاگ ان معلومات سے کوئی فائدہ نہیں فروخت کرتا ہے. CIDRAM ایک تجارتی ادارہ نہیں ہے، اور کسی بھی تجارتی مفادات سے متعلق نہیں ہے، لہذا ان کاموں کو کوئی احساس نہیں ہوگا. اس منصوبے کی شروعات کے بعد یہ معاملہ رہا ہے، اور آج ہی مقدمہ جاری ہے.
بعض اوقات آپ کو قانون کی طرف سے آپ کی ویب سائٹ پر اپنی جگہ پر اپنی رازداری کی پالیسی پر ایک لنک ظاہر کرنے کی ضرورت ہوسکتی ہے. اس بات کو یقینی بنانے کیلئے صارفین کو آپ کی رازداری کے طریقوں کے بارے میں مطلع کیا جاسکتا ہے، جو آپ جمع کرتے ہیں، اور آپ اس معلومات کے ساتھ کیا کرتے ہیں. CIDRAM کے "رسائی نہیں ہوئی" کے صفحے پر اس لنک کو شامل کرنے کے قابل ہونے کے لۓ، آپ کی رازداری کی پالیسی کے ایڈریس کی وضاحت کرنے کے لئے ایک ترتیب کا اختیار فراہم کیا جاتا ہے.
نوٹ: یہ سختی سے سفارش کی جاتی ہے کہ آپ کی رازداری کی پالیسی کا صفحہ CIDRAM کی حفاظت کے پیچھے نہیں ہے. اگر CIDRAM آپ کی پرائیویسی پالیسی کی حفاظت کرتا ہے تو، جب وہ آپ کی رازداری کی پالیسی پر لنک پر کلک کریں تو صارفین کو مسدود کیا جائے گا. مثالی طور پر، آپ کو اپنی رازداری کی پالیسی کی ایک مستحکم کاپی، جیسے HTML صفحہ یا سادہ متن فائل سے منسلک ہونا چاہئے.
متعلقہ ترتیب ہدایات:
privacy_policy<-legal
GDPR یورپی یونین کا ایک ضابطہ ہے جو 25 مئی، 2018 تک اثر انداز ہوتا ہے. ریگولیشن کا بنیادی مقصد یہ ہے کہ یورپی یونین کے شہریوں اور باشندوں کو ان کے اپنے ذاتی ڈیٹا سے متعلق قابو پانے، اور پرائیویٹ اور ذاتی ڈیٹا کے بارے میں یورپی یونین کے اندر ریگولیشن کو متحد کرنا.
ریگولیشن کسی بھی EU کے "اعداد و شمار کے مضامین" (کسی بھی شناخت یا شناختی قدرتی شخص) کے "ذاتی طور پر شناختی معلومات" کی پروسیسنگ سے متعلق مخصوص اجزاء پر مشتمل ہے. تعمیل کرنے کے لئے، کمپنیوں، عمل، اور متعلقہ نظام، "ڈیزائن کی طرف سے رازداری" کو لاگو کرنا لازمی ہے، سب سے زیادہ ممکن راز رازداری کی ترتیبات کا استعمال کرنا ضروری ہے، کسی ذخیرہ یا پروسیسنگ معلومات کے لئے حفاظتی انتظامات کو لاگو کرنا ضروری ہے (بشمول، لیکن تک محدود نہیں، "pseudonymisation" اور "anonymisation")، واضح طور پر ان اعداد و شمار کی اقسام کا اعلان کرنا چاہیے جو وہ جمع کرتے ہیں، وہ کس طرح کے سببوں کے لئے، اس کے عمل کو کس طرح، وہ کتنی عرصے تک اسے برقرار رکھتی ہیں، اور اگر وہ اس ڈیٹا کو کسی بھی تیسری پارٹی کے ساتھ شریک کریں، اعداد و شمار کی اقسام، کیسے، کیوں، اور اسی طرح کی اقسام.
اعداد و شمار پر عملدرآمد نہیں کیا جاسکتا جب تک کہ ایسا کرنے کے لئے قانونی بنیاد نہ ہو، قواعد و ضوابط کے مطابق. عام طور پر، اس کا مطلب یہ ہے کہ یہ قانونی ذمہ داریوں کے مطابق ہونا ضروری ہے، اور صرف واضح ہونے کے بعد، اچھی طرح سے مطلع رضامندی کے اعداد و شمار سے حاصل کی گئی ہے.
وقت میں، قوانین تبدیل کر سکتے ہیں. لہذا، پرانے معلومات کو پھیلانے سے بچنے کے لۓ، یہ مستند ذریعہ سے سیکھنا بہتر ہوگا. اگر میں براہ راست یہاں معلومات شامل ہوں تو، یہ تاریخ سے باہر ہوسکتا ہے.
مزید معلومات سیکھنے کے لئے کچھ سفارش کردہ وسائل:
v3 اور پچھلے بڑے ورژن کے درمیان اہم فرق ہیں. جس طرح سے انٹری پوائنٹس کام کرتے ہیں، جس طرح سے ماڈیولز کی ساخت ہوتی ہے، اور جس طرح سے اپڈیٹر v3 کے لیے کام کرتا ہے وہ اس طرح سے مختلف ہے جس طرح ان چیزوں نے پچھلے بڑے ورژنز کے لیے کام کیا. ان اختلافات کی وجہ سے، پچھلے بڑے ورژنز سے v3 میں اپ گریڈ کرنے کا بہترین طریقہ یہ ہوگا کہ ایک تازہ انسٹالیشن انجام دی جائے.
اگر آپ اپنی ترتیب اور اپنے معاون قواعد کو برقرار رکھنا چاہتے ہیں، اپ گریڈ کا عمل شروع کرنے سے پہلے، فرنٹ اینڈ بیک اپ پیج پر جائیں. وہاں سے، ترتیب اور معاون قواعد برآمد کیے جا سکتے ہیں. برآمد کرنے سے فائل ڈاؤن لوڈ ہو جائے گی. نئے بڑے ورژن میں اپ گریڈ کرنے کے بعد، اس فائل کو پہلے سے برآمد شدہ ڈیٹا کو انسٹالیشن میں درآمد کرنے کے لیے استعمال کیا جا سکتا ہے.
ماڈیولز کی ساخت میں تبدیلیوں کی وجہ سے، پچھلے بڑے ورژنز کے لیے بنائے گئے ماڈیولز کو v3 کے لیے صحیح طریقے سے کام کرنے کے لیے دوبارہ لکھنے کی ضرورت ہوگی. براہ راست منتقلی کام نہیں کرے گی. واقعات کا بھی یہی حال ہے.
دستخطی فائلوں کے ڈھانچے کا طریقہ تبدیل نہیں ہوا ہے، اس لیے دستخطی فائلیں جو پچھلے بڑے ورژن کے لیے ہیں، بغیر کسی پریشانی کے براہ راست v3 میں منتقل کی جا سکتی ہیں.
ماڈیولز، دستخطی فائلیں، اور ایونٹس میں سے ہر ایک کی اپنی مخصوص ڈائریکٹریز ہوتی ہیں، جو کہ v3 کے بعد ایک نیا اضافہ ہے (لہذا، v3 کے لیے، وہ ہر ایک vault کی جڑ کے بجائے اپنی اپنی مخصوص ڈائریکٹریوں میں جائیں گے).
پچھلے بڑے ورژنز کے لیے عوامی طور پر دستیاب دستخطی فائلوں، ماڈیولز، اور بلاک لسٹوں میں سے کچھ کو فرسودہ کر دیا گیا ہے، اس لیے ہر چیز v3 کے لیے دستیاب نہیں ہوگی. زیادہ تر معاملات میں، v3 کے بعد سے شامل کردہ نئی خصوصیات اور بنیادی فعالیت کی وجہ سے، بہرحال ان کی ضرورت نہیں ہوگی.
معاون قوانین کے ڈھانچے کے طریقے میں کچھ ٹھیک ٹھیک تبدیلیاں ہیں، اور ترتیب میں تبدیلیاں ہیں، لیکن اگر آپ فرنٹ اینڈ بیک اپ صفحہ پر درآمد/برآمد خصوصیت استعمال کرتے ہیں، تو آپ کو دستی طور پر کچھ کرنے کی ضرورت نہیں ہوگی. درآمد کرتے وقت، CIDRAM جانتا ہے کہ کس چیز کی ضرورت ہے، اور اسے آپ کے لیے خود بخود سنبھال لے گا.
v4 ابھی تک موجود نہیں ہے. تاہم، جب v3 سے v4 میں اپ گریڈ کرنے کا وقت آتا ہے، تو اپ گریڈ کا عمل بہت آسان ہونا چاہیے. ہم نہیں جان سکیں گے کہ وقت آنے تک یہ کتنا نمایاں طور پر مختلف ہو گا، لیکن میں توقع کرتا ہوں کہ اختلافات پہلے کے مقابلے بہت کم ہوں گے، اور اپ گریڈ کے عمل کو آسان بنانے کے لیے میکانزم کو شروع سے ہی v3 میں لاگو کر دیا گیا ہے. جب تک اپڈیٹر میں اہم تبدیلیاں نہیں ہوتی ہیں یا انٹری پوائنٹس کے کام کرنے کے طریقے میں، نظریہ طور پر، اسے مکمل طور پر فرنٹ اینڈ کے ذریعے اپ گریڈ کرنا ممکن ہونا چاہیے، بغیر کسی نئی تنصیب کی ضرورت کے.
مزید تفصیلی معلومات مستقبل میں کسی مناسب وقت پر، دستاویزات میں، یہاں شامل کی جائیں گی.
آخری تازہ کاری: ۹ جنوری ۲۰۲۵ (۲۰۲۵.۰۱.۰۹).