سیکشن 1.

June 5, 2026 · View on GitHub

CIDRAM v4 لیے دستاویزی (اردو).

فہرست:

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 سے ملنے کے لیے کی کوشش کر کے اس کرتا ہے ناپسندیدہ ٹریفک کے)؛ موازنہ نہیں ملا رہے ہیں تو، درخواستوں مسدود ہیں.

CIDRAM کاپی رائٹ 2016 اور Caleb M (Maikuolan) کی طرف GNU/GPLv2 اجازت سے آگے.

یہ سکرپٹ مفت سافٹ ویئر ہے. آپ اسے دوبارہ تقسیم اور / یا ترمیم کے طور پر مفت سافٹ ویئر فاؤنڈیشن کی جانب سے شائع GNU جنرل پبلک لائسنس کی شرائط کے تحت اس پر نظر ثانی کر سکتے ہیں؛ یا تو لائسنس کے ورژن 2، یا (آپ کے اختیارات پر) کسی بھی جدید ورژن. یہ سکرپٹ یہ مفید ہو جائے گا، لیکن کسی بھی وارنٹی کے بغیر امید میں تقسیم کیا جاتا ہے؛ کسی خاص مقصد کے لیے قابل فروختگی یا فٹنس کی بھی تقاضا وارنٹی کے بغیر. مزید تفصیلات کے لیے GNU جنرل پبلک لائسنس، "LICENSE.txt" فائل اور سے بھی دستیاب میں واقع دیکھیں:
CIDRAM یہاں سے آزادانہ طور پر ڈاؤن لوڈ کیا جا سکتا ہے:
یہ دستاویز اور اس کے مختلف تراجم یہاں مل سکتے ہیں:

۲. انسٹال کرنے کا طریقہ

۲.۰ دستی طور پر نصب

سب سے پہلے، آپ کو 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" کے طریقہ کار کو کال کرنا.

ایک سادہ مثال:

<?php
require_once '/path/to/the/vault/directory/loader.php';
(new \CIDRAM\CIDRAM\Core())->protect();
اگر آپ Apache ویب سرور استعمال کر رہے ہیں اور آپ کو php.ini تک رسائی حاصل ہے، تو آپ جب بھی PHP کی کوئی درخواست کی جاتی ہے تو آپ CIDRAM کو آگے بڑھانے کے لیے X ہدایت کا استعمال کر سکتے ہیں، جب بھی PHP کی درخواست کی جاتی ہے تو آپ 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 کے ساتھ نصب

CIDRAM Packagist ساتھ رجسٹرڈ ہے، اور اسی طرح، آپ کمپوزر سے واقف ہیں تو، آپ.

composer require cidram/cidram

۲.۲ ورڈپریس کے لیے نصب

CIDRAM ورڈپریس پلگ ان کے ڈیٹا بیس کے ساتھ ایک پلگ ان کے طور پر رجسٹرڈ ہے، اور آپ کو پلگ ان ڈیش بورڈ سے براہ راست CIDRAM انسٹال کر سکتے ہیں. آپ کسی بھی دیگر پلگ ان کے طور پر اسی انداز میں اسے انسٹال کر سکتے ہیں، اور کوئی اس کے علاوہ اقدامات کی ضرورت ہے.

انتباہ: ایک صاف تنصیب میں پلگ ان ڈیش بورڈ کے نتائج کے ذریعے CIDRAM تازہ کاری ہو رہی! آپ کو آپ کی تنصیب کے اپنی مرضی کے مطابق کیا ہے تو (اپنی کنفگریشن بدل گیا، نصب ماڈیولز، وغیرہ)، ان کی تخصیصات پلگ ان ڈیش بورڈ کے ذریعے اپ ڈیٹ کر جب ختم ہو جائے گا! لاگ مسلیں بھی ختم ہو جائے گا! لاگ فائلوں اور اصلاح کے تحفظ کے لیے، CIDRAM سامنے کے آخر میں اپ ڈیٹس صفحے کے ذریعے اپ ڈیٹ کریں.

۲.۳ کنفگریشن اور حسب ضرورت

آپ کے لیے سختی سے تجویز کی جاتی ہے کہ آپ اپنی نئی تنصیب کی کنفگریشن کا جائزہ لیں تاکہ آپ اسے اپنی ضروریات کے مطابق ایڈجسٹ کر سکیں. آپ اضافی ماڈیولز، دستخطی فائلیں انسٹال کرنا، معاون اصول بنانا، یا دیگر تخصیصات کو نافذ کرنا چاہیں گے تاکہ آپ کی تنصیب آپ کی ضروریات کے مطابق ہو سکے. میں ان چیزوں کو کرنے کے لیے فرنٹ اینڈ کو استعمال کرنے کی تجویز کرتا ہوں.


۳. کس طرح استعمال

CIDRAM خود کار طریقے سے آپ کی ویب سائٹ کو ناپسندیدہ درخواستوں کسی بھی دستی امداد کی ضرورت کے بغیر، ایک طرف اس کی ابتدائی تنصیب سے مسدود کرنا چاہیے.

آپ کو آپ کی کنفگریشن اپنی مرضی کے مطابق اور اپنی مرضی کے مطابق جس CIDR آپ کی کنفیگریشن فائل اور/یا آپ کے دستخط کی فائلوں میں تبدیلی کرنے کی طرف سے بلاک کر رہے ہیں کر سکتے ہیں.

CIDRAM دستی طور پر یا سامنے کے اختتام کے ذریعے اپ ڈیٹ کیا جا سکتا ہے. CIDRAM بھی Composer یا WordPress کے ذریعہ اپ ڈیٹ کیا جا سکتا ہے، اگر اصل میں ان کے ذریعہ نصب ہوجائے.


۴. سامنے کے آخر میں انتظام

۴.۰ سامنے کے آخر کیا ہے.

سامنے کے آخر میں، برقرار رکھنے کا انتظام، اور آپ CIDRAM تنصیب کو اپ ڈیٹ کرنے کے لیے ایک آسان اور آسان طریقہ فراہم کرتا ہے. آپ صرف مسودہ دیکھ سکتے ہیں، اشتراک، اور نوشتہ صفحے کے ذریعے لاگ مسلیں لوڈ، آپ کی کنفگریشن کے صفحے کے ذریعے کی کنفگریشن تبدیل کر سکتے ہیں، آپ کو انسٹال کر سکتے ہیں اور اپ ڈیٹس صفحے کے ذریعے انسٹال اجزاء، اور آپ کو اپ لوڈ کر سکتے ہیں، ڈاؤن لوڈ، اتارنا، اور فائل کے ذریعے آپ کے vault میں فائلوں پر نظر ثانی مینیجر.

۴.۱ فرنٹ اینڈ تک کیسے رسائی حاصل کی جائے.

بالکل پہلے کی طرح، آپ کو فرنٹ اینڈ تک رسائی حاصل کرنے کے لیے ایک انٹری پوائنٹ بنانے کی ضرورت ہوگی. اس طرح کا داخلی نقطہ تین چیزوں پر مشتمل ہے:

۱. آپ کے کوڈ بیس یا CMS پر کہیں "loader.php" فائل کو شامل کرنا.
۲. 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

2FA کو چالو کرنے کے ذریعہ front-end کو مزید محفوظ بنانے کے لیے ممکن ہے. جب 2FA کے ساتھ اکاؤنٹ میں لاگ ان ہو تو، اس اکاؤنٹ سے منسلک ای میل پتہ پر ایک ای میل بھیجا جاتا ہے. اس ای میل میں "2FA کوڈ" شامل ہے، جو اس صارف کا استعمال کرتے ہوئے لاگ ان کرنے کے لۓ صارف کا نام اور پاسورڈ کے علاوہ صارف کو داخل ہونا ضروری ہے. اس کا مطلب یہ ہے کہ اکاؤنٹ اکاؤنٹ پاس ورڈ حاصل کرنے کے لیے کسی بھی ہیکر یا ممکنہ حملہ آور کو اس اکاؤنٹ میں لاگ ان کرنے کے قابل نہیں ہو گا، کیونکہ انہیں وصول کرنے کے قابل ہونے کے لیے ان اکاؤنٹ سے منسلک ای میل پتہ تک رسائی حاصل ہوگی. اور سیشن کے ساتھ منسلک 2FA کوڈ استعمال کریں.

سب سے پہلے، 2FA کو چالو کرنے کے لیے، PHPMailer اجزاء کو انسٹال کرنے کے لیے front-end اپ ڈیٹس کا صفحہ استعمال کریں. ای میل بھیجنے کے لیے CIDRAM PHPMailer کا استعمال کرتا ہے.

PHPMailer نصب کرنے کے بعد، آپ کو CIDRAM کنفگریشن کے صفحے یا کنفگریشن کی فائل کے ذریعے PHPMailer کے لیے کنفگریشن ہدایات کو آباد کرنے کی ضرورت ہوگی. ان کنفگریشنات کے ہدایات کے بارے میں مزید معلومات اس دستاویز کے کنفگریشن کے حصے میں شامل ہیں. PHPMailer کنفگریشن ہدایات آبادی کے بعد، enable_two_factor true سیٹ کریں. 2FA اب فعال ہونا چاہیے.

اگلا، آپ کو ایک ای میل پتہ کو اکاؤنٹ کے ساتھ منسلک کرنے کی ضرورت ہوگی، تاکہ CIDRAM کو معلوم ہے کہ اس اکاؤنٹ کے ساتھ لاگ ان کرتے وقت 2FA کوڈ بھیجنے کے لیے. ایسا کرنے کے لیے، اکاؤنٹ کے صارف نام کے طور پر ای میل پتہ استعمال کریں (کچھ foo@bar.tld کی طرح)، یا اس صارف کے صارف کے حصے کے طور پر ای میل پتہ بھی شامل ہے جس طرح آپ عام طور پر ای میل بھیجیں گے (کچھ Foo Bar <foo@bar.tld> کی طرح).

نوٹ: غیر مجاز رسائی کے خلاف vault کی حفاظت خاص طور پر اہم ہے (مثال کے طور پر، آپ کے سرور کی سیکیورٹی کو مضبوط کرنا، عوامی رسائی کی اجازت محدود)، کیونکہ غیر مجاز رسائی آپ کے SMTP کنفگریشنات کو بے نقاب کر سکتا ہے (اس میں SMTP صارف کا نام اور پاس ورڈ بھی شامل ہے). آپ کو اس بات کو یقینی بنانا چاہیے کہ 2FA کو چالو کرنے سے پہلے vault مناسب طریقے سے محفوظ ہو. اگر آپ ایسا کرنے میں قاصر ہیں تو، کم سے کم، آپ کو ایک نیا ای میل اکاؤنٹ بنانا چاہیے، اس مقصد کے لیے وقف کردہ SMTP کنفگریشنات کے خطرات کو کم کرنے کے لیے.


۵. کنفگریشن کے اختیارات

ندرجہ ذیل ان ہدایات کے مقصد کی وضاحت کے ساتھ ساتھ، "config.yml" کنفگریشن فائل میں CIDRAM کو دستیاب ہدایات کی ایک فہرست ہے.

کنفگریشن (v4)

├───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]
│       default_dns [string]
│       default_algo [string]
│       statistics [string]
│       statistics_captchas [string]
│       force_hostname_lookup [bool]
│       allow_gethostbyaddr_lookup [bool]
│       disabled_channels [string]
│       request_proxy [string]
│       request_proxyauth [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]
│       theme_mode [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]
├───captcha
│       usemode [int]
│       nonblocked_status_code [int]
│       api [string]
│       messages [string]
│       lockto [string]
│       hcaptcha_sitekey [string]
│       hcaptcha_secret [string]
│       friendly_sitekey [string]
│       friendly_apikey [string]
│       turnstile_sitekey [string]
│       turnstile_secret [string]
│       expiry [float]
│       signature_limit [int]
│       log [string]
├───legal
│       pseudonymise_ip_addresses [bool]
│       privacy_policy [string]
├───template_data
│       theme [string]
│       theme_mode [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]

"general" (قسم)

عام کنفگریشنات (کنفیگریشن جس کا تعلق دوسری قسموں سے نہیں ہے).

"stages" [string]
  • عمل درآمد کے مراحل کے لیے کنٹرول (فعال کرنے کے اقدامات، غلطی لاگنگ، وغیرہ).
stages───[اس مرحلے کو فعال کریں؟]─[اس مرحلے کے دوران پیدا ہونے والی کسی غلطی کو لاگ کریں؟]─[IP ٹریکنگ کی طرف اس مرحلے کے دوران پیدا ہونے والی خلاف ورزیوں کو شمار کریں؟]
├─BanCheck ("چیک کریں کہ آیا پابندی لگائی گئی ہے")
├─Tests ("دستخطی فائلوں کے ٹیسٹ پر عمل کریں")
├─Modules ("ماڈیولز پر عمل کریں")
├─SearchEngineVerification ("سرچ انجن کی تصدیق پر عمل کریں")
├─SocialMediaVerification ("سوشل میڈیا کی تصدیق پر عمل کریں")
├─OtherVerification ("دوسری توثیق پر عمل کریں")
├─Aux ("معاون قوانین پر عمل کریں")
├─Tracking ("IP ٹریکنگ پر عمل کریں")
├─RL ("ریٹ محدود کرنے پر عمل کریں")
├─CAPTCHA ("CAPTCHA تعینات کریں (بلاک شدہ درخواستیں)")
├─Reporting ("رپورٹنگ پر عمل کریں")
├─Statistics ("اعداد و شمار کو اپ ڈیٹ کریں")
├─Webhooks ("ویب ہکس پر عمل کریں")
├─TriggerNotifications ("ای میل ٹرگر اطلاع کی قطار پر کارروائی کریں")
├─PrepareFields ("آؤٹ پٹ اور لاگز کے لیے فیلڈز تیار کریں")
├─Output ("آؤٹ پٹ پیدا کریں (بلاک شدہ درخواستیں)")
├─WriteLogs ("لاگ فائلوں میں لکھیں (بلاک شدہ درخواستیں)")
├─Terminate ("درخواست کو ختم کریں (بلاک شدہ درخواستیں)")
├─AuxRedirect ("معاون قوانین کے مطابق ری ڈائریکٹ کریں")
└─NonBlockedCAPTCHA ("CAPTCHA تعینات کریں (غیر مسدود درخواستیں)")
"fields" [string]
  • بلاک ہونے پر فیلڈز کے لیے کنٹرول (جب کوئی درخواست بلاک ہو جاتی ہے).
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. اگرچہ کلائنٹ کے اشارے فنگر پرنٹنگ کے لیے کارآمد ثابت ہو سکتے ہیں، کیونکہ وہ وسیع پیمانے پر تعاون یافتہ نہیں ہیں، لیکن درخواستوں میں ان کی موجودگی کو فرض نہیں کیا جانا چاہیے اور نہ ہی ان پر انحصار کیا جانا چاہیے (یعنی، ان کی غیر موجودگی کی بنیاد پر بلاک کرنا ایک برا خیال ہے).

"timezone" [string]
  • استعمال کرنے کے لیے ٹائم زون کی وضاحت کرتا ہے (جیسے، Africa/Cairo، America/New_York، Asia/Tokyo، Australia/Perth، Europe/Berlin، Pacific/Guam، وغیرہ). SYSTEM کی وضاحت کریں تاکہ PHP کو آپ کے لیے خود بخود یہ سنبھل سکے.
timezone
├─SYSTEM ("نظام کو پہلے سے طے شدہ ٹائم زون کا استعمال کریں.")
├─UTC ("UTC")
└─…دیگر
"time_offset" [int]
  • ٹائم زون منٹ میں آفسیٹ.
"time_format" [string]
  • 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.

"ipaddr" [string]
  • کہاں درخواستوں منسلک کرنے کے 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_response_header_code" [int]
  • درخواستوں کو روکنے پر بھیجنے کے لیے 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 (سروس میسر نہیں)): سب سے زیادہ مضبوط، لیکن کم از کم صارف دوست.
  حملے کے دوران، یا انتہائی مسلسل ناپسندیدہ
  ٹریفک سے نمٹنے کے لیے تجویز کردہ.

۱. جب "سائلنٹ موڈ" نافذ ہوتا ہے، تو silent_mode_response_header_code⬅general کے ذریعے بیان کردہ HTTP حیثیت کا پیغام استعمال کیا جائے گا (یہ سب سے زیادہ ترجیح ہے).

۲. جب درخواست بھیجنے والے پر خلاف ورزی کی حد سے تجاوز کرنے کی وجہ سے پابندی لگا دی گئی ہے، تو "پابندی" کے لیے HTTP حیثیت کا پیغام استعمال کیا جائے گا.

۳. جب شرح کو محدود کرنے کی وجہ سے بلاک کیا جائے گا، 429 استعمال کیا جائے گا، یا جب وسائل کے تنازعات کی وجہ سے بلاک کیا جائے گا، تو conflict_response⬅signatures کے ذریعے بیان کردہ HTTP حیثیت کا پیغام استعمال کیا جائے گا (اس تناظر میں شرح محدود اور وسائل کے تنازعات کو یکساں ترجیح حاصل ہے).

۴. جب "HTTP حیثیت کا کوڈ اوور رائڈ" سیٹ کرنے والے معاون اصول کی وجہ سے بلاک کیا جاتا ہے، تو وہ HTTP حیثیت کا کوڈ اوور رائڈ استعمال کیا جائے گا.

۵. جب قانونی وجوہات کی وجہ سے مسدود کیا جاتا ہے (یعنی، جب کسی حسب ضرورت دستخط کی وجہ سے مسدود کیا جاتا ہے جس میں "قانونی" شارٹ ہینڈ لفظ استعمال ہوتا ہے)، تو "قانونی" کے لیے HTTP حیثیت کا پیغام استعمال کیا جائے گا.

۶. دیگر تمام مسدود درخواستوں کے لیے، "پہلے سے طے شدہ" کے لیے HTTP حیثیت کا پیغام استعمال کیا جائے گا (یہ سب سے کم ترجیح ہے).

"silent_mode" [string]
  • خاموشی CIDRAM چاہیے "رسائی مسترد کر دی" کے صفحے کی نمائش سے بلاک رسائی کی کوششوں کو ری ڈائریکٹ کرنے کے بجائے؟ ہاں تو، کو بلاک کر تک رسائی کی کوششوں کو ری ڈائریکٹ کرنے کے محل وقوع کی وضاحت. کوئی تو اس متغیر خالی چھوڑ.
"silent_mode_response_header_code" [int]
  • بلاک شدہ رسائی کی کوششوں کو خاموشی سے ری ڈائریکٹ کرتے وقت CIDRAM کو کون سا HTTP حیثیت کا پیغام بھیجنا چاہیے؟
silent_mode_response_header_code
├─301 (301 Moved Permanently (مستقل طور پر منتقل ہو گیا)): کلائنٹ کو ہدایت کرتا ہے کہ ری ڈائریکٹ
│ مستقل ہے، اور یہ کہ ری ڈائریکٹ کے لیے
│ استعمال ہونے والا کا طریقہ ابتدائی
│ درخواست کے لیے استعمال کیے جانے والے
│ درخواست کے طریقہ سے مختلف ہو سکتا ہے.
├─302 (302 Found (ملا)): کلائنٹ کو ہدایت کرتا ہے کہ ری ڈائریکٹ
│ عارضی ہے، اور یہ کہ ری ڈائریکٹ کے لیے
│ استعمال ہونے والا درخواست کا طریقہ
│ ابتدائی درخواست کے لیے استعمال کیے جانے
│ والے درخواست کے طریقہ سے مختلف ہو سکتا ہے.
├─307 (307 Temporary Redirect (عارضی ری ڈائریکٹ)): کلائنٹ کو ہدایت کرتا ہے کہ ری ڈائریکٹ
│ عارضی ہے، اور یہ کہ ری ڈائریکٹ کے لیے
│ استعمال ہونے والا درخواست کا طریقہ
│ ابتدائی درخواست کے لیے استعمال کیے جانے
│ والے درخواست کے طریقہ سے مختلف نہیں ہو
│ سکتا.
└─308 (308 Permanent Redirect (مستقل ری ڈائریکٹ)): کلائنٹ کو ہدایت کرتا ہے کہ ری ڈائریکٹ
  مستقل ہے، اور یہ کہ ری ڈائریکٹ کے لیے
  استعمال ہونے والا درخواست کا طریقہ
  ابتدائی درخواست کے لیے استعمال کیے جانے
  والے درخواست کے طریقہ سے مختلف نہیں ہو
  سکتا.

اس بات سے کوئی فرق نہیں پڑتا ہے کہ ہم کلائنٹ کو کیسے ہدایت دیتے ہیں، یہ یاد رکھنا ضروری ہے کہ آخر کار ہمارا اس پر کوئی کنٹرول نہیں ہے کہ کلائنٹ کیا کرنا چاہتا ہے، اور اس بات کی کوئی ضمانت نہیں ہے کہ کلائنٹ ہماری ہدایات کا احترام کرے گا.

"lang" [string]
  • 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 (FR)")
├─fr-CA ("Français (CA)")
├─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 ("中文(傳統)")
"lang_override" [bool]
  • جب بھی ممکن ہو HTTP_ACCEPT_LANGUAGE کے مطابق لوکلائز کریں؟ True (سچے) = جی ہاں [پہلے سے طے شدہ]؛ False (جھوٹی) = نہیں.
"numbers" [string]
  • آپ کس طرح تعداد میں ظاہر کرنے کے لیے پسند کرتے ہیں؟ مثال کے طور پر منتخب کریں جو آپ کے لیے سب سے زیادہ درست نظر آتے ہیں.
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 ("1234567.89")
├─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" [string]
  • اگر آپ چاہتے ہیں، تو آپ صارفین کو جب انہیں بلاک کر رہے ہیں تو دینے کے لیے ای میل پتہ کی فراہمی کر سکتے ہیں.وہ اسے استعمال آپ سے رابطہ کرنے کے لیے کر سکتے ہیں اگر وہ غلطی سے بلاک کر رہے ہیں. انتباہ: آپ جو بھی ای میل پتہ پر فراہمی کرتے ہیں، وہ یقینی طور پر سپےمبٹس اور کھرچنی کی طرف سے حاصل کیے جائیں گے. اس کی وجہ سے، اس کی سختی سے سفارش کی جاتی ہے کہ آپ ایک ای میل پتہ انتخاب کرتے ہیں جو ڈسپوزایبل یا غیر اہم ہے (یعنی.، آپ کی ذاتی یا کاروباری ای میل پتہ کا استعمال نہ کریں).
"emailaddr_display_style" [string]
  • آپ کو ای میل پتہ کو کس طرح صارفین کو پیش کرنا پسند ہے؟
emailaddr_display_style
├─default ("کلک کرنے والے لنک")
└─noclick ("متن جو کلک نہیں کیا جا سکتا")
"default_dns" [string]
  • میزبان نام تلاش کرنے کے لیے استعمال کرنے کے لیے DNS سرورز کی فہرست. انتباہ: جب تک کہ آپ کو پتہ ہے تم کیا کر رہے ہو اس کو تبدیل نہ کریں!

FAQ. میں "default_dns" کے لیے کیا استعمال کر سکتا ہوں؟

"default_algo" [string]
  • اس بات کی وضاحت کرتا ہے جو تمام مستقبل کے پاس ورڈ اور سیشن کے لیے الگورتھم استعمال کرنا ہے.
default_algo
├─PASSWORD_DEFAULT ("PASSWORD_DEFAULT")
├─PASSWORD_BCRYPT ("PASSWORD_BCRYPT")
├─PASSWORD_ARGON2I ("PASSWORD_ARGON2I")
└─PASSWORD_ARGON2ID ("PASSWORD_ARGON2ID (PHP >= 7.3.0)")
"statistics" [string]
  • کنٹرول کرتا ہے کہ کون سی شماریاتی معلومات کو ٹریک کرنا ہے.
statistics───[IPv4]─[IPv6]─[دیگر]
├─Blocked ("درخواستوں پر بلاک کر دی گئی")
├─Banned ("درخواستوں پر پابندی لگا دی گئی")
├─Passed ("درخواستیں گزر گئیں")
├─ReportOK ("درخواستوں کی اطلاع بیرونی API کو دی گئی – ٹھیک ہے")
└─ReportFailed ("درخواستوں کی اطلاع بیرونی API کو دی گئی – ناکامی")

نوٹ: معاون قواعد کے اعداد و شمار کو ٹریک کرنا ہے یا نہیں، معاون قواعد کے صفحہ سے کنٹرول کیا جا سکتا ہے.

"statistics_captchas" [string]
  • کنٹرول کرتا ہے کہ CAPTCHA کے لیے کون سی شماریاتی معلومات کو ٹریک کرنا ہے.
statistics_captchas───[ناکامی]─[کامیابی]─[خدمت کی]
├─HCaptcha ("hCaptcha")
├─FriendlyCaptcha ("Friendly Captcha")
└─CloudflareTurnstile ("Cloudflare Turnstile")

نوٹ: معاون قواعد کے اعداد و شمار کو ٹریک کرنا ہے یا نہیں، معاون قواعد کے صفحہ سے کنٹرول کیا جا سکتا ہے.

"force_hostname_lookup" [bool]
  • تمام درخواستوں کے لیے میزبانی حاصل کریں؟ True (سچے) = جی ہاں؛ False (جھوٹی) = نہیں [پہلے سے طے شدہ]. میزبان نام کی تلاش عام طور پر "ضرورت کی بنیاد" کی بنیاد پر انجام دیا جاتا ہے، لیکن تمام درخواستوں کے لیے مجبور کیا جاسکتا ہے. ایسا کرتے ہوئے لاگ ان میں مزید تفصیلی معلومات فراہم کرنے کے ذریعہ مفید ثابت ہوسکتا ہے، لیکن کارکردگی پر تھوڑا منفی اثر بھی ہوسکتا ہے.
"allow_gethostbyaddr_lookup" [bool]
  • جب UDP دستیاب نہیں ہے تو gethostbyaddr کی تلاش کی اجازت دیں؟ True (سچے) = جی ہاں [پہلے سے طے شدہ]؛ False (جھوٹی) = نہیں.

نوٹ: ہو سکتا ہے IPv6 تلاش کچھ 32 بٹ سسٹمز پر صحیح طریقے سے کام نہ کرے.

"disabled_channels" [string]
  • درخواستوں کو بھیجنے کے لیے خاص طور پر چینلز کا استعمال کے لیے CIDRAM کو روکنے کے لیے یہ استعمال کیا جا سکتا ہے (مثال کے طور پر، جب اپ ڈیٹ کرنا، اجزاء میٹا ڈیٹا، وغیرہ کو پکڑنے کے بعد).
disabled_channels
├─GitHub ("<span class="origin bgHRdBl">US</span> GitHub")
├─BitBucket ("<span class="origin bgHRdBl">US</span> BitBucket")
├─Codeberg ("<span class="origin bgVBkRd fgYlw">DE</span> Codeberg")
└─GoogleDNS ("<span class="origin bgHRdBl">US</span> GoogleDNS")
"request_proxy" [string]
  • اگر آپ چاہتے ہیں کہ باہر جانے والی درخواستیں کسی پراکسی کے ذریعے بھیجی جائیں، تو اس پراکسی کو یہاں بیان کریں. اگر نہیں، تو اسے خالی چھوڑ دیں.
"request_proxyauth" [string]
  • اگر پراکسی کے ذریعے آؤٹ باؤنڈ درخواستیں بھیج رہے ہیں اور اگر اس پراکسی کو صارف نام اور پاس ورڈ کی ضرورت ہے، تو وہ صارف نام اور پاس ورڈ یہاں بتائیں (مثال کے طور پر، user:pass). اگر نہیں، تو اسے خالی چھوڑ دیں.
"default_timeout" [int]
  • بیرونی درخواستوں کے لیے استعمال کرنے کے لیے پہلے سے طے شدہ ٹائم آؤٹ؟ پہلے سے طے شدہ = 12 سیکنڈ.
"sensitive" [string]
  • حساس صفحات کے طور پر شمار کرنے کے لیے راستوں کی فہرست. فہرست میں شامل ہر راستے کو ضرورت پڑنے پر دوبارہ تعمیر شدہ URI کے خلاف چیک کیا جائے گا. ایک راستہ جو فارورڈ سلیش سے شروع ہوتا ہے اسے لغوی سمجھا جائے گا، اور درخواست کے پاتھ جزو سے مماثل ہوگا. ایک راستہ جو ایک غیر حروفِ عددی کریکٹر سے شروع ہوتا ہے، اور اسی کریکٹر (یا وہی کریکٹر کے علاوہ ایک اختیاری "i" جھنڈا) پر ختم ہوتا ہے اسے ریگولر ایکسپریشن سمجھا جائے گا. کسی دوسرے قسم کے راستے کو لفظی سمجھا جائے گا، اور URI کے کسی بھی حصے سے مماثل ہو سکتا ہے. ایک پاتھ کو حساس صفحہ کے طور پر سمجھا جا سکتا ہے کچھ ماڈیولز کے برتاؤ کو متاثر کر سکتا ہے، لیکن اس کا کوئی دوسرا اثر نہیں ہوتا ہے.
"email_notification_address" [string]
  • اگر آپ نے CIDRAM سے ای میل کے ذریعے اطلاعات موصول کرنے کا انتخاب کیا ہے، مثال کے طور پر، جب مخصوص معاون قوانین کو متحرک کیا جاتا ہے، آپ ان اطلاعات کے لیے وصول کنندہ کا پتہ یہاں بتا سکتے ہیں.
"email_notification_name" [string]
  • اگر آپ نے CIDRAM سے ای میل کے ذریعے اطلاعات موصول کرنے کا انتخاب کیا ہے، مثال کے طور پر، جب مخصوص معاون قوانین کو متحرک کیا جاتا ہے، آپ ان اطلاعات کے لیے وصول کنندہ کا نام یہاں بتا سکتے ہیں.
"email_notification_when" [string]
  • جنریٹ ہونے کے بعد اطلاعات کب بھیجیں.
email_notification_when
├─Immediately ("فوراً.")
├─After24Hours ("24 گھنٹوں کے بعد، ایک ساتھ بنڈل (یا جب دستی طور پر ٹرگر کیا جاتا ہے، جیسے، cron کے ذریعے).")
└─ManuallyOnly ("صرف اس وقت جب دستی طور پر ٹرگر کیا جائے (جیسے، cron کے ذریعے).")

"components" (قسم)

CIDRAM کی طرف سے استعمال ہونے والے اجزاء کو چالو کرنے اور غیر فعال کرنے کے لیے کنفگریشن. عام طور پر اپ ڈیٹس صفحہ کے ذریعے آباد ہوتا ہے، لیکن بہتر کنٹرول کے لیے اور اپ ڈیٹس صفحہ کے ذریعے پہچانے جانے والے حسب ضرورت اجزاء کے لیے بھی یہاں سے منظم کیا جا سکتا ہے.

"ipv4" [string]
  • IPv4 دستخطی فائلیں.
"ipv6" [string]
  • IPv6 دستخطی فائلیں.
"modules" [string]
  • ماڈیولز.
"imports" [string]
  • درآمدات. عام طور پر CIDRAM کو جزو کی کنفگریشن کی معلومات فراہم کرنے کے لیے استعمال کیا جاتا ہے.
"events" [string]
  • ایونٹ ہینڈلرز. عام طور پر استعمال کیا جاتا ہے جس طرح سے CIDRAM اندرونی طور پر برتاؤ کرتا ہے یا اضافی فعالیت فراہم کرتا ہے.

"logging" (قسم)

لاگنگ سے متعلق کنفیگریشن (اس کو چھوڑ کر جو دیگر زمروں پر لاگو ہوتا ہے).

"standard_log" [string]
  • تمام بلاک کر تک رسائی کی کوششوں کو لاگ ان کرنے کے لیے انسانی قابل مطالعہ فائل. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.

مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز time_format⬅general پر دکھائے جاتے ہیں.

"apache_style_log" [string]
  • تمام بلاک کر تک رسائی کی کوششوں کو لاگ ان کرنے کے لیے اپاچی طرز فائل. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.

مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز time_format⬅general پر دکھائے جاتے ہیں.

"serialised_log" [string]
  • تمام بلاک کر تک رسائی کی کوششوں کو لاگ ان کرنے کے لیے serialized کی فائل. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.

مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز time_format⬅general پر دکھائے جاتے ہیں.

"error_log" [string]
  • کسی بھی غیر مہلک غلطیوں کو لاگ کرنے کے لیے ایک فائل کا پتہ چلا. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.

مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز time_format⬅general پر دکھائے جاتے ہیں.

"outbound_request_log" [string]
  • کسی بھی آؤٹ باؤنڈ درخواستوں کے نتائج کو لاگ ان کرنے کے لیے ایک فائل. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.

مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز time_format⬅general پر دکھائے جاتے ہیں.

"report_log" [string]
  • بیرونی API کو بھیجی گئی کسی بھی رپورٹ کو لاگ ان کرنے کے لیے ایک فائل. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.

مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز time_format⬅general پر دکھائے جاتے ہیں.

"truncate" [string]
  • وہ ایک خاص سائز تک پہنچنے میں جب صاف لاگ مسلیں؟ ویلیو میں B/KB/MB/GB/TB زیادہ سے زیادہ سائز ہے. جب 0KB، وہ غیر معینہ مدت تک ترقی کر سکتا ہے (پہلے سے طے). نوٹ: واحد فائلوں پر لاگو ہوتا ہے! فائلیں اجتماعی غور نہیں کر رہے ہیں.
"log_rotation_limit" [int]
  • لاگ گرد گردش کسی بھی وقت کسی بھی وقت موجود ہونا لاگ ان کی تعداد محدود کرتا ہے. جب نیا لاگ ان کی تخلیق کی جاتی ہے تو، اگر لاگ ان کی کل تعداد مخصوص حد سے زیادہ ہوتی ہے تو مخصوص کارروائی کی جائے گی. آپ یہاں مطلوبہ حد کی وضاحت کرسکتے ہیں. 0 کی قیمت لاگ گرد گردش کو غیر فعال کرے گی.
"log_rotation_action" [string]
  • لاگ گرد گردش کسی بھی وقت کسی بھی وقت موجود ہونا لاگ ان کی تعداد محدود کرتا ہے. جب نیا لاگ ان کی تخلیق کی جاتی ہے تو، اگر لاگ ان کی کل تعداد مخصوص حد سے زیادہ ہوتی ہے تو مخصوص کارروائی کی جائے گی. آپ یہاں مطلوبہ کارروائی کی وضاحت کرسکتے ہیں.
log_rotation_action
├─Delete ("قدیم ترین لاگ ان کو حذف کریں، جب تک کہ حد تک زیادہ نہیں ہوسکتی ہے.")
└─Archive ("سب سے پہلے آرکائیو، اور پھر سب سے پرانی لاگ ان کو حذف کریں، جب تک کہ حد زیادہ نہیں ہوسکتی.")
"log_banned_ips" [bool]
  • لاگ فائلوں پر پابندی لگا دی گئی IP پتوں سے مسدود درخواستیں شامل کریں؟ True (سچے) = جی ہاں [پہلے سے طے شدہ]؛ False (جھوٹی) = نہیں.
"log_sanitisation" [bool]
  • لاگز ڈیٹا دیکھنے کے لیے سامنے کے آخر لاگز صفحے کے کا استعمال کرتے وقت کب، XSS حملوں سے صارفین کی حفاظت کے لیے، یہ نمائش سے پہلے نظر ثانی شدہ ہے. لیکن، ہم ایسا نہیں کرتے جب سب سے پہلے اسے ریکارڈ کرنا پڑتا ہے. اگر یہ مستقبل میں اس کا تجزیہ کرنے کی ضرورت ہے تو اس سے مدد مل سکتی ہے. لیکن خارجہ قارئین کا استعمال کرتے وقت یہ کبھی کبھی غیر محفوظ ہوسکتا ہے. اگر ضرورت ہو تو آپ رویے کو تبدیل کرسکتے ہیں. True (سچے) = کم درست، لیکن کم خطرہ. False (جھوٹی) = زیادہ درست، لیکن زیادہ خطرہ [پہلے سے طے شدہ].

"frontend" (قسم)

فرنٹ اینڈ کے لیے کنفیگریشن.

"frontend_log" [string]
  • سامنے کے آخر میں لاگ ان کوششوں لاگنگ کے لیے دائر. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.

مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز time_format⬅general پر دکھائے جاتے ہیں.

"signatures_update_event_log" [string]
  • جب دستخطوں کو اپ ڈیٹ پیج کے ذریعہ اپ ڈیٹ کیا جاتا ہے تو ریکارڈ کرنے کے لیے ایک فائل. ایک فائل کا نام کی وضاحت کریں، یا غیر فعال کرنے کو خالی چھوڑ.

مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز time_format⬅general پر دکھائے جاتے ہیں.

"max_login_attempts" [int]
  • لاگ ان کوششوں کی زیادہ سے زیادہ تعداد (سامنے کے آخر میں). پہلے سے طے شدہ = 5.
"theme" [string]
  • فرنٹ اینڈ کے لیے استعمال کرنے والی تھیم.
theme
├─default ("Default")
├─bluemetal ("Blue Metal")
├─fullmoon ("Full Moon")
├─moss ("Moss")
├─primer ("Primer")
├─primerdark ("Primer Dark")
├─rbi ("Red-Blue Inverted")
├─slate ("Slate")
└─…دیگر
"theme_mode" [string]
  • فرنٹ اینڈ کے لیے استعمال کرنے والی تھیم کے لیے موڈ.
theme_mode
├─normal ("نارمل")
└─inverted ("الٹا")
"magnification" [float]
  • فونٹ اضافہ. پہلے سے طے شدہ = 1.
"custom_header" [string]
  • تمام فرنٹ اینڈ پیجز کے شروع میں HTML کے بطور داخل کیا گیا. اگر آپ ویب سائٹ کا لوگو، پرسنلائزڈ ہیڈر، اسکرپٹس، وغیرہ شامل کرنا چاہتے ہیں، تو یہ مفید ہو سکتا ہے.
  • تمام فرنٹ اینڈ پیجز کے آخر میں HTML کے بطور داخل کیا گیا. اگر آپ قانونی نوٹس، رابطہ لنک، کاروباری معلومات، وغیرہ شامل کرنا چاہتے ہیں، تو یہ مفید ہو سکتا ہے.
"remotes" [string]
  • اجزاء کے میٹا ڈیٹا کو حاصل کرنے کے لیے اپڈیٹر کے ذریعے استعمال کیے گئے پتوں کی فہرست. نئے بڑے ورژن میں اپ گریڈ کرتے وقت، یا اپ ڈیٹس کے لیے نیا ذریعہ حاصل کرتے وقت اسے ایڈجسٹ کرنے کی ضرورت پڑ سکتی ہے، لیکن عام حالات میں اسے تنہا چھوڑ دیا جانا چاہیے.
"enable_two_factor" [bool]
  • یہ تعین کرتا ہے کہ 2FA استعمال کیا جانا چاہیے.

"signatures" (قسم)

دستخطوں، دستخط فائلوں، ماڈیولز، وغیرہ کے لیے تشکیل.

"shorthand" [string]
  • یہ کنٹرول کرتا ہے کہ جب کسی دستخط کے خلاف مثبت مماثلت ہو جس میں دیے گئے شارٹ ہینڈ الفاظ کا استعمال ہوتا ہے تو درخواست کے ساتھ کیا کرنا ہے.
shorthand───[اسے بلاک کریں.]─[اسے پروفائل کریں.]─[بلاک ہونے پر، آؤٹ پٹ ٹیمپلیٹ کا استعمال نہ کریں.]
├─Attacks ("حملے")
├─Bogon ("⁰ بوگون IP")
├─Cloud ("کلاؤڈ سروس")
├─Generic ("جنرک")
├─Legal ("¹ قانونی")
├─Malware ("میلویئر")
├─Proxy ("² پراکسی")
├─Spam ("سپیم")
├─Banned ("³ پابندی")
├─BadIP ("³ غلط IP")
├─RL ("³ ریٹ محدود")
├─Conflict ("³ تنازع")
└─Other ("⁴ دیگر")

0. اگر آپ کی ویب سائٹ کو LAN یا localhost کے ذریعے رسائی کی ضرورت ہے، اسے مسدود نہ کریں. اگر ضرورت نہ ہو تو آپ اسے بلاک کر سکتے ہیں.

1. معیاری دستخطی فائلیں اسے استعمال نہیں کرتی ہیں، لیکن یہ اس صورت میں تعاون یافتہ ہے کہ یہ کچھ صارفین کے لیے کارآمد ہو سکتا ہے.

2. اگر آپ کے صارفین کو پراکسی کے ذریعے آپ کی ویب سائٹ تک رسائی حاصل کرنے کی ضرورت ہے، اسے مسدود نہ کریں. اگر ضرورت نہ ہو تو آپ اسے بلاک کر سکتے ہیں.

3. دستخطوں کے اندر براہ راست استعمال کی حمایت نہیں کی جاتی ہے، لیکن خاص حالات میں اسے دوسرے ذرائع سے استعمال کیا جا سکتا ہے.

4. ایسے معاملات کا حوالہ دیتے ہیں جہاں شارٹ ہینڈ الفاظ بالکل استعمال نہیں ہوتے ہیں، یا CIDRAM کے ذریعہ پہچانے نہیں جاتے ہیں.

ایک فی دستخط. ایک دستخط متعدد پروفائلز کی درخواست کر سکتا ہے، لیکن صرف ایک مختصر لفظ استعمال کر سکتا ہے. یہ ممکن ہے کہ ایک سے زیادہ شارٹ ہینڈ الفاظ موزوں ہوں، لیکن چونکہ صرف ایک ہی استعمال کیا جا سکتا ہے، ہم کوشش کرتے ہیں کہ ہمیشہ صرف سب سے موزوں الفاظ استعمال کریں.

ترجیح. ایک منتخب کردہ آپشن ہمیشہ غیر منتخب کردہ آپشن پر ترجیح لیتا ہے. مثال کے طور پر، اگر ایک سے زیادہ شارٹ ہینڈ الفاظ چل رہے ہیں لیکن ان میں سے صرف ایک کو بلاک کیے جانے کے طور پر سیٹ کیا گیا ہے، تب بھی درخواست کو بلاک کر دیا جائے گا.

ہیومن اینڈ پوائنٹس اور کلاؤڈ سروسز. "کلاؤڈ سروس" ویب ہوسٹنگ فراہم کنندگان، سرور فارمز، ڈیٹا سینٹرز، یا بہت سی دوسری چیزوں کا حوالہ دے سکتی ہے. "ہیومن اینڈ پوائنٹ" سے مراد وہ ذرائع ہیں جن کے ذریعے انسان انٹرنیٹ تک رسائی حاصل کرتا ہے، جیسے کہ انٹرنیٹ سروس فراہم کرنے والے کے ذریعے. نیٹ ورک عام طور پر صرف ایک یا دوسرا فراہم کرتا ہے، لیکن بعض اوقات دونوں فراہم کر سکتا ہے. ہم کوشش کرتے ہیں کہ کبھی بھی ممکنہ انسانی اینڈ پوائنٹ کو کلاؤڈ سروسز کے طور پر شناخت نہ کریں. لہذا، ایک کلاؤڈ سروس کی شناخت کسی اور چیز کے طور پر کی جا سکتی ہے اگر اس کی حد معلوم انسانی اختتامی نقطوں کے ذریعے مشترکہ ہو. اسی طرح، جب کسی بھی معلوم انسانی اینڈ پوائنٹس کے ذریعے رینجز کا اشتراک نہیں کیا جاتا ہے، تو ہم ہمیشہ کلاؤڈ سروسز کے بطور کلاؤڈ سروسز کی شناخت کرنے کی کوشش کرتے ہیں. لہذا، کلاؤڈ سروس کے طور پر شناخت کی گئی درخواست شاید معلوم انسانی اختتامی مقامات کے ساتھ حدود کا اشتراک نہیں کرتی ہے. حملوں یا سپیم کے خطرے سے شناخت شدہ درخواستوں کا معاملہ اس کے برعکس ہے. تاہم، انٹرنیٹ ہمیشہ بہاؤ میں رہتا ہے، نیٹ ورکس کے مقاصد وقت کے ساتھ بدلتے رہتے ہیں، اور رینجز ہمیشہ خریدی یا فروخت ہوتی رہتی ہیں، لہذا غلط مثبتات کے حوالے سے چوکس رہیں.

"default_tracktime" [string]
  • وہ دورانیہ جس کے لیے IP پتوں کو ٹریک کیا جانا چاہیے. پہلے سے طے شدہ = 7d0°0′0″ (1 ہفتہ).
"infraction_limit" [int]
  • خلاف ورزی کی زیادہ سے زیادہ تعداد ایک IP اس سے پہلے کیا جاتا ہے IP باخبر رہنے کے کی طرف سے پابندی کا اطلاق کرنے کی اجازت ہے. پہلے سے طے شدہ = 10.
"tracking_override" [bool]
  • ماڈیولوں کو ٹریکنگ کے اختیارات کو اوور رائڈ کرنے کی اجازت دیں؟ True (سچے) = جی ہاں [پہلے سے طے شدہ]؛ False (جھوٹی) = نہیں.
"conflict_response" [int]
  • جب ایک ہی وسائل تک رسائی کے لیے بیک وقت بہت ساری کوششیں ہوتی ہیں (مثال کے طور پر، ایک ہی مشین پر ایک ہی وسائل کے لیے متعدد PHP پروسیسز کے لیے بیک وقت درخواستیں)، ان میں سے کچھ کوششیں ناکام ہو سکتی ہیں. نایاب اور غیر امکانی صورت میں کہ یہ دستخطی فائلوں یا ماڈیولز کو متاثر کرتا ہے، CIDRAM کو درخواست کے بارے میں موثر فیصلہ کرنے سے روکا جا سکتا ہے. اگر ایسا ہوتا ہے، کیا درخواست کو بلاک کر دینا چاہیے، اور CIDRAM کو کون سا HTTP حیثیت کا پیغام بھیجنا چاہیے؟
conflict_response
├─0 (درخواست کو مسدود نہ کریں.): اگر آپ ترجیح دیتے ہیں کہ درخواستوں کو صرف
│ اس صورت میں مسدود کیا جائے جب آپ کو یقین ہو
│ کہ وہ خراب ہیں، یا غلط مثبتات کے سلسلے میں
│ محتاط رہنے کے لیے (کبھی کبھار غیر مطلوبہ
│ ٹریفک کے گزرنے کے خطرے میں)، یہ منتخب کریں.
│ اگر آپ ترجیح دیتے ہیں کہ درخواستوں کو
│ مسدود کر دیا جائے اگر آپ کو یقین نہیں ہے کہ
│ وہ بے نظیر ہیں، یا چوکس رہنے کے لیے (کبھی
│ کبھار جھوٹے مثبت ہونے کے خطرے میں)، دوسرے
│ دستیاب اختیارات میں سے ایک کا انتخاب کریں.
├─409 (409 Conflict (تنازع)): وسائل کے تنازعات کے لیے تجویز کردہ (مثلاً،
│ ضم تنازعات، فائل تک رسائی کے تنازعات،
│ وغیرہ). دوسرے سیاق و سباق میں سفارش نہیں کی
│ جاتی ہے.
└─429 (429 Too Many Requests (بہت ساری درخواستیں)): شرح کو محدود کرنے، DDoS حملوں سے نمٹنے، اور
  سیلاب سے بچاؤ کے لیے تجویز کردہ. دوسرے
  سیاق و سباق میں سفارش نہیں کی جاتی ہے.

"verification" (قسم)

اس بات کی تصدیق کے لیے کنفیگریشن کہ درخواستیں کہاں سے آتی ہیں.

"search_engines" [string]
  • سرچ انجنوں سے درخواستوں کی تصدیق کے لیے کنٹرولز.
search_engines───[تصدیق کرنے کی کوشش کریں؟]─[منفی کو مسدود کریں؟]─[غیر تصدیق شدہ درخواستوں کو مسدود کریں؟]─[سنگل ہٹ بائی پاسز کی اجازت دیں؟]─[مثبت سے باخبر رہنا بند کرو؟]
├─Amazonbot ("Amazonbot")
├─Applebot ("Applebot")
├─Baidu ("* Baiduspider/百度")
├─Bingbot ("* Bingbot")
├─DuckDuckBot ("* DuckDuckBot")
├─Googlebot ("* Googlebot")
├─MojeekBot ("MojeekBot")
├─PetalBot ("* PetalBot")
├─Qwantify ("Qwantify/Bleriot")
├─SeznamBot ("SeznamBot")
├─Sogou ("* Sogou/搜狗")
├─Yahoo ("Yahoo/Slurp")
├─Yandex ("* Yandex/Яндекс")
└─YoudaoBot ("YoudaoBot")

"مثبت" اور "منفی" کیا ہیں؟ درخواست کے ذریعے پیش کردہ شناخت کی تصدیق کرتے وقت، ایک کامیاب نتیجہ کو "مثبت" یا "منفی" کے طور پر بیان کیا جا سکتا ہے. جب پیش کی گئی شناخت کے حقیقی شناخت ہونے کی تصدیق ہو جاتی ہے، تو اسے "مثبت" کے طور پر بیان کیا جائے گا. جب پیش کردہ شناخت کے جھوٹے ہونے کی تصدیق ہو جاتی ہے، تو اسے "منفی" کے طور پر بیان کیا جائے گا. تاہم، ایک ناکام نتیجہ (مثال کے طور پر، تصدیق ناکام ہو جاتی ہے، یا پیش کردہ شناخت کی سچائی کا تعین نہیں کیا جا سکتا) کو "مثبت" یا "منفی" کے طور پر بیان نہیں کیا جائے گا. اس کے بجائے، ایک ناکام نتیجہ کو محض غیر تصدیق شدہ کے طور پر بیان کیا جائے گا. جب درخواست کے ذریعہ پیش کردہ شناخت کی تصدیق کرنے کی کوئی کوشش نہیں کی جاتی ہے، تو درخواست کو بھی غیر تصدیق شدہ کے طور پر بیان کیا جائے گا. شرائط صرف اس تناظر میں معنی رکھتی ہیں جہاں درخواست کے ذریعہ پیش کردہ شناخت کو تسلیم کیا جاتا ہے، اور اس وجہ سے، جہاں تصدیق ممکن ہے. اگر پیش کردہ شناخت اوپر فراہم کردہ اختیارات سے مماثل نہیں ہے، یا اگر کوئی شناخت پیش نہیں کی گئی ہے، تو اوپر فراہم کردہ اختیارات غیر متعلقہ ہو جاتے ہیں.

"سنگل ہٹ بائی پاس" کیا ہیں؟ کچھ معاملات میں، ایک مثبت تصدیق شدہ درخواست اب بھی دستخط فائلوں، ماڈیولز، یا دیگر عوامل کے نتیجے میں مسدود ہو سکتی ہے، اور غلط مثبت سے بچنے کے لیے بائی پاس ضروری ہو سکتے ہیں. جب ایک بائی پاس کا مقصد بالکل ایک خلاف ورزی سے نمٹنا ہوتا ہے، تو ایسے بائی پاس کو "سنگل ہٹ بائی پاس" کے طور پر بیان کیا جا سکتا ہے.

  • اس اختیار میں used⬅bypasses کے تحت اسی طرح کا بائی پاس ہ. چاہے اس اختیار کی تصدیق کرنے کی کوشش کے لیے چیک باکس منتخب کیا گیا ہو، کی سفارش کی جاتی ہے اس بات کو یقینی بنانے کہ متعلقہ بائی پاس کا چیک باکس ایک جیسا ہو.
"social_media" [string]
  • سوشل میڈیا پلیٹ فارمز سے درخواستوں کی تصدیق کے لیے کنٹرولز.
social_media───[تصدیق کرنے کی کوشش کریں؟]─[منفی کو مسدود کریں؟]─[غیر تصدیق شدہ درخواستوں کو مسدود کریں؟]─[سنگل ہٹ بائی پاسز کی اجازت دیں؟]─[مثبت سے باخبر رہنا بند کرو؟]
├─Embedly ("* Embedly")
├─Facebook ("** Facebook")
├─Pinterest ("* Pinterest")
├─Snapchat ("* Snapchat")
└─Twitterbot ("*!! Twitterbot")

"مثبت" اور "منفی" کیا ہیں؟ درخواست کے ذریعے پیش کردہ شناخت کی تصدیق کرتے وقت، ایک کامیاب نتیجہ کو "مثبت" یا "منفی" کے طور پر بیان کیا جا سکتا ہے. جب پیش کی گئی شناخت کے حقیقی شناخت ہونے کی تصدیق ہو جاتی ہے، تو اسے "مثبت" کے طور پر بیان کیا جائے گا. جب پیش کردہ شناخت کے جھوٹے ہونے کی تصدیق ہو جاتی ہے، تو اسے "منفی" کے طور پر بیان کیا جائے گا. تاہم، ایک ناکام نتیجہ (مثال کے طور پر، تصدیق ناکام ہو جاتی ہے، یا پیش کردہ شناخت کی سچائی کا تعین نہیں کیا جا سکتا) کو "مثبت" یا "منفی" کے طور پر بیان نہیں کیا جائے گا. اس کے بجائے، ایک ناکام نتیجہ کو محض غیر تصدیق شدہ کے طور پر بیان کیا جائے گا. جب درخواست کے ذریعہ پیش کردہ شناخت کی تصدیق کرنے کی کوئی کوشش نہیں کی جاتی ہے، تو درخواست کو بھی غیر تصدیق شدہ کے طور پر بیان کیا جائے گا. شرائط صرف اس تناظر میں معنی رکھتی ہیں جہاں درخواست کے ذریعہ پیش کردہ شناخت کو تسلیم کیا جاتا ہے، اور اس وجہ سے، جہاں تصدیق ممکن ہے. اگر پیش کردہ شناخت اوپر فراہم کردہ اختیارات سے مماثل نہیں ہے، یا اگر کوئی شناخت پیش نہیں کی گئی ہے، تو اوپر فراہم کردہ اختیارات غیر متعلقہ ہو جاتے ہیں.

"سنگل ہٹ بائی پاس" کیا ہیں؟ کچھ معاملات میں، ایک مثبت تصدیق شدہ درخواست اب بھی دستخط فائلوں، ماڈیولز، یا دیگر عوامل کے نتیجے میں مسدود ہو سکتی ہے، اور غلط مثبت سے بچنے کے لیے بائی پاس ضروری ہو سکتے ہیں. جب ایک بائی پاس کا مقصد بالکل ایک خلاف ورزی سے نمٹنا ہوتا ہے، تو ایسے بائی پاس کو "سنگل ہٹ بائی پاس" کے طور پر بیان کیا جا سکتا ہے.

  • اس اختیار میں used⬅bypasses کے تحت اسی طرح کا بائی پاس ہ. چاہے اس اختیار کی تصدیق کرنے کی کوشش کے لیے چیک باکس منتخب کیا گیا ہو، کی سفارش کی جاتی ہے اس بات کو یقینی بنانے کہ متعلقہ بائی پاس کا چیک باکس ایک جیسا ہو.

** ASN تلاش کی فعالیت کی ضرورت ہے (مثال کے طور پر، IP-API یا BGPView ماڈیول کے ذریعے).

*!! iMessage کی وجہ سے جھوٹے مثبت ہونے کا زیادہ امکان.

"other" [string]
  • جہاں ممکن ہو دوسری قسم کی درخواستوں کی تصدیق کے لیے کنٹرولز.
other───[تصدیق کرنے کی کوشش کریں؟]─[منفی کو مسدود کریں؟]─[غیر تصدیق شدہ درخواستوں کو مسدود کریں؟]─[سنگل ہٹ بائی پاسز کی اجازت دیں؟]─[مثبت سے باخبر رہنا بند کرو؟]
├─AdSense ("AdSense")
├─AmazonAdBot ("* AmazonAdBot")
├─ChatGPT-User ("!! ChatGPT-User")
├─GPTBot ("!! GPTBot")
├─OAI-SearchBot ("!! OAI-SearchBot")
└─UptimeRobot ("UptimeRobot")

"مثبت" اور "منفی" کیا ہیں؟ درخواست کے ذریعے پیش کردہ شناخت کی تصدیق کرتے وقت، ایک کامیاب نتیجہ کو "مثبت" یا "منفی" کے طور پر بیان کیا جا سکتا ہے. جب پیش کی گئی شناخت کے حقیقی شناخت ہونے کی تصدیق ہو جاتی ہے، تو اسے "مثبت" کے طور پر بیان کیا جائے گا. جب پیش کردہ شناخت کے جھوٹے ہونے کی تصدیق ہو جاتی ہے، تو اسے "منفی" کے طور پر بیان کیا جائے گا. تاہم، ایک ناکام نتیجہ (مثال کے طور پر، تصدیق ناکام ہو جاتی ہے، یا پیش کردہ شناخت کی سچائی کا تعین نہیں کیا جا سکتا) کو "مثبت" یا "منفی" کے طور پر بیان نہیں کیا جائے گا. اس کے بجائے، ایک ناکام نتیجہ کو محض غیر تصدیق شدہ کے طور پر بیان کیا جائے گا. جب درخواست کے ذریعہ پیش کردہ شناخت کی تصدیق کرنے کی کوئی کوشش نہیں کی جاتی ہے، تو درخواست کو بھی غیر تصدیق شدہ کے طور پر بیان کیا جائے گا. شرائط صرف اس تناظر میں معنی رکھتی ہیں جہاں درخواست کے ذریعہ پیش کردہ شناخت کو تسلیم کیا جاتا ہے، اور اس وجہ سے، جہاں تصدیق ممکن ہے. اگر پیش کردہ شناخت اوپر فراہم کردہ اختیارات سے مماثل نہیں ہے، یا اگر کوئی شناخت پیش نہیں کی گئی ہے، تو اوپر فراہم کردہ اختیارات غیر متعلقہ ہو جاتے ہیں.

"سنگل ہٹ بائی پاس" کیا ہیں؟ کچھ معاملات میں، ایک مثبت تصدیق شدہ درخواست اب بھی دستخط فائلوں، ماڈیولز، یا دیگر عوامل کے نتیجے میں مسدود ہو سکتی ہے، اور غلط مثبت سے بچنے کے لیے بائی پاس ضروری ہو سکتے ہیں. جب ایک بائی پاس کا مقصد بالکل ایک خلاف ورزی سے نمٹنا ہوتا ہے، تو ایسے بائی پاس کو "سنگل ہٹ بائی پاس" کے طور پر بیان کیا جا سکتا ہے.

  • اس اختیار میں used⬅bypasses کے تحت اسی طرح کا بائی پاس ہ. چاہے اس اختیار کی تصدیق کرنے کی کوشش کے لیے چیک باکس منتخب کیا گیا ہو، کی سفارش کی جاتی ہے اس بات کو یقینی بنانے کہ متعلقہ بائی پاس کا چیک باکس ایک جیسا ہو.

!! اصلی یا جعلی، کسی بھی طرح سے، زیادہ تر صارفین اس کو بلاک کرنا چاہیں گے. یہ "تصدیق کرنے کی کوشش کریں" کو منتخب نہ کرنے اور "غیر تصدیق شدہ درخواستوں کو مسدود کریں" کو منتخب کرکے حاصل کیا جاسکتا ہے. تاہم، کچھ صارفین ایسی درخواستوں کی تصدیق کرنے کے قابل ہو سکتے ہیں (مثبت کو اجازت دیتے ہوئے منفی کو روکنے کے لیے)، اس لیے ماڈیولز کے ذریعے ایسی درخواستوں کو بلاک کرنے کے بجائے، ایسی درخواستوں کو سنبھالنے کے اختیارات یہاں فراہم کیے گئے ہیں.

"adjust" [string]
  • تصدیق کے تناظر میں دیگر خصوصیات کو ایڈجسٹ کرنے کے کنٹرولز.
adjust───[HCaptcha کا استعمال نہ کریں]─[Friendly Captcha کا استعمال نہ کریں]─[Cloudflare Turnstile کا استعمال نہ کریں]
├─Negatives ("بلاک شدہ منفی")
└─NonVerified ("بلاک شدہ غیر تصدیق شدہ")

"captcha" (قسم)

CAPTCHA کی کنفگریشنات (بلاک ہونے پر انسانوں کو دوبارہ رسائی حاصل کرنے کا ایک راستہ فراہم کرتا ہے).

"usemode" [int]
  • CAPTCHA کب پیش کیے جائیں؟ آپ یہاں ہر معاون فراہم کنندہ کے لیے ترجیحی سلوک کی وضاحت کر سکتے ہیں.
usemode───[hCaptcha]─[Friendly Captcha]─[Cloudflare Turnstile]
├─0 (کبھی نہیں.)
├─1 (صرف اس صورت میں جب بلاک ہوجائے، دستخطوں کی حد میں ہو، اور پابندی عائد نہ ہو.)
├─2 (صرف اس صورت میں جب بلاک ہو، استعمال کے لیے خصوصی طور پر نشان زد، دستخطوں کی حد میں ہو، اور پابندی نہیں ہو.)
├─3 (صرف اس وقت جب دستخطوں کی حد میں ہو، اور پابندی عائد نہ ہو (کوئی بات نہیں بلاک ہو یا نہیں).)
├─4 (صرف اس وقت جب بلاک نہیں کیا جاتا ہے.)
├─5 (صرف اس وقت جب بلاک نہ ہوا ہو، یا جب استعمال کے لیے خاص طور پر نشان زد کیا گیا ہو، دستخطوں کی حد میں ہو، اور پابندی نہ ہو.)
└─6 (صرف اس وقت جب بلاک نہ ہوا ہو، حساس صفحہ کی درخواستوں پر.)

نوٹ: وائٹ لسٹڈ یا توثیق شدہ اور غیر مسدود درخواستوں کو کبھی بھی CAPTCHA کو مکمل کرنے کی ضرورت نہیں ہے.

یہ بھی نوٹ کریں: CAPTCHA بوٹس اور مختلف قسم کی بدنیتی پر مبنی خودکار درخواستوں کے خلاف مفید تحفظ فراہم کر سکتے ہیں، لیکن بدنیتی پر مبنی انسان کے خلاف کوئی تحفظ فراہم نہیں کریں گے.

درخواستوں کو معاون قواعد کے ذریعے "استعمال کے لیے نشان زد" کیا جا سکتا ہے.

آیا کسی درخواست کو "حساس" سمجھا جاتا ہے اس کا تعین sensitive⬅general سے ہوتا ہے.

"دستخط کی حد" کا تعین signature_limit⬅captcha سے ہوتا ہے.

"nonblocked_status_code" [int]
  • غیر مسدود درخواستوں پر CAPTCHA کی نمائش کرتے وقت کون سا حیثیت کا کوڈ استعمال کرنا چاہیے؟
nonblocked_status_code───[hCaptcha]─[Friendly Captcha]─[Cloudflare Turnstile]
├─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 (قانونی وجوہات کی بنا پر دستیاب نہیں ہے)): بنیادی طور پر قانونی وجوہات کی بنا پر
  مسدود کرنے پر تجویز کیا جاتا ہے. دوسرے
  سیاق و سباق میں سفارش نہیں کی جاتی ہے.
"api" [string]
  • کون سا API استعمال کرنے کے لیے؟
api───[hCaptcha]─[Friendly Captcha]─[Cloudflare Turnstile]
├─v0 ("v0")
├─v1 ("v1")
├─Invisible ("v1 (پوشیدہ)")
└─v2 ("v2")
"messages" [string]
  • CAPTCHA کے ساتھ دکھائے جانے والے پیغامات.
messages───[hCaptcha]─[Friendly Captcha]─[Cloudflare Turnstile]
├─cookie_warning ("کوکی انتباہ دکھائیں؟): آپ کے ملک یا ریاست کے رازداری کے قوانین پر
│ منحصر ہے (مثلاً، EU میں GDPR/DSGVO، برازیل میں
│ LGPD وغیرہ)، یہ قانونی طور پر درکار ہو سکتا
│ ہے."
└─api_message ("API کا پیغام دکھائیں؟): CAPTCHA کی تکمیل کے حوالے سے صارف کے لیے
  ہدایات، استعمال کیے گئے API کے لیے موزوں."
"lockto" [string]
  • CAPTCHA کو کس چیز پر لاک کرنا ہے.
lockto───[hCaptcha]─[Friendly Captcha]─[Cloudflare Turnstile]
├─ip ("CAPTCHA کو CAPTCHA مکمل کرنے والے صارف کے IP پتے پر لاک کریں لیکن اصل صارف کے لیے نہیں.): کوکیز کا استعمال صارفین کی شناخت کے لیے
│ نہیں کیا جاتا. جب CAPTCHA کی کامیاب تکمیل کی
│ وجہ سے دوبارہ رسائی حاصل کی جاتی ہے، تو اس
│ کا اطلاق اسی IP پتہ سے جڑنے والے ہر فرد پر
│ ہوتا ہے."
├─user ("CAPTCHA مکمل کرنے والے صارف کے لیے CAPTCHA کو لاک کریں لیکن ان کے IP پتہ پر نہیں.): کوکیز کا استعمال صارفین کی شناخت کے لیے
│ کیا جاتا ہے. جب CAPTCHA کی کامیاب تکمیل کی وجہ
│ سے دوبارہ رسائی حاصل کی جاتی ہے، تو یہ صرف
│ CAPTCHA کو مکمل کرنے والے صارف پر لاگو ہوتا
│ ہے، اور جب تک ان کی کوکی درست رہے گی،
│ برقرار رہے گی، چاہے ان کا IP پتہ بدل جائے."
└─both ("CAPTCHA مکمل کرنے والے صارف کے ساتھ ساتھ ان کے IP پتہ پر CAPTCHA کو لاک کریں.): کوکیز کا استعمال صارفین کی شناخت کے لیے
  کیا جاتا ہے. جب CAPTCHA کی کامیاب تکمیل کی وجہ
  سے دوبارہ رسائی حاصل کی جاتی ہے، تو یہ صرف
  CAPTCHA کو مکمل کرنے والے صارف پر لاگو ہوتا
  ہے، اور اگر اس کا IP پتہ تبدیل ہوتا ہے تو یہ
  برقرار نہیں رہے گا."
"hcaptcha_sitekey" [string]
  • اگر آپ CIDRAM کے ساتھ hCaptcha استعمال کرنا چاہتے ہیں، تو آپ کو یہاں ایک قدر درج کرنے کی ضرورت ہوگی. اگر نہیں، تو آپ اسے نظر انداز کر سکتے ہیں.

یہ قدر آپ کے CAPTCHA خدمت کے لیے ڈیش بورڈ میں مل سکتی ہے.

بھی دیکھو:
"hcaptcha_secret" [string]
  • اگر آپ CIDRAM کے ساتھ hCaptcha استعمال کرنا چاہتے ہیں، تو آپ کو یہاں ایک قدر درج کرنے کی ضرورت ہوگی. اگر نہیں، تو آپ اسے نظر انداز کر سکتے ہیں.

یہ قدر آپ کے CAPTCHA خدمت کے لیے ڈیش بورڈ میں مل سکتی ہے.

بھی دیکھو:
"friendly_sitekey" [string]
  • اگر آپ CIDRAM کے ساتھ Friendly Captcha استعمال کرنا چاہتے ہیں، تو آپ کو یہاں ایک قدر درج کرنے کی ضرورت ہوگی. اگر نہیں، تو آپ اسے نظر انداز کر سکتے ہیں.

یہ قدر آپ کے CAPTCHA خدمت کے لیے ڈیش بورڈ میں مل سکتی ہے.

بھی دیکھو:
"friendly_apikey" [string]
  • اگر آپ CIDRAM کے ساتھ Friendly Captcha استعمال کرنا چاہتے ہیں، تو آپ کو یہاں ایک قدر درج کرنے کی ضرورت ہوگی. اگر نہیں، تو آپ اسے نظر انداز کر سکتے ہیں.

یہ قدر آپ کے CAPTCHA خدمت کے لیے ڈیش بورڈ میں مل سکتی ہے.

بھی دیکھو:
"turnstile_sitekey" [string]
  • اگر آپ CIDRAM کے ساتھ Cloudflare Turnstile استعمال کرنا چاہتے ہیں، تو آپ کو یہاں ایک قدر درج کرنے کی ضرورت ہوگی. اگر نہیں، تو آپ اسے نظر انداز کر سکتے ہیں.

یہ قدر آپ کے CAPTCHA خدمت کے لیے ڈیش بورڈ میں مل سکتی ہے.

بھی دیکھو:
"turnstile_secret" [string]
  • اگر آپ CIDRAM کے ساتھ Cloudflare Turnstile استعمال کرنا چاہتے ہیں، تو آپ کو یہاں ایک قدر درج کرنے کی ضرورت ہوگی. اگر نہیں، تو آپ اسے نظر انداز کر سکتے ہیں.

یہ قدر آپ کے CAPTCHA خدمت کے لیے ڈیش بورڈ میں مل سکتی ہے.

بھی دیکھو:
"expiry" [float]
  • گھنٹوں کی تعداد CAPTCHA کے واقعات کو یاد کرنے. پہلے سے طے شدہ = 720 (1 ماہ).
"signature_limit" [int]
  • CAPTCHA پیش کش واپس لینے سے پہلے دستخطوں کی زیادہ سے زیادہ تعداد کی اجازت. پہلے سے طے شدہ = 1.
"log" [string]
  • تمام CAPTCHA کے کوششوں لاگ؟ اگر ہاں، تو لاگ فائل کے لیے استعمال کرنے کے لیے نام کی وضاحت کریں. اگر نہیں، تو اس متغیر کو خالی چھوڑ دیں.

مفید مشورہ: آپ ٹائم فارمیٹ پلیس ہولڈرز کا استعمال کرکے لاگ فائلوں کے ناموں کے ساتھ تاریخ/وقت کی معلومات منسلک کرسکتے ہیں. دستیاب وقت کی شکل کے پلیس ہولڈرز time_format⬅general پر دکھائے جاتے ہیں.

قانونی تقاضوں کے لیے کنفگریشنات.

"pseudonymise_ip_addresses" [bool]
  • لاگ ان کرتے وقت پی ایس ڈی نامناسب IP پتے؟ True (سچے) = جی ہاں [پہلے سے طے شدہ]؛ False (جھوٹی) = نہیں.
بھی دیکھو:
"privacy_policy" [string]
  • کسی بھی پیدا کردہ صفحات کے فوٹر میں ظاہر ہونے والی متعلقہ رازداری کی پالیسی کا پتہ. ایک URL کی وضاحت کریں، یا غیر فعال کرنے کے لیے خالی چھوڑ دیں.

"template_data" (قسم)

ٹیمپلیٹس اور تھیمز کی کنفگریشنات.

"theme" [string]
  • بلاک ایونٹس اور CAPTCHA کی درخواستوں کے لیے استعمال کرنے والی تھیم.
theme
├─default ("Default")
├─bluemetal ("Blue Metal")
├─fullmoon ("Full Moon")
├─moss ("Moss")
├─primer ("Primer")
├─primerdark ("Primer Dark")
├─rbi ("Red-Blue Inverted")
├─slate ("Slate")
└─…دیگر
"theme_mode" [string]
  • بلاک ایونٹس اور CAPTCHA کی درخواستوں کے لیے تھیم کا موڈ.
theme_mode
├─normal ("نارمل")
└─inverted ("الٹا")
"magnification" [float]
  • فونٹ اضافہ. پہلے سے طے شدہ = 1.
"css_url" [string]
  • اپنی مرضی کے موضوعات کے لیے سی ایس ایس فائل URL.
"block_event_title" [string]
  • بلاک ایونٹس کے لیے ظاہر کرنے کے لیے صفحہ کا عنوان.
block_event_title
├─CIDRAM ("CIDRAM")
├─denied ("رسائی مسترد کر دی!")
└─…دیگر
"captcha_title" [string]
  • CAPTCHA کی درخواستوں کے لیے ظاہر کرنے کے لیے صفحہ کا عنوان.
captcha_title
├─CIDRAM ("CIDRAM")
└─…دیگر
"custom_header" [string]
  • تمام "رسائی مسترد کر دی" صفحات کے شروع میں بطور HTML داخل کیا گیا. اگر آپ ویب سائٹ کا لوگو، پرسنلائزڈ ہیڈر، اسکرپٹس، وغیرہ شامل کرنا چاہتے ہیں، تو یہ مفید ہو سکتا ہے.
  • تمام "رسائی مسترد کر دی" صفحات کے آخر میں بطور HTML داخل کیا گیا. اگر آپ قانونی نوٹس، رابطہ لنک، کاروباری معلومات، وغیرہ شامل کرنا چاہتے ہیں، تو یہ مفید ہو سکتا ہے.

"rate_limiting" (قسم)

شرح کو محدود کرنے کی کنفگریشنات (عام استعمال کے لیے سفارش نہیں کی جاتی ہے).

ذہن میں رکھیں جس طرح دیگر تمام CIDRAM خصوصیات کے ساتھ، CIDRAM کی شرح محدود کرنے والی خصوصیت صرف ان صفحات اور وسائل پر لاگو کی جا سکتی ہے جن سے CIDRAM منسلک ہے. اس کا عام طور پر مطلب یہ ہوتا ہے کہ جو وسائل PHP نہیں ہیں ان کا احاطہ نہیں کیا جائے گا سوائے اس کے جہاں واضح طور پر منسلک PHP وسائل کے ذریعہ پیش کیا جائے. اگر آپ ریٹ محدود کرنے کے لیے سرور ماڈیول، cPanel، یا کوئی دوسرا نیٹ ورک ٹول استعمال کرنے کے قابل ہیں، تو CIDRAM کی شرح محدود کرنے والی خصوصیت کے بجائے اسے استعمال کرنا بہتر ہوگا. یہ بھی ذہن میں رکھیں کہ ایک پرعزم اور پرعزم صارف، ان کا IP پتہ کو گھما کر یا کسی ایسے پراکسی یا VPN فراہم کنندہ پر جا کر جس سے CIDRAM ابھی تک واقف نہیں ہے، آسانی سے شرح کو محدود کرنے سے بچا سکتا ہے, اور یہ بات ذہن میں رکھیں کہ شرح کو محدود کرنا حقیقی، حقیقی اختتامی صارفین کے لیے بہت پریشان کن ہو سکتا ہے. یہ بعض اوقات ضروری ہو سکتا ہے، لیکن شاذ و نادر ہی مطلوب ہے.

"max_bandwidth" [string]
  • بینڈوڈتھ کی زیادہ سے زیادہ رقم کی اجازت کے عرصے میں اجازت دی گئی ہے. جب سے تجاوز کی گئی، مستقبل کی درخواستوں کی ریٹ محدود ہے. جب 0، اس قسم کی محدود استعمال نہیں کی جائے گی. پہلے سے طے شدہ = 0KB.
"max_requests" [int]
  • الاؤنس کی مدت کے اندر اندر زیادہ سے زیادہ درخواستوں کی اجازت دی گئی ہے. جب سے تجاوز کی گئی، مستقبل کی درخواستوں کی ریٹ محدود ہے. جب 0، اس قسم کی محدود استعمال نہیں کی جائے گی. پہلے سے طے شدہ = 0.
"precision_ipv4" [int]
  • IPv4 استعمال کی نگرانی کرتے وقت استعمال کرنے کی صحت سے متعلق. قیمت CIDR بلاک سائز کی عکاسی کرتا ہے. بہترین صحت سے متعلق کے لیے 32 پر مقرر کریں. پہلے سے طے شدہ = 32.
"precision_ipv6" [int]
  • IPv6 استعمال کی نگرانی کرتے وقت استعمال کرنے کی صحت سے متعلق. قیمت CIDR بلاک سائز کی عکاسی کرتا ہے. بہترین صحت سے متعلق کے لیے 128 پر مقرر کریں. پہلے سے طے شدہ = 128.
"allowance_period" [string]
  • استعمال کو ٹریک کرنے کا دورانیہ. پہلے سے طے شدہ = 0°0′0″.
"exceptions" [string]
  • مستثنیات (یعنی، درخواستوں کو جس کی ریٹ محدود نہیں ہونی چاہیے). متعلقہ صرف اس وقت جب شرح کی حد بندی قابل ہو.
exceptions
├─Whitelisted ("وائٹ لسٹ کی درخواستیں")
├─Verified ("سرچ انجنوں اور سوشل میڈیا سے تصدیق شدہ درخواستیں")
└─FE ("CIDRAM فرنٹ اینڈ سے درخواستیں")
"segregate" [bool]
  • کیا مختلف ڈومینز اور میزبانوں کے کوٹوں کو الگ یا شیئر کیا جانا چاہیے؟ True = کوٹے الگ کیے جائیں گے. False = کوٹے شیئر کیے جائیں گے [پہلے سے طے شدہ].

"supplementary_cache_options" (قسم)

ضمنی کیشے کے اختیارات. نوٹ: ان اقدار کو تبدیل کرنے سے آپ ممکنہ طور پر لاگ آؤٹ ہو سکتے ہیں.

"prefix" [string]
  • یہاں بیان کردہ قدر کو تمام کیش انٹری کیز کے ساتھ پہلے سے جوڑا جائے گا. پہلے سے طے شدہ = "CIDRAM_". جب ایک ہی سرور پر متعدد تنصیبات موجود ہوں، تو یہ ان کے کیچز کو ایک دوسرے سے الگ رکھنے کے لیے مفید ہو سکتا ہے.
"enable_apcu" [bool]
  • اس کی وضاحت کرتا ہے کہ کیش کے لیے APCu استعمال کرنا چاہے. پہلے سے طے شدہ = True (سچ).
"enable_memcached" [bool]
  • اس کی وضاحت کرتا ہے کہ کیش کے لیے Memcached استعمال کرنا چاہے. پہلے سے طے شدہ = False (جھوٹی).
"enable_redis" [bool]
  • اس کی وضاحت کرتا ہے کہ کیش کے لیے Redis استعمال کرنا چاہے. پہلے سے طے شدہ = False (جھوٹی).
"enable_pdo" [bool]
  • اس کی وضاحت کرتا ہے کہ کیش کے لیے PDO استعمال کرنا چاہے. پہلے سے طے شدہ = False (جھوٹی).
"memcached_host" [string]
  • Memcached کے میزبان نام. پہلے سے طے شدہ = localhost.
"memcached_port" [int]
  • Memcached کے لیے بندرگاہ. پہلے سے طے شدہ = "11211".
"redis_host" [string]
  • Redis کے میزبان نام. پہلے سے طے شدہ = localhost.
"redis_port" [int]
  • Redis کے لیے بندرگاہ. پہلے سے طے شدہ = "6379".
"redis_timeout" [float]
  • Redis کے لیے ٹائم آؤٹ. پہلے سے طے شدہ = "2.5".
"redis_database_number" [int]
  • Redis ڈیٹا بیس نمبر. پہلے سے طے شدہ = 0. نوٹ: Redis Cluster کے ساتھ 0 کے علاوہ دیگر اقدار استعمال نہیں کر سکتے.
"pdo_dsn" [string]
  • PDO کے لیے DSN. پہلے سے طے شدہ = "mysql:dbname=cidram;host=localhost;port=3306".

FAQ. "PDO DSN" کیا ہے؟ میں CIDRAM کے ساتھ PDO کیسے استعمال کرسکتا ہوں؟

"pdo_username" [string]
  • PDO کے لیے صارف نام.
"pdo_password" [string]
  • PDO کے لیے پاس ورڈ.

"bypasses" (قسم)

پہلے سے طے شدہ دستخط کو نظرانداز کرنے کے لیے تشکیل.

"used" [string]
  • کون سے بائی پاس کو استعمال کیا جانا چاہیے؟
used
├─AbuseIPDB ("AbuseIPDB")
├─AmazonAdBot ("AmazonAdBot")
├─Baidu ("Baiduspider/百度")
├─Bingbot ("Bingbot")
├─DuckDuckBot ("DuckDuckBot")
├─Embedly ("Embedly")
├─Feedbot ("Feedbot")
├─Feedspot ("Feedspot")
├─GoogleFiber ("Google Fiber")
├─Googlebot ("Googlebot")
├─Jetpack ("Jetpack")
├─PetalBot ("PetalBot")
├─Pinterest ("Pinterest")
├─Redditbot ("Redditbot")
├─Snapchat ("Snapchat")
├─Sogou ("Sogou/搜狗")
├─Yandex ("Yandex/Яндекс")
└─iCloud ("iCloud (iPhone Safari Bypass)")

۶. دستخط فارمیٹ

۶.۰ مبادیات (دستخط فائلوں کے لیے)

"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

۶.۲.۰ YAML مبادیات

مکمل طور پر اختیاری (یعنی آپ اسے استعمال کرتے ہیں تو آپ کا انتخاب ہے) 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: username@domain.tld
logging:
 standard_log: "logfile.{yyyy}-{mm}-{dd}.txt"
 apache_style_log: "access.{yyyy}-{mm}-{dd}.txt"
 serialised_log: "serial.{yyyy}-{mm}-{dd}.txt"
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/"

۶.۳ معاون

۶.۳.۰ دستخط کے حصوں کو نظر انداز کرنا

کے علاوہ، آپ CIDRAM مکمل طور پر دستخط کی فائلوں میں سے کسی کے اندر کچھ مخصوص حصوں کو نظر انداز کرنا چاہتے ہیں تو، آپ "ignore.dat" فائل ہے جس میں حصوں کو نظر انداز کرنے کی وضاحت کرنے کے لیے استعمال کر سکتے ہیں. ایک نئی لائن پر، لکھنا "Ignore"، ایک کی جگہ کے بعد، آپ کو CIDRAM نظر انداز کرنا (ذیل کی مثال ملاحظہ کریں) چاہتے ہیں کہ سیکشن کے نام کے بعد

Ignore سیکشن 1
یہ CIDRAM سامنے کے آخر "حصوں کی فہرست" کے صفحے کے ذریعہ بھی حاصل کیا جا سکتا ہے.

۶.۳.۱ معاون قوانین

اگر آپ محسوس کرتے ہیں کہ آپ اپنی مرضی کے دستخط شدہ فائلوں کو لکھتے ہیں یا اپنی مرضی کے مطابق ماڈیولز آپ کے لیے بہت پیچیدہ ہیں، ایک آسان متبادل سیڈامیم سامنے کے آخر "معاون قواعد" کے صفحے کا استعمال کرنا ہوسکتا ہے. مناسب اختیارات کا انتخاب کرتے ہوئے اور مخصوص قسم کے درخواستوں کے بارے میں تفصیلات کی وضاحت کرکے، آپ ان ہدایات کو جواب دینے کے بارے میں CIDRAM کو ہدایت کرسکتے ہیں. تمام دستخط شدہ فائلوں کے بعد "معاون قواعد" کو معطل کر دیا جاتا ہے اور ماڈیولز نے پہلے سے ہی عملدرآمد مکمل کر لیا ہے.

۶.۳.۲ اپنی مرضی کے دستخطی فائلوں کو محفوظ کرنا اور چالو کرنا

CIDRAM v2 اور اس سے پہلے کے لیے، vault میں، آپ کو دو فائلیں ملیں گی: ipv4_custom.dat.RenameMe اور ipv6_custom.dat.RenameMe. آپ ان فائلوں میں اپنی مرضی کے دستخط محفوظ کر سکتے ہیں، یا، اگر آپ چاہیں تو، آپ اپنی مرضی کے دستخطوں کے لیے نئی فائلیں بنا سکتے ہیں، ان کو جو چاہیں نام دے سکتے ہیں. CIDRAM v2 اور اس سے پہلے کے لیے، حسب ضرورت دستخطی فائلوں کو vault ڈائریکٹری کے بیس میں محفوظ کیا جانا چاہیے.

CIDRAM v3 اور اس سے آگے کے لیے، حسب ضرورت دستخطوں کے لیے پہلے سے فراہم کردہ کوئی فائل نہیں ہے، لیکن آپ اسی طرح اپنی مرضی کے دستخطوں کے لیے نئی فائلیں بنا سکتے ہیں، جیسا کہ آپ چاہیں نام رکھ سکتے ہیں. CIDRAM v3 اور آگے کے لیے، اپنی مرضی کے مطابق دستخطی فائلوں کو آپ کی CIDRAM انسٹالیشن کی تیار کردہ "signatures" ڈائریکٹری میں محفوظ کیا جانا چاہیے.

اپنی مرضی کی دستخطی فائلوں کو "فعال" کرنے کے لیے، آپ کی کنفیگریشن فائل کے "ipv4" یا "ipv6" کنفیگریشن ڈائریکٹو کے ذریعہ ان کا حوالہ دیا جانا چاہیے (اس بات پر منحصر ہے کہ آیا کسٹم دستخط فائلیں IPv4 یا IPv6 دستخطوں کے لیے ہیں).

CIDRAM v2 اور اس سے پہلے کے لیے، "ipv4" اور "ipv6" "signatures" کنفیگریشن کے زمرے کے تحت پائے جاتے ہیں.

CIDRAM v3 اور آگے کے لیے، "ipv4" اور "ipv6" "components" کنفیگریشن کے زمرے کے تحت پائے جاتے ہیں.

۶.۴ مبادیات (ماڈیولز کے لیے)

ماڈیولز CIDRAM کی فعالیت کو بڑھانے کے لیے استعمال کیا جا سکتا ہے، اضافی کاموں کو انجام دینے کے لیے، یا اضافی منطق پر عمل درآمد.

کیونکہ ماڈیولز PHP کی فائلوں کے طور پر لکھی جاتی ہیں، اگر آپ CIDRAM کوڈ بیس کے ساتھ مناسب طریقے سے واقف ہیں تو، آپ اپنی ماڈیول اور ماڈیول دستخط کی تشکیل کرسکتے ہیں تاہم آپ چاہتے ہیں (PHP کے ساتھ کیا ممکن ہے کی مناسب حدود کے اندر اندر).

نوٹ: اگر آپ PHP کے کوڈ کے ساتھ کام کرنے میں آرام دہ اور پرسکون نہیں ہیں تو، آپ کے اپنے ماڈیول لکھنے کی سفارش نہیں کی جاتی ہے.

کچھ فعالیتیں CIDRAM کی طرف سے فراہم کی جاتی ہیں جو اپنے ماڈیولز کو لکھنے کے لیے آسان اور آسان بنانا چاہیے. اس فعالیت کے بارے میں معلومات ذیل میں بیان کی گئی ہے.

۶.۵ ماڈیول فعالیت

۶.۵.۰ $this->trigger
ماڈیول دستخط عام طور پر $this->trigger کے ساتھ لکھا جاتا ہے. زیادہ تر معاملات میں، یہ بندش ماڈیول لکھنے کے مقصد کے لیے کسی اور سے کہیں زیادہ اہم ہو گی.

$this->trigger ۴ پیرامیٹرز کو قبول کرتا ہے: $Condition، $ReasonShort، $ReasonLong (اختیاری)، $DefineOptions (اختیاری).

$Condition سچائی کا اندازہ کیا جاتا ہے. اگر یہ سچ (true) ہے تو، دستخط چالو ہے. اگر یہ غلط (false) ہے تو، دستخط چالو نہیں ہے. $Condition عام طور پر ایک ایسی شرط پر مشتمل ہے جس کی وجہ سے کسی درخواست کو بلاک کرنا ہوگا.

$ReasonShort کو "کیوں بلاک شدہ" فیلڈ میں حوالہ دیا جاتا ہے جب دستخط چالو ہوجاتا ہے.

$ReasonLong صارف کو ظاہر ہونے پر ایک پیغام ہے جب وہ روک رہے ہیں، اس وجہ سے وضاحت کریں کہ. ختم ہونے پر معیاری "کیوں بلاک شدہ" پیغام استعمال کرتا ہے.

$DefineOptions ایک اختیاری سرنی ہے جس میں کلیدی/قدر شامل ہیں، درخواست کی مثال کے مطابق مخصوص کنفگریشنات کے اختیارات کی وضاحت کرنے کے لیے استعمال کیا جاتا ہے. جب دستخط چالو ہو تو کنفگریشن کے اختیارات لاگو کیے جائیں گے.

$this->trigger سچ ہے جب دستخط چالو ہوجاتا ہے، اور جب غلط نہیں ہوتا تو غلط ہوتا ہے.

۶.۵.۱ $this->bypass
دستخط بائی پاسز عام طور پر $this->bypass کے ساتھ لکھے جاتے ہیں.

$this->bypass ۳ پیرامیٹرز کو قبول کرتا ہے: $Condition، $ReasonShort، $DefineOptions (اختیاری).

$Condition سچائی کا اندازہ کیا جاتا ہے. اگر یہ سچ (true) ہے تو، بائی پاس چالو ہے. اگر یہ غلط (false) ہے تو، بائی پاس چالو نہیں ہے. $Condition عام طور پر ایک ایسی شرط پر مشتمل ہے جو کسی کو بلاک کرنے کی درخواست نہیں بننی چاہیے.

$ReasonShort کو "کیوں بلاک شدہ" فیلڈ میں حوالہ دیا جاتا ہے جب بائی پاس چالو ہوجاتا ہے.

$DefineOptions ایک اختیاری سرنی ہے جس میں کلیدی/قدر شامل ہیں، درخواست کی مثال کے مطابق مخصوص کنفگریشنات کے اختیارات کی وضاحت کرنے کے لیے استعمال کیا جاتا ہے. جب دستخط چالو ہو تو کنفگریشن کے اختیارات لاگو کیے جائیں گے.

$this->bypass سچ ہے جب بائی پاس چالو ہوجاتا ہے، اور جب غلط نہیں ہوتا.

۶.۵.۲ "$this->dnsReverse"
یہ ایک 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']
 
اگر موجودہ درخواست کا IP پتہ 6to4، Teredo، یا ISATAP پتہ ہے، تو وہ پتہ اس کے IPv4 کے برابر ہو جائے گا. اگر نہیں، تو یہ موجودہ درخواست کا IP پتہ ہوگا.
$this->BlockInfo['IPAddrResolved']
 
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']
 
موجودہ درخواست کی درخواست کا طریقہ.
$this->BlockInfo['Request_Method']
 
موجودہ درخواست کا پروٹوکول.
$this->BlockInfo['Protocol']

۷. جانا جاتا مطابقت کے مسائل

مندرجہ ذیل پیکجوں اور مصنوعات کو CIDRAM کے ساتھ مطابقت پزیر ہونے کے لیے مل گیا ہے:
اس بات کا یقین کرنے کے لیے کہ مندرجہ ذیل پیکجوں اور مصنوعات CIDRAM کے ساتھ مطابقت پزیر ہوں گے ماڈیولز دستیاب کیے گئے ہیں:
بھی دیکھو: مطابقت چارٹ.


بلاک تمام ممالک CIDRAM کر سکتا ہوں؟

جی ہاں. اس کا آسان ترین طریقہ BGPView ماڈیول یا IP-API ماڈیول کو انسٹال کرنا اور اپنی ضروریات کے مطابق تشکیل دینا ہے.

دستخط کیسے بیشتر اپ ڈیٹ کر رہے ہیں؟

اپ ڈیٹ فریکوئنسی سوال میں دستخط کی فائلوں پر منحصر ہوتی ہے. CIDRAM دستخط کی فائلوں کے لیے تمام حاکم عام طور پر اپ ڈیٹ کرنے کے لیے ممکن ہے کے طور پر کے طور پر ان کے دستخط رکھنے کی کوشش کرتے ہیں، لیکن ہم سب کے طور پر مختلف دیگر وعدوں، اس منصوبے سے باہر ہماری زندگی ہے، اور ہم میں سے کوئی اس کو مالی طور پر معاوضہ رہے ہیں (یعنی، ادا کی ) منصوبے پر ہماری کوششوں کے لیے ایک عین مطابق اپ ڈیٹ کے شیڈول کی ضمانت نہیں کیا جا سکتا. ان کو اپ ڈیٹ کرنے کے لیے کافی وقت نہیں ہے جب بھی، اور عام طور پر، حاکم ضرورت پر اور حدود کے درمیان پائے جاتے تبدیلیاں کس طرح اکثر کی بنیاد پر ترجیح دینے کی کوشش کریں عام طور پر، دستخطوں کو اپ ڈیٹ کر رہے ہیں. اگر آپ کو کوئی پیشکش کرنے کو تیار ہیں تو اس سلسلے میں معاونت ہمیشہ تعریف کی ہے.

CIDRAM استعمال کرتے ہوئے میں ایک مسئلہ کا سامنا کرنا پڑا ہے اور میں اس کے بارے میں کیا پتہ نہیں ہے! مدد کریں!

  • آپ نے سافٹ ویئر کا تازہ ترین ورژن استعمال کر رہے ہیں؟ آپ کو آپ کے دستخط فائلوں کا تازہ ترین ورژن استعمال کر رہے ہیں؟ ان دو سوالوں کی یا تو کرنے کے لیے جواب نہیں ہے تو، سب سے پہلے سب کچھ کو اپ ڈیٹ کرنے کی کوشش کریں، اور چاہے وہ مسئلہ برقرار رہتا ہے چیک کریں. یہ برقرار رہتا ہے، پڑھنے جاری رکھیں.
  • اگر آپ کو تمام دستاویزات کے ذریعے کی جانچ پڑتال کی ہے؟ اگر نہیں، تو براہ مہربانی. مسئلہ دستاویزات استعمال کر حل نہیں کیا جا سکتا ہے، تو پڑھنے جاری رکھیں.
  • اگر آپ کو issues صفحے جانچ پڑتال کی ہے، دیکھنا چاہے مسئلہ پہلے ذکر کیا گیا ہے؟ اس سے پہلے ذکر کیا گیا ہے تو، چاہے وہ کسی بھی تجاویز، خیالات، اور / یا کے حل فراہم کیا گیا جانچ اور مسئلہ حل کرنے کی کوشش کرنے کے لیے ضروری کے مطابق عمل کریں.
  • اگر مسئلہ اب بھی جاری رہتا ہے، تو issues کے صفحے پر ایک نیا issue تشکیل دے کر اس کے بارے میں مدد طلب کریں.

میں نے دورہ کرنا چاہتے ہیں کہ ایک ویب سائٹ سے CIDRAM کی طرف سے بلاک کیا گیا ہے! مدد کریں!

CIDRAM ویب سائٹ کے مالکان ناپسندیدہ ٹریفک کو بلاک کرنے کے لیے ایک ذریعہ فراہم کرتا ہے، لیکن یہ وہ CIDRAM استعمال کرنا چاہتے ہیں کہ کس طرح اپنے لیے فیصلہ کرنے کے لیے ویب سائٹ کے مالکان کی ذمہ داری ہے. کے دستخط سے متعلق جھوٹی مثبت عام طور CIDRAM ساتھ شامل فائلوں کی صورت میں، تصحیح بنایا جا سکتا ہے، لیکن مخصوص ویب سائٹس سے غیر مسدود ہونے کے حوالے میں، آپ کے سوال میں ویب سائٹس کے مالکان کے ساتھ کہ اپ لینے کی ضرورت پڑے گی. مقدمات جہاں تصحیح کم سے کم، بنائے جاتے ہیں میں، وہ مثال ہے، وہ ان کی تنصیب ترمیم شدہ گئے ہیں جہاں کے لیے، اس طرح کے طور پر ان کے دستخط فائلوں اور / یا تنصیب، اور دیگر مقدمات میں (اپ ڈیٹ کرنے کی ضرورت ہو گی، ان کی اپنی مرضی کے دستخط پیدا، وغیرہ)، کو حل کرنے کی ذمہ داری آپ کا مسئلہ مکمل طور پر ان کی ہے، اور ہمارے قابو سے باہر مکمل طور پر ہے.

میں 7.2 سے زیادہ پرانے ایک PHP ورژن کے ساتھ CIDRAM v2~v4 استعمال کرنا چاہتے ہیں؛ کیا آپ مدد کر سکتے ہیں؟

نہیں. CIDRAM v2~v4 کم از کم PHP≥7.2 کی ضرورت ہے.

بھی دیکھو: مطابقت چارٹ.

میں نے ایک سے زیادہ ڈومینز کی حفاظت کے لیے ایک واحد CIDRAM تنصیب کا استعمال کر سکتا ہوں؟

جی ہاں. CIDRAM ایک سے زیادہ ڈومینز کی حفاظت کے لیے استعمال کیا جا سکتا ہے. ضرورت کی کنفگریشن مختلف ہے تو، ایسا کرنے کے لیے تحفظ کی ضرورت ہوتی ڈومینز کے مطابق نامی نئی کنفگریشن فائل، تخلیق کرتے ہیں. CIDRAM یہ ڈومین کے لیے کام کرنا چاہیے کہ کس طرح اس بات کا تعین کرنے کے لیے ان فائلوں کو استعمال کریں گے. سوف تستخدم CIDRAM هذه الملفات لتحديد كيفية تشغيلها للنطاق. ایک مثال کے طور، کے لیے "https://www.some-domain.tld/"، اس کا نام ہے "some-domain.tld.config.yml". ڈومین نام "HTTP_HOST" سے آتا ہے. "www" نظر انداز کر دیا جاتا ہے.

میں نے اس پر وقت خرچ نہیں کرنا چاہتا (اسے انسٹال، اس کے قیام، وغیرہ)؛ میں نے آپ کو ایسا کرنے کے لیے ادا کر سکتے ہیں؟

شاید. یہ معاملہ در معاملہ کی بنیاد پر کیا جاتا ہے. کی آپ کو ضرورت ہے ہمیں بتائیں. ہمیں بتائیں کہ آپ کی پیشکش کر رہے ہیں. ہم آپ کو بتا دیں گے ہم مدد کر سکتے ہیں.

میں ذاتی کام کے لیے آپ کی خدمات حاصل کر سکتے ہیں؟

اوپر ملاحظہ کریں.

مجھے خصوصی ترمیم کی ضرورت؛ کیا آپ مدد کر سکتے ہیں؟

اوپر ملاحظہ کریں.

میں نے ایک ڈویلپر، ویب سائٹ ڈیزائنر، یا پروگرامر ہوں. میں اس منصوبے سے متعلق کام کر سکتے ہیں؟

جی ہاں. ہمارے لائسنس اس کی ممانعت نہیں کرتا.

میں نے اس منصوبے میں شراکت کے لیے چاہتے ہیں؛ میں یہ کر سکتا ہوں؟

جی ہاں. اس کا خیر مقدم کیا جاتا ہے. "CONTRIBUTING.md" ملاحظہ کریں مزید معلومات کے لیے.

کیا میں خود کار طریقے سے اپ ڈیٹ کرنے کے لیے cron استعمال کرسکتا ہوں؟

جی ہاں. بیرونی سکرپٹ کے ذریعہ اپ ڈیٹس صفحہ کے ساتھ بات چیت کرنے کے لیے ایک API سامنے کے آخر میں بنایا جاتا ہے. ایک علاحدہ لکھاوٹ، "Cronable"، دستیاب ہے، اور اس کے اور دیگر معاون پیکجوں کو خود کار طریقے سے اپ ڈیٹ کرنے کے لیے آپ کے cron manager یا cron scheduler کا استعمال کیا جا سکتا ہے (یہ اسکرپٹ اپنی اپنی دستاویزات فراہم کرتا ہے).

"خلاف ورزی" کیا ہیں؟

"دستخط شمار" اور "خلاف ورزی" دونوں کا تعلق کسی خاص درخواست کے دوران شروع ہونے والے دستخطوں کی شدت اور تعداد سے ہے، چاہے دستخطی فائلوں، ماڈیولز، معاون اصولوں، یا کسی اور وجہ سے. لیکن، جب کہ "دستخط شمار" صرف اس مخصوص درخواست کے لیے برقرار رہتی ہے، "خلاف ورزی" زیادہ سے زیادہ درخواستوں پر برقرار رہ سکتی ہے جیسا کہ default_tracktime کے ذریعے طے کیا گیا ہے.

یہ اس بات کو یقینی بناتا ہے کہ جب ایک درخواست کو کافی تعداد میں خلاف ورزیوں کے ساتھ بلاک کیا جاتا ہے، تو اسی ذریعہ سے آنے والی درخواستوں کو بھی بلاک کیا جا سکتا ہے.

CIDRAM بلاک میزبانوں کو کر سکتے ہیں؟

جی ہاں. یہ ایک معاون اصول یا حسب ضرورت ماڈیول بنا کر حاصل کیا جا سکتا ہے.

میزبان ناموں کو مسدود کرنے کے لیے ایک معاون اصول

میں "default_dns" کے لیے کیا استعمال کر سکتا ہوں؟

عام طور پر، کسی قابل اعتماد DNS سرور کا IP کافی ہونا چاہیے. اگر آپ تجاویز کی تلاش کر رہے ہیں تو، public-dns.info اور OpenNIC نام سے جانا جاتا، عوامی DNS سرورز کی وسیع فہرست فراہم کرتے ہیں. متبادل طور پر، ذیل میں میز ملاحظہ کریں:

IPآپریٹر
1.1.1.1Cloudflare
8.8.4.4
8.8.8.8
2001:4860:4860::8844
2001:4860:4860::8888
Google Public DNS
9.9.9.9
149.112.112.112
Quad9 DNS
84.200.69.80
84.200.70.40
2001:1608:10:25::1c04:b12f
2001:1608:10:25::9249:d69b
DNS.WATCH
208.67.220.220
208.67.222.220
208.67.222.222
OpenDNS Home
77.88.8.1
77.88.8.8
2a02:6b8::feed:0ff
2a02:6b8:0:1::feed:0ff
Yandex.DNS
8.20.247.20
8.26.56.26
Comodo Secure DNS
216.146.35.35
216.146.36.36
Dyn
64.6.64.6
64.6.65.6
Verisign Public DNS
37.235.1.174
37.235.1.177
45.33.97.5
172.104.237.57
172.104.49.100
FreeDNS
156.154.70.1
156.154.71.1
2610:a1:1018::1
2610:a1:1019::1
Neustar Security
45.32.36.36
45.77.165.194
Fourth Estate
74.82.42.42Hurricane Electric
195.46.39.39
195.46.39.40
SafeDNS
89.233.43.71
91.239.100.100
2001:67c:28a4::
2a01:3a0:53:53::
UncensoredDNS
208.76.50.50
208.76.51.51
SmartViper
نوٹ: میں نجی رازداری کے عمل، سیکورٹی، افادیت، اور کسی بھی DNS کی خدمات، درج کی یا دوسری صورت میں قابل اعتماد کے بارے میں کوئی دعوی نہیں کرتا. جب آپ کے بارے میں فیصلے کرتے ہیں تو براہ کرم خود اپنی تحقیق کریں.

کیا ویب سائٹس کے علاوہ چیزوں کی حفاظت کے لیے میں CIDRAM استعمال کرسکتا ہوں (مثال کے طور پر، ای میل سرورز، FTP سرورز، SSH سرورز، IRC سرورز، وغیرہ)؟

آپ یہ کر سکتے ہیں (قانونی احساس میں)، لیکن آپ کو نہیں ہونا چاہیے (تکنیکی اور عملی احساس میں). ہمارے لائسنس کو CIDRAM کا استعمال کیا ٹیکنالوجی کی حد تک محدود نہیں ہے. تاہم، CIDRAM ایک "ویب ایپلی کیشن فائر وال" (WAF) ہے، جو ویب سائٹس کی حفاظت کے لیے ہے. دوسرے مقاصد کے لیے استعمال ہونے پر یہ مؤثر یا قابل اعتماد ہونے کا امکان نہیں ہے (کیونکہ یہ دماغ میں دیگر ٹیکنالوجیوں کے ساتھ ڈیزائن نہیں کیا گیا تھا)، عملدرآمد مشکل ہوسکتا ہے، اور غلطیوں اور دیگر مسائل کا خطرہ بہت زیادہ ہے.

مواد ترسیل کے نیٹ ورک یا کیشنگ کی خدمات کا استعمال کرتے ہوئے ایک ہی وقت میں CIDRAM کا استعمال کرتے ہوئے، کیا مسائل ہو گی؟

ممکنہ طور پر. یہ سوال میں خدمت کی نوعیت پر منحصر ہے، اور آپ اس کا استعمال کیسے کر رہے ہیں. عموما، اگر آپ صرف جامد اثاثوں کو پکڑ رہے ہیں تو (تصاویر، CSS، وغیرہ؛ جو وقت کے ساتھ تبدیل نہیں ہوتا ہے)، کوئی مسئلہ نہیں ہونا چاہیے. تاہم، وہاں مسائل ہوسکتے ہیں، اگر آپ ڈیٹا کیشنگ کر رہے ہیں جو عام طور پر متحرک طور پر پیدا ہوجائے تو درخواست کی جاتی ہے، یا اگر آپ POST کی درخواستوں کے نتائج کو پکڑ رہے ہیں (یہ آپ کی ویب سائٹ اور ماحول کو جامد طور پر فراہم کرے گا، اور CIDRAM ایک مستحکم ماحول میں کسی بھی معقول فائدہ فراہم کرنے کے لیے امکان نہیں ہے). اس کے علاوہ، آپ کو استعمال کرنے والے مواد کی ترسیل کے نیٹ ورک یا کیشنگ سروس پر منحصر ہے، اس کے مطابق CIDRAM مخصوص کنفگریشنات کی ضروریات ہوسکتی ہے (آپ کو اس بات کا یقین کرنے کی ضرورت ہوگی کہ CIDRAM صحیح طریقے سے کنفگریشن دیا جائے). غلط کنفگریشن کی وجہ سے غلط جھوٹے مثبت اور دیگر مسائل کا سبب بن سکتا ہے.

کیا CIDRAM DDoS حملوں کے خلاف میری ویب سائٹ کی حفاظت کرتا ہے؟

یہ نہیں کرے گا.

مزید تفصیل میں: 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: کی طرح کچھ شامل کرسکیں. کسی بھی صورت میں، آپ کو سوال میں فائل کا نام تبدیل کرنے کی ضرورت نہیں ہوگی.

"PDO DSN" کیا ہے؟ میں CIDRAM کے ساتھ PDO کیسے استعمال کرسکتا ہوں؟

"PHP Data Objects" (PHP ڈیٹا آبجیکٹ)، "PDO" کا مخفف ہے. یہ PHP کو ایک انٹرفیس فراہم کرتا ہے تاکہ وہ PHP کی ایپلی کیشنز کے ذریعہ استعمال ہونے والے ڈیٹا بیس سسٹم سے رابطہ قائم کرسکیں.

"data source name" (ڈیٹا سورس کا نام)، "DSN" کا مخفف ہے. یہ PDO کو بیان کرتا ہے کہ اسے ڈیٹا بیس سے کیسے جڑنا چاہیے.

CIDRAM میں، آپ کیڈیچنگ مقاصد کے لیے PDO استعمال کرسکتے ہیں. تاکہ اسے صحیح طریقے سے کام کیا جاسکے، کنفگریشن کے ذریعہ اس کو اہل بنائیں، اس کے لیے ایک ڈیٹا بیس بنائیں، اور نیچے بیان کردہ ڈھانچے کے مطابق اپنے ڈیٹا بیس میں ایک نیا ٹیبل بنائیں.

جب ایک ڈیٹا بیس کنکشن کامیابی کے ساتھ ہے، لیکن ضروری جدول موجود نہیں ہے، یہ خود بخود تخلیق کرنے کی کوشش کرے گی. تاہم، اس طرز عمل کا بڑے پیمانے پر تجربہ نہیں کیا گیا ہے اور کامیابی کی ضمانت نہیں دی جاسکتی ہے.

اگر آپ اسے استعمال نہیں کرنا چاہتے ہیں تو، آپ ان ہدایات کو نظرانداز کرسکتے ہیں.

ذیل میں بیان کردہ ڈھانچے میں "cidram" کو اپنے ڈیٹا بیس کے نام کے بطور استعمال کیا گیا ہے، لیکن آپ اپنے ڈیٹا بیس کے لیے جو بھی نام استعمال کرنا چاہ، استعمال کرسکتے ہیں، جب تک کہ وہی نام آپ کی ڈی ایس این کنفگریشن میں نقل کیا جائے.

$ ╔══════════════════════════════════════════════╗ ║ \text{DATABASE} "\text{cidram}" ║ ║ │╔═══════════════════════════════════════════╩═════╗ ║ └╫─\text{TABLE} "\text{Cache}" (\text{UTF}-8) ║ ║ ╠═╪═\text{FIELD}══\text{CHARSET}═\text{DATATYPE}═════\text{KEY}══\text{NULL}═\text{DEFAULT}═╣ ║ ║ ├─"\text{Key}"──\text{UTF}-8───\text{VARCHAR}(128)─\text{PRI}── \times ──── \times ║ ║ ║ ├─"\text{Data}"─\text{UTF}-8───\text{TEXT}───────── \times ──── \times ──── \times ║ ╚══╣ └─"\text{Time}"─ \times ───────\text{INT}(>=10)──── \times ──── \times ──── \times ║ ╚═════════════════════════════════════════════════╝ $

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 آپ کے صارف کے نام اور پاس ورڈ کی طرح ہونا چاہیے جو آپ نے اپنے ڈیٹا بیس کے لیے منتخب کیا ہے.

CIDRAM cronjobs کو مسدود کررہا ہے؛ اس کو کیسے ٹھیک کریں؟

اگر آپ cronjobs کے لیے ایک سرشار فائل استعمال کر رہے ہیں، اگر عام صارف کی درخواستوں کے دوران اس فائل کو کال کرنے کی ضرورت نہیں ہے، اس بات کو یقینی بنانا کہ آپ کے cronjobs کے دوران CIDRAM پر عمل درآمد نہیں کیا جاتا ہے سب سے آسان حل ہے.

اگر یہ ممکن نہیں ہے، اگر آپ کے کرون سرور کا IP پتہ مستقل اور پیش گوئی ہے، اپنی مرضی کے مطابق دستخط فائل میں وائٹ لسٹ دستخط بنانے کی کوشش کریں، یا اس کو سفید کرنے کے لیے ایک معاون اصول بنانے کی کوشش کریں. اگر IP پتہ اکثر تبدیل ہوتا ہے لیکن اسی نیٹ ورک میں رہتا ہے، آپ اپنے ignore.dat میں اس فہرست کو روکنے کے لیے ذمہ دار دستخط والے حصے کا نام درج کرنے کی کوشش کرسکتے ہیں.

اگر آپ نے ان تمام آئیڈیوں کو آزمایا ہے اور ان میں سے کسی نے بھی آپ کے لیے کام نہیں کیا ہے، یا اگر آپ کو یہ جاننے میں مدد کی ضرورت ہو کہ اسے کیسے کریں، CIDRAM کے issues پیج پر ہم سے بات کریں.


۹.۰ سیکشن پریامبل

دستاویزات کا یہ حصہ پیکج کے استعمال اور عمل کے بارے میں ممکنہ قانونی مفکوم بیان کرتا ہے، اور کچھ بنیادی متعلق معلومات فراہم کرتی ہے. بعض صارفین کے لیے شکایت کا یقین کرنے کے لیے یہ ممکن ہو سکتا ہے کہ وہ کسی بھی قانونی تقاضے کے ساتھ موجود ممالک میں موجود ہوسکتے ہیں جس میں وہ کام کرتے ہیں، اور کچھ صارفین اس کی معلومات کے مطابق اپنی ویب سائٹ کی پالیسیوں کو ایڈجسٹ کرنے کی ضرورت ہوسکتی ہے.

سب سے پہلے، سب سے اہم، یاد رکھیں کہ میں (پیکیج کا مصنف) ایک وکیل نہیں ہوں. لہذا، میں قانونی مشورہ فراہم کرنے کے لیے قانونی طور پر قابل نہیں ہوں. اس کے علاوہ، کچھ معاملات میں، قانونی ضروریات مختلف ممالک اور دائرہ کاروں کے درمیان مختلف ہوتی ہیں. یہ مختلف قانونی ضروریات کبھی کبھی متفق ہیں (مثلا، ایسے ممالک جو "رازداری کے حقوق" اور "بھول جانے کا حق"، ایسے ممالک کے مقابلے میں جو "ڈیٹا برقرار رکھنے" کا حق رکھتے ہیں). یہ بھی غور کریں کہ پیکیج تک رسائی مخصوص ممالک یا دائرہ کاروں سے محدود نہیں ہے, اور اس وجہ سے، پیکج کے صارفین جغرافیایی متنوع ہونے کا امکان رکھتے ہیں. ان پوائنٹس پر غور کیا گیا ہے، میں ایسی حیثیت میں نہیں ہوں جو یہ سب کے لیے "قانونی طور پر مطابق" ہونے کا مطلب ہے. تاہم، مجھے امید ہے کہ اس معلومات میں آپ کو یہ فیصلہ کرنے میں مدد ملتی ہے کہ پیکج کے تناظر میں قانونی طور پر مطابق رہنے کے لۓ آپ کو کیا کرنا ہوگا. اگر آپ کو کوئی شبہ ہے، یا اگر آپ کو قانونی نقطہ نظر سے اضافی مدد اور مشورہ کی ضرورت ہو تو، میں ایک قانونی پیشہ ورانہ مشاورت کی سفارش کروں گا.

۹.۱ ذمہ داری

پیکج کسی بھی وارنٹی کے ساتھ فراہم نہیں کی جاتی ہے (لائسنس پہلے ہی اس کا ذکر کرتا ہے). یہ ذمہ داری کے تمام مقاصد پر لاگو ہوتا ہے. پیکج آپ کی سہولت کے لیے فراہم کی جاتی ہے. امید ہے کہ یہ مفید ہو گا، اور یہ آپ کے لیے کچھ فائدہ فراہم کرے گا. تاہم، پیکج کا استعمال کرتے ہوئے یا لاگو آپ کا اپنا فیصلہ ہے. آپ اسے استعمال کرنے یا اسے لاگو کرنے پر مجبور نہیں ہوئے ہیں. جب آپ ایسا کرتے ہو تو، آپ اس فیصلے کے ذمہ دار ہیں. میں اور دوسرا پیکج شراکت دار، آپ کے فیصلوں کے نتائج کے لیے قانونی طور پر ذمہ دار نہیں ہے.

۹.۲ تیسرے فریقوں

اس پیکیج پر منحصر ہے کہ کس طرح پیکج کنفگریشن اور لاگو ہوتا ہے، کچھ صورتو میں، یہ تیسری جماعتوں کے ساتھ معلومات کا اشتراک کرسکتا ہے. کچھ قواعد و ضوابط میں، کچھ دائرہ کار کی طرف سے، یہ "ذاتی طور پر شناختی معلومات" کے طور پر بیان کیا جا سکتا ہے.

تیسری جماعتوں کی طرف سے یہ معلومات کس طرح استعمال کی جاتی ہے، ان کی پالیسیوں کے تابع ہے، اور اس دستاویزات کے دائمے سے باہر ہے. تاہم، اس طرح کے معاملات میں، معلومات کا اشتراک معذور ہوسکتا ہے. اس طرح کے معاملات میں، اگر آپ اسے چالو کرنے کا انتخاب کرتے ہیں تو، یہ آپ کی ذمہ داری ہے کہ آپ کو ان خدشات کے بارے میں معلومات کی رازداری، سیکورٹی اور استعمال کے بارے میں کوئی خدشات کی تحقیقات کی جا سکتی ہے. اگر کوئی شبہ موجود ہے، یا اگر آپ ان تیسری جماعتوں کے انعقاد سے ناخوش ہیں تو، ان تیسری جماعتوں کے ساتھ معلومات کے تمام حصول کو غیر فعال کرنے میں یہ سب سے بہتر ہوسکتا ہے.

شفافیت کے مقصد کے لیے، مشترکہ معلومات کی قسم ذیل میں بیان کی گئی ہے.

۹.۲.۰ میزبان نام تلاش کریں

اگر آپ میزبانوں کے ساتھ کام کرنے کے لیے کسی بھی خصوصیات یا ماڈیولز کا استعمال کرتے ہیں تو، CIDRAM انباؤنڈ درخواستوں کے میزبان نام حاصل کرنے کے قابل ہوسکتا ہے. عام طور پر، یہ ایک DNS سرور سے IP پتہ کے میزبان ناموں کی درخواست کرکے یہ کرتا ہے، یا براہ راست نظام کی طرف سے فراہم کی گئی فعالیت کے ذریعے معلومات کی درخواست کی طرف سے. Google DNS سروس پہلے سے طے شدہ طور پر مقرر کیا جاتا ہے (لیکن یہ کنفگریشن کے ذریعے آسانی سے تبدیل کیا جا سکتا ہے). مطابقت پزیر خدمات کے ساتھ مطابقت پذیری کی جا سکتی ہے، اور ان پر منحصر ہے کہ آپ کس طرح پیکج کو کنفگریشن دیں گے. نظام کے ذریعے براہ راست درخواست کرتے وقت، آپ کو اپنے نظام کے منتظم سے رابطہ کرنے کی ضرورت پڑے گی جس کا تعین کیا جاسکتا ہے. متاثر ماڈیولز سے بچنے یا اس کے مطابق پیکیج کنفگریشن میں ترمیم کرکے CIDRAM میں ہوسٹ نام کی تلاش کی جا سکتی ہے.

متعلقہ کنفگریشن ہدایات:
  • allow_gethostbyaddr_lookup <- general
  • default_dns <- general
  • force_hostname_lookup <- general
  • other <- verification
  • search_engines <- verification
  • social_media <- verification
۹.۲.۱ تلاش انجن اور سوشل میڈیا کی توثیق

جب یہ اختیارات فعال ہوتے ہیں تو، CIDRAM کو تلاش کے انجن اور سوشل میڈیا کی درخواستوں کی صداقت کی توثیق کرنے کی کوشش ہوتی ہے. ایسا کرنے کے لیے، یہ ان پونڈ درخواستوں کے میزبانوں سے IP پتوں کو حل کرنے کی کوشش کرنے کے لیے Google DNS سروس کا استعمال کرتا ہے (اس عمل میں، ان بے حد درخواستوں کے میزبانوں کو سروس کے ساتھ اشتراک کیا جاتا ہے).

متعلقہ کنفگریشن ہدایات:
  • other <- verification
  • search_engines <- verification
  • social_media <- verification
۹.۲.۲ CAPTCHA

CAPTCHA پیکیج کے ذریعہ تعاون یافتہ ہیں. ان کو صحیح طریقے سے کام کرنے کے لیے API کیز کی ضرورت ہوتی ہے. وہ بطور ڈیفالٹ غیر فعال ہیں، لیکن مطلوبہ API چابیاں تشکیل دے کر ان کو فعال کیا جاسکتا ہے. جب فعال ہوجائے تو، خدمت اور CIDRAM یا صارف کے براؤزر کے مابین مواصلت ہوسکتی ہے. اس میں ممکنہ طور پر بات چیت کرنے والی معلومات شامل ہوسکتی ہے جیسے صارف کا IP پتہ، صارف ایجنٹ، آپریٹنگ سسٹم، اور دیگر تفصیلات.

۹.۲.۳ STOP FORUM SPAM

Stop Forum Spam ایک شاندار، آزادانہ طور پر دستیاب سروس ہے جو اسپیمرز سے فورمز، بلاگز، اور ویب سائٹس کی حفاظت کے لیے مدد کرسکتا ہے. یہ یہ معروف اسپیمرز کے ایک ڈیٹا بیس فراہم کر کے کرتا ہے، اور ایک API جو لیورڈج کیا جا سکتا ہے کہ یہ چیک کرنے کے لیے کہ آیا IP پتہ، صارف کا نام، یا ای میل پتہ اس کے ڈیٹا بیس پر درج کیا جاتا ہے.

CIDRAM ایک ماڈیول فراہم کرتا ہے جو اس API کو چیک کرنے کے لۓ لیتا ہے کہ آیا درخواستوں کا IP پتہ مشتبہ اسپیمر سے تعلق رکھتا ہے. جب ماڈیول انسٹال اور چالو ہوجاتا ہے، صارف IP پتے کو خدمت کے ساتھ اشتراک کیا جا سکتا ہے، ماڈیول کی کنفگریشن اور مطلوبہ مقصد کے مطابق.

۹.۲.۴ ABUSEIPDB

AbuseIPDB API کا استعمال کرتے ہوئے بدسلوکی IP پتے کو بلاک کرنے کے لیے CIDRAM ایک اختیاری ماڈیول فراہم کرتا ہے. جب ماڈیول انسٹال اور چالو ہوجاتا ہے، صارف IP پتے کو خدمت کے ساتھ اشتراک کیا جا سکتا ہے، ماڈیول کی کنفگریشن اور مطلوبہ مقصد کے مطابق.

۹.۲.۵ BGPVIEW, IP-API

BGPView API اور IP-API API کا استعمال کرتے ہوئے ASN اور ملکی کوڈ تلاش کرنے کے لیے CIDRAM لیے اختیاری ماڈیول فراہم کرتا ہے. یہ تلاشیں اپنے ASN یا ملک کے اصل کی بنیاد پر درخواستوں کو مسدود کرنے یا وائٹ لسٹ کرنے کی اہلیت فراہم کرتی ہیں. جب ماڈیول انسٹال اور چالو ہوجاتا ہے، صارف IP پتے کو خدمت کے ساتھ اشتراک کیا جا سکتا ہے، ماڈیول کی کنفگریشن اور مطلوبہ مقصد کے مطابق.

۹.۲.۶ PROJECT HONEYPOT

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 <- logging
  • serialised_log <- logging
  • standard_log <- logging
جب یہ ہدایات خالی رہیں تو، اس قسم کی ریکارڈنگ غیر فعال رہیں گے.

۹.۳.۱ CAPTCHA لاگ

جب ایک صارف CAPTCHA مثال کے طور پر مکمل کرنے کی کوشش کرتا ہے، تو ریکارڈ کیا جاتا ہے.

ان ریکارڈوں میں صارف کے IP پتہ، تاریخ اور اس وقت کا واقعہ شامل ہے، اور حیثیت. یہ ریکارڈ عام طور پر اس طرح نظر آتے ہیں:

IP پتہ: x.x.x.x - تاریخ وقت: Day, dd Mon 20xx hh:ii:ss +0000 - CAPTCHA کے ریاست: ایوان کے پاس!
متعلقہ کنفگریشن ہدایات:
  • log <- captcha
۹.۳.۲ سامنے کے آخر لاگ

یہ سامنے کے آخر میں لاگ ان کرنے کی کوشش کرنے سے متعلق ہے. جب سامنے کے آخر میں رسائی کو فعال کیا جاتا ہے، جب صارف کو سامنے کے آخر میں لاگ ان کرنے کی کوشش ہوتی ہے، تو ریکارڈ کیا جاتا ہے.

اس ریکارڈ میں صارف کے 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 <- logging
  • log_rotation_limit <- logging
۹.۳.۴ ٹرنک لاگ

اگر آپ چاہتے ہیں تو، آپ انفرادی ریکارڈز کو چھوٹ سکتے ہیں جب وہ مخصوص سائز سے کہیں زیادہ ہیں.

متعلقہ کنفگریشن ہدایات:
  • truncate <- logging
۹.۳.۵ IP پتہ PSEUDONYMISATION

سب سے پہلے، اگر آپ اصطلاح سے واقف نہیں ہیں، "pseudonymisation" ذاتی اعداد و شمار کی پروسیسنگ سے مراد اس طرح سے ہے کہ یہ کسی بھی مخصوص شخص کو بغیر کسی ضمنی معلومات کی نشان دہی نہیں کی جاسکتی ہے، فراہم کی جاتی ہے کہ اس طرح کی اضافی معلومات علاحدہ طریقے سے برقرار رکھی جاتی ہے اور تکنیکی اور تنظیمی تدابیر کے تابع ہوتے ہیں اس بات کو یقینی بنانے کے لیے کہ ذاتی ڈیٹا کسی قدرتی شخص کو نشان دہی نہیں کی جاسکتی ہے.

مندرجہ ذیل وسائل اس سے مزید تفصیل میں وضاحت کرنے میں مدد کرسکتے ہیں:
کچھ حالات میں، آپ کو کسی بھی PII جمع، عملدرآمد، یا ذخیرہ کرنے کے لیے "anonymisation" یا "pseudonymisation" کو لاگو کرنا قانونی طور پر ضروری ہوسکتا ہے. یہ تصور ابھی کچھ وقت تک وجود میں آیا ہے، لیکن GDPR/DSGVO خاص طور پر "pseudonymisation" کا ذکر اور حوصلہ افزائی کرتا ہے.

اگر آپ چاہتے ہیں تو، CIDRAM لاگ ان کرتے وقت لاگ ان کرتے وقت IP پتے کے لیے یہ کر سکتے ہیں. جب لکھنا لکھنا، IPv4 پتے کے آخری آکٹیٹ اور IPv6 پتے کے دوسرے حصے کے بعد سب کچھ، "x" کی طرف سے نمائندگی کی جائے گی.

نوٹ: CIDRAM کی IP ٹریکنگ کی خصوصیت اس کی صلاحیت نہیں ہے. اگر یہ آپ کے لیے ایک مسئلہ ہے، IP ٹریکنگ کو مکمل طور پر غیر فعال کرنے کے لیے یہ سب سے بہتر ہو سکتا ہے.

متعلقہ کنفگریشن ہدایات:
  • pseudonymise_ip_addresses <- legal
۹.۳.۶ لاگ ان معلومات کو چھوڑ دیں

اگر آپ مخصوص قسم کی معلومات کو مکمل طور پر لاگ ان کرنے سے روکنا چاہتے ہیں تو، آپ ایسا کرسکتے ہیں. کنفیگریشن پیج پر، براہ کرم fields کنفیگریشن ڈائریکٹیو سے رجوع کریں تاکہ یہ کنٹرول کیا جا سکے کہ کون سے فیلڈز لاگ انٹریز میں ظاہر ہوتے ہیں اور "رسائی نہیں ہوئی" صفحہ پر.

fields

نوٹ: IP پتے کے لیے pseudonymisation کا استعمال کرنے کی کوئی وجہ نہیں ہے جب IP پتے کو مکمل طور پر لاگ ان سے لے کر.

متعلقہ کنفگریشن ہدایات:
  • fields <- general
۹.۳.۷ اعداد و شمار

CIDRAM اعداد و شمار کو ٹریک کر سکتے ہیں، جیسے کہ کسی مخصوص وقت سے کتنے بلاک واقعات یا CAPTCHA مثال موجود ہیں. یہ خصوصیت ڈیفالٹ کے ذریعہ غیر فعال ہے، لیکن پیکیج کی کنفگریشن کے ذریعے فعال کیا جا سکتا ہے. یہ خصوصیت صرف واقعات کی تعداد کو ٹریک کرتا ہے. اس میں کوئی مخصوص معلومات شامل نہیں ہے، لہذا اسے PII کے طور پر نہیں جانا چاہیے.

متعلقہ کنفگریشن ہدایات:
  • statistics <- general
۹.۳.۸ خفیہ کاری

CIDRAM اس کے لاگ ان یا کیش کو خفیہ نہیں کرتا. یہ مستقبل میں متعارف کرایا جا سکتا ہے، لیکن فی الحال اس کی کوئی مخصوص منصوبہ نہیں ہے. اگر آپ غیر قانونی شدہ تیسری جماعتوں کے بارے میں فکر مند ہیں تو CIDRAM میں حساس معلومات تک رسائی حاصل ہے، میں سفارش کرتا ہوں کہ عام طور پر قابل رسائی مقام پر CIDRAM انسٹال نہیں کیا جائے گا (مثال کے طور پر، public_html میں انسٹال نہ کریں) اور اس بات کو یقینی بنائیں کہ مناسب حد تک محدود پابندیوں کو نافذ کیا جائے. اگر یہ آپ کے خدشات کو حل کرنے کے لیے کافی نہیں ہے تو پھر CIDRAM کو کنفگریشن دیں تاکہ حساس معلومات جمع نہیں کی جائے گی (جیسے جیسے، لاگ ان کو غیر فعال کرکے).

۹.۴ کوکی

CIDRAM کو دو مقامات پر کوکیز کا تعین کرتا ہے. سب سے پہلے، اس بات پر منحصر ہے کہ کس طرح lockto کو کنفیگر کیا گیا ہے، CIDRAM ایک کوکی سیٹ کر سکتا ہے تاکہ یاد رہے کہ صارف نے کیپچا مکمل کیا ہے. دوسرا، صارف کو سامنے کے آخر میں لاگ ان ہونے پر CIDRAM ایک کوکی سیٹ کرتا ہے (تصدیق کے مقاصد کے لیے).

دونوں صورتوں میں، صارف کو پہلے سے ہی کوکیز کے بارے میں خبردار کیا جاتا ہے. کوکیز کہیں اور نہیں بنائے جاتے ہیں.

نوٹ: "پوشیدہ" CAPTCHA APIs کو کچھ علاقوں میں کوکی قوانین سے مطابقت نہیں ہوسکتی ہے اور ایسے قوانین کے تابع کسی بھی ویب سائٹ سے ان کو پرہیز کرنا چاہیے. اس کے بجائے دوسرے فراہم کردہ API استعمال کرنے کا انتخاب کرنا، یا صرف مکمل طور پر CAPTCHA کو غیر فعال کرنا بہتر ہوگا.

متعلقہ کنفگریشن ہدایات:
  • lockto <- captcha
  • api <- captcha

۹.۵ مارکیٹنگ اور اشتہارات

CIDRAM مارکیٹنگ یا اشتہارات کے مقاصد کے لیے کسی بھی معلومات جمع یا عمل نہیں کرتا ہے. یہ کسی جمع کردہ یا لاگ ان معلومات سے کوئی فائدہ نہیں فروخت کرتا ہے. CIDRAM ایک تجارتی ادارہ نہیں ہے، اور کسی بھی تجارتی مفادات سے متعلق نہیں ہے، لہذا ان کاموں کو کوئی احساس نہیں ہوگا. اس منصوبے کی شروعات کے بعد یہ معاملہ رہا ہے، اور آج ہی مقدمہ جاری ہے.

۹.۶ رازداری کی پالیسی

بعض اوقات آپ کو قانون کی طرف سے آپ کی ویب سائٹ پر اپنی جگہ پر اپنی رازداری کی پالیسی پر ایک لنک ظاہر کرنے کی ضرورت ہوسکتی ہے. اس بات کو یقینی بنانے کے لیے صارفین کو آپ کی رازداری کے طریقوں کے بارے میں مطلع کیا جاسکتا ہے، جو آپ جمع کرتے ہیں، اور آپ اس معلومات کے ساتھ کیا کرتے ہیں. CIDRAM کے "رسائی نہیں ہوئی" کے صفحے پر اس لنک کو شامل کرنے کے قابل ہونے کے لۓ، آپ کی رازداری کی پالیسی کے پتہ کی وضاحت کرنے کے لیے ایک کنفگریشن کا اختیار فراہم کیا جاتا ہے.

نوٹ: یہ سختی سے سفارش کی جاتی ہے کہ آپ کی رازداری کی پالیسی کا صفحہ CIDRAM کی حفاظت کے پیچھے نہیں ہے. اگر CIDRAM آپ کی پرائیویسی پالیسی کی حفاظت کرتا ہے تو، جب وہ آپ کی رازداری کی پالیسی پر لنک پر کلک کریں تو صارفین کو مسدود کیا جائے گا. مثالی طور پر، آپ کو اپنی رازداری کی پالیسی کی ایک مستحکم کاپی، جیسے HTML صفحہ یا سادہ متن فائل سے منسلک ہونا چاہیے.

متعلقہ کنفگریشن ہدایات:
  • privacy_policy <- legal

۹.۷ GDPR/DSGVO

GDPR یورپی یونین کا ایک ضابطہ ہے جو 25 مئی، 2018 تک اثر انداز ہوتا ہے. ریگولیشن کا بنیادی مقصد یہ ہے کہ یورپی یونین کے شہریوں اور باشندوں کو ان کے اپنے ذاتی ڈیٹا سے متعلق قابو پانے، اور پرائیویٹ اور ذاتی ڈیٹا کے بارے میں یورپی یونین کے اندر ریگولیشن کو متحد کرنا.

ریگولیشن کسی بھی EU کے "اعداد و شمار کے مضامین" (کسی بھی شناخت یا شناختی قدرتی شخص) کے "ذاتی طور پر شناختی معلومات" کی پروسیسنگ سے متعلق مخصوص اجزاء پر مشتمل ہے. تعمیل کرنے کے لیے، کمپنیوں، عمل، اور متعلقہ نظام، "ڈیزائن کی طرف سے رازداری" کو لاگو کرنا لازمی ہے، سب سے زیادہ ممکن راز رازداری کی کنفگریشنات کا استعمال کرنا ضروری ہے، کسی ذخیرہ یا پروسیسنگ معلومات کے لیے حفاظتی انتظامات کو لاگو کرنا ضروری ہے (بشمول، لیکن تک محدود نہیں، "pseudonymisation" اور "anonymisation")، واضح طور پر ان اعداد و شمار کی اقسام کا اعلان کرنا چاہیے جو وہ جمع کرتے ہیں، وہ کس طرح کے سببوں کے لیے، اس کے عمل کو کس طرح، وہ کتنی عرصے تک اسے برقرار رکھتی ہیں، اور اگر وہ اس ڈیٹا کو کسی بھی تیسری پارٹی کے ساتھ شریک کریں، اعداد و شمار کی اقسام، کیسے، کیوں، اور اسی طرح کی اقسام.

اعداد و شمار پر عملدرآمد نہیں کیا جاسکتا جب تک کہ ایسا کرنے کے لیے قانونی بنیاد نہ ہو، قواعد و ضوابط کے مطابق. عام طور پر، اس کا مطلب یہ ہے کہ یہ قانونی ذمہ داریوں کے مطابق ہونا ضروری ہے، اور صرف واضح ہونے کے بعد، اچھی طرح سے مطلع رضامندی کے اعداد و شمار سے حاصل کی گئی ہے.

وقت میں، قوانین تبدیل کر سکتے ہیں. لہذا، پرانے معلومات کو پھیلانے سے بچنے کے لۓ، یہ مستند ذریعہ سے سیکھنا بہتر ہوگا. اگر میں براہ راست یہاں معلومات شامل ہوں تو، یہ تاریخ سے باہر ہوسکتا ہے.

مزید معلومات سیکھنے کے لیے کچھ سفارش کردہ وسائل:

۱۰. پچھلے بڑے ورژن سے اپ گریڈ کرنا

۱۰.۰ CIDRAM v3 میں اپ گریڈ کرنا

v3 اور پچھلے بڑے ورژن کے درمیان اہم فرق ہیں. جس طرح سے انٹری پوائنٹس کام کرتے ہیں، جس طرح سے ماڈیولز کی ساخت ہوتی ہے، اور جس طرح سے اپڈیٹر v3 کے لیے کام کرتا ہے وہ اس طرح سے مختلف ہے جس طرح ان چیزوں نے پچھلے بڑے ورژنز کے لیے کام کیا. ان اختلافات کی وجہ سے، پچھلے بڑے ورژنز سے v3 میں اپ گریڈ کرنے کا بہترین طریقہ یہ ہوگا کہ ایک تازہ انسٹالیشن انجام دی جائے.

اگر آپ اپنی کنفگریشن اور اپنے معاون قواعد کو برقرار رکھنا چاہتے ہیں، اپ گریڈ کا عمل شروع کرنے سے پہلے، فرنٹ اینڈ بیک اپ پیج پر جائیں. وہاں سے، کنفگریشن اور معاون قواعد برآمد کیے جا سکتے ہیں. برآمد کرنے سے فائل ڈاؤن لوڈ ہو جائے گی. نئے بڑے ورژن میں اپ گریڈ کرنے کے بعد، اس فائل کو پہلے سے برآمد شدہ ڈیٹا کو انسٹالیشن میں درآمد کرنے کے لیے استعمال کیا جا سکتا ہے.

ماڈیولز کی ساخت میں تبدیلیوں کی وجہ سے، پچھلے بڑے ورژنز کے لیے بنائے گئے ماڈیولز کو v3 کے لیے صحیح طریقے سے کام کرنے کے لیے دوبارہ لکھنے کی ضرورت ہوگی. براہ راست منتقلی کام نہیں کرے گی. واقعات کا بھی یہی حال ہے.

دستخطی فائلوں کے ڈھانچے کا طریقہ تبدیل نہیں ہوا ہے، اس لیے دستخطی فائلیں جو پچھلے بڑے ورژن کے لیے ہیں، بغیر کسی پریشانی کے براہ راست v3 میں منتقل کی جا سکتی ہیں.

ماڈیولز، دستخطی فائلیں، اور ایونٹس میں سے ہر ایک کی اپنی مخصوص ڈائریکٹریز ہوتی ہیں، جو کہ v3 کے بعد ایک نیا اضافہ ہے (لہذا، v3 کے لیے، وہ ہر ایک vault کی جڑ کے بجائے اپنی اپنی مخصوص ڈائریکٹریوں میں جائیں گے).

پچھلے بڑے ورژنز کے لیے عوامی طور پر دستیاب دستخطی فائلوں، ماڈیولز، اور بلاک لسٹوں میں سے کچھ کو فرسودہ کر دیا گیا ہے، اس لیے ہر چیز v3 کے لیے دستیاب نہیں ہوگی. زیادہ تر معاملات میں، v3 کے بعد سے شامل کردہ نئی خصوصیات اور بنیادی فعالیت کی وجہ سے، بہرحال ان کی ضرورت نہیں ہوگی.

معاون قوانین کے ڈھانچے کے طریقے میں کچھ ٹھیک ٹھیک تبدیلیاں ہیں، اور کنفگریشن میں تبدیلیاں ہیں، لیکن اگر آپ فرنٹ اینڈ بیک اپ صفحہ پر درآمد/برآمد خصوصیت استعمال کرتے ہیں، تو آپ کو دستی طور پر کچھ کرنے کی ضرورت نہیں ہوگی. درآمد کرتے وقت، CIDRAM جانتا ہے کہ کس چیز کی ضرورت ہے، اور اسے آپ کے لیے خود بخود سنبھال لے گا.

v3 کے ذریعے متعارف کرائی گئی تبدیلیوں کی فہرست کے لیے (مثال کے طور پر شامل کردہ خصوصیات، خصوصیات کو ہٹایا گیا، وغیرہ)، v3 چینج لاگ سے رجوع کریں.

۱۰.۱ CIDRAM v3 سے پہلے والے ورژن سے CIDRAM v4 میں اپ گریڈ کرنا

اوپر سے رجوع کریں: ایک تازہ تنصیب کی سفارش کی جاتی ہے.

۱۰.۲ CIDRAM v3 سے CIDRAM v4 میں اپ گریڈ کرنا

۱. سب سے پہلے، اپ ڈیٹس کے صفحے پر جائیں، اور اگر کوئی اپ ڈیٹس دستیاب ہیں، تو ان سب کو انسٹال کرنا یقینی بنائیں. یہ اپ گریڈنگ کے لیے تمام ضروری کوڈ کی دستیابی کو یقینی بناتا ہے اور اپڈیٹر کے لیے درکار کام کی مقدار کو کم کرنے میں مدد کرتا ہے.

۲. کنفیگریشن پیج پر جائیں اور remotes⬅frontend تلاش کریں. فہرست میں، جہاں آپ v3 دیکھتے ہیں، اسے v4 میں تبدیل کریں. اپنی کنفگریشن کو بچانے کے لیے اپ ڈیٹ پر کلک کریں. یہ تبدیلی اپڈیٹر سے کہتی ہے کہ اپ ڈیٹس تلاش کرتے وقت درست ورژن کو نشانہ بنائے.

۳. بیک اپ صفحہ پر جائیں. برآمد کو منتخب کریں، کنفگریشن کے لیے، اعداد و شمار کے لیے، اور معاون اصولوں کے لیے چیک باکس پر نشان لگائیں، اور پھر بیک اپ ڈاؤن لوڈ کرنے کے لیے ٹھیک کو دبائیں. کچھ تبدیلیاں ہوئی ہیں. مثال کے طور پر، "لاگ نہ کریں" کی کارروائی کو معاون قواعد سے ہٹا دیا گیا ہے (اسی چیز کو حاصل کرنے کے بجائے "لاگنگ کو دبانا" کا اختیار استعمال کیا جا سکتا ہے). آپ کو یہ بیک اپ اپ گریڈ کرنے کے بعد واپس CIDRAM میں درآمد کرنا ہوگا.

۴. اپ ڈیٹس کے صفحے پر واپس جائیں. نئے بڑے ورژن کی تازہ کاریوں کو اب ظاہر ہونا چاہیے. ٹائم آؤٹ سے بچنے کے لیے، سب کو اپ ڈیٹ کرنے سے پہلے، پہلے صرف "کور" یا "فرنٹ اینڈ" کو اپ ڈیٹ کرنے کی کوشش کریں (جیسا کہ دونوں ایک دوسرے کے باہمی انحصار کے طور پر، کسی کو اپ ڈیٹ کرنے سے دونوں کو خود بخود اپ ڈیٹ ہونا چاہیے). چونکہ صفحہ کا ڈھانچہ اور CSS اسٹائل میں بڑے ورژن کے درمیان نمایاں تبدیلی آئی ہے، یہ اپ ڈیٹ کرنے کے بعد ابتدائی طور پر ٹوٹا ہوا دکھائی دے سکتا ہے؛ یہ نہیں ہے. کسی دوسرے صفحہ پر جائیں اور سخت ریفریش کرنے کی کوشش کرنے کے لیے Ctrl+F5 دبائیں (یعنی ایک ریفریش جس کے ذریعے براؤزر اپنے کیشے پر انحصار کرنے کے بجائے CSS اسٹائلنگ اور دیگر پیری فیرلز کی تازہ کاپی لاتا ہے). اس کے بعد صفحہ کی ساخت اور CSS اسٹائل صحیح طریقے سے ظاہر ہونا چاہیے. اگر ایسا نہیں ہوتا ہے تو اپنے براؤزر کی کیش کو صاف کرنے کی کوشش کریں.

۵. اس کے ساتھ، آپ باقی سب کچھ اپ ڈیٹ کر سکتے ہیں. اپ ڈیٹس کے صفحہ پر واپس جائیں، اور اگر آپ کو صفحہ کے اوپری حصے میں بٹن نظر آتا ہے، تو سبھی کو اپ ڈیٹ کریں پر کلک کریں.

۶. اس بات کو یقینی بنانے کے لیے کہ کوئی دیرپا خراب اپ ڈیٹس یا کرپٹ فائلیں نہیں ہیں، اور یہ یقینی بنانے کے لیے کہ سب کچھ ویسا ہی ہے جیسا کہ ہونا چاہیے، تمام مرمت پر کلک کریں. بہت شاذ و نادر ہی یہ ایک حقیقی مسئلہ ہونا چاہیے، لیکن اسے محفوظ طریقے سے چلانا بہتر ہے.

۷. بیک اپ صفحہ پر واپس جائیں. درآمد کو منتخب کریں، کنفگریشن کے لیے، اعداد و شمار کے لیے، اور معاون اصولوں کے لیے چیک باکس پر نشان لگائیں، فائل کو منتخب کرنے کے لیے بٹن پر کلک کریں، پہلے ڈاؤن لوڈ کیے گئے بیک اپ کو تلاش کریں اور منتخب کریں، اور اس بیک اپ کو درآمد کرنے کے لیے OK کو دبائیں. CIDRAM تبدیلیوں کو ایڈجسٹ کرنے کے لیے ضروری ایڈجسٹمنٹ خود بخود انجام دے گا.

۸. آپ نے اپ گریڈ مکمل کر لیا ہے. نئے بڑے ورژن میں دستخطی فائلوں، ماڈیولز، یا ایونٹس میں کوئی تبدیلی نہیں کی گئی ہے، لہذا آپ کو اپ گریڈ کرنے کے لیے اس کے بارے میں فکر کرنے کی ضرورت نہیں ہے. اس کے بعد، آپ نئے بڑے ورژن (مثلاً، نئی متعارف کردہ خصوصیات کے لیے) کے ذریعے متعارف کرائی گئی تبدیلیوں کی وجہ سے کنفگریشن کے صفحے کو مختصراً دریافت کرنا چاہیں گے.

v4 کے ذریعے متعارف کرائی گئی تبدیلیوں کی فہرست کے لیے (مثال کے طور پر شامل کردہ خصوصیات، خصوصیات کو ہٹایا گیا، وغیرہ)، v4 چینج لاگ سے رجوع کریں.


آخری تازہ کاری: ۶ جون ۲۰۲۶ (۲۰۲۶.۰۶.۰۶).