پرش به محتوا

رشته ی جادویی

از ویکی‌پدیا، دانشنامهٔ آزاد

در برنامه‌نویسی کامپیوتر، یک رشته جادویی ورودی‌ای است که برنامه‌نویس باور دارد هرگز توسط کاربر فراخوانی نخواهد شد و باعث فعال شدن عملکردهای پنهان می‌شود. کاربر این برنامه احتمالاً ورودی‌ای را ارائه می‌دهد که در بیشتر موارد پاسخ مورد انتظار را می‌دهد. با این حال، اگر کاربر بی خبرانه آن ورودی به اصطلاح جادویی را فراهم کند، باعث فعال شدن عملکرد های داخلی می‌شود که در این مواقع پاسخ برنامه اغلب برای کاربر بسیار غیرمنتظره است (بنابراین “جادویی” به نظر می‌رسد).[۱]

پیش زمینه[ویرایش]

معمولاً، پیاده‌سازی رشته‌های جادویی به دلیل محدودیت‌های زمانی است. توسعه‌دهنده باید به جای اینکه عمیق‌تر به یک مشکل بپردازد و راه حل بهتری پیدا کند، راه حل سریعی پیدا کند.

به عنوان مثال، هنگام تست کردن یک برنامه که جزئیات شخصی کاربر را می‌گیرد و شماره کارت اعتباری آن‌ها را تأیید می‌کند، یک توسعه‌دهنده ممکن است تصمیم بگیرد یک میانبر رشته جادویی اضافه کند که با وارد کردن ورودی بعید "***" به عنوان شماره کارت اعتباری، باعث شود برنامه خودکار به گونه‌ای پیش برود که گویا کارت معتبر است، بدون اینکه وقت صرف تأیید آن کند. اگر توسعه‌دهنده فراموش کند رشته جادویی را حذف کند، و یک کاربر نهایی برنامه به طور تصادفی "***" را به عنوان شماره کارت اعتباری موقت هنگام پر کردن فرم وارد کند، کاربر ناخواسته عملکرد پنهان را فعال می‌کند.

تحلیل[ویرایش]

شرایط / مسائل مربوط به علت[ویرایش]

غالباً محدودیت‌های زمانی قابل توجهی وجود دارد که از ابتدای دخالت توسعه‌دهنده در یک پروژه خارج از کنترل او است. مشکلات رایجی که ممکن است به این ضد الگو منجر شود عبارتند از: Null != null[۲] یا هر تغییری که در آن یک نوع داده به صورت بیت به بیت با نوعی که قرار است یکسان باشد، مقایسه نمی‌شود. این مشکلی است که حتی درون یک محیط توسعه یکسان (زبان برنامه‌نویسی و کامپایلر یکسان) نیز ممکن است رخ دهد. این مشکل سابقه‌ای طولانی برای انواع عددی و بولین دارد و اکثر کامپایلرها این را به خوبی مدیریت می‌کنند (با هشدارها و خطاهای قابل اجرا، حل پیش‌فرض و غیره…). انواع پوچ پذیر مانند رشته‌ها، دشواری تاریخی تعاریف متفاوت برای NULL را دارند. خطاها/هشدارهای تولید شده اغلب عمومی هستند یا یک خطای پیش‌فرض ‘بهترین تطبیق’ که پیام آن واقعاً توصیف نمی‌کند که چه اتفاقی در حال رخ دادن است. اگر توسعه‌دهنده نتواند سرنخ‌های کافی برای ردگیری مشکل از طریق عیب‌زدایی به دست آورد، استفاده از میانبر و زدن کد یک رشته ‘پیش‌فرض’، ممکن است تنها راه برای حفظ برنامه زمان‌بندی پروژه باشد. یک راه حل برای این مشکل ممکن است استفاده از الگوی شئ Null باشد.[۳]

برنامه نویسی به سمت یک گوشه. گاهی اوقات یک طراحی سر راست و حتی ساده به نظر می‌رسد اما معلوم می‌شود که دارای یک نقص منطقی است، که به ورودی‌های احتمالی کاربر بستگی دارد، به دلیل شرایط غالباً پیش‌بینی نشده در انتهای توسعه برنامه‌ریزی شده. بنابراین، یک توسعه‌دهنده ممکن است احساس نیاز کند که ورودی کاربر را، با مجوزهای امنیتی/عملیاتی خاص برای مقابله با چنین شرایطی پیاده‌سازی کند. این موضوع می‌تواند به ویژه کنایه آمیز باشد زیرا گاهی اوقات معلوم می‌شود که یک طراحی قوی‌تر از ابتدا احتمالاً فضای کافی برای رسیدگی به نقص را فراهم می‌کرد. با این حال، این شاید زمان زیادی برای پیاده‌سازی لازم داشت و ممکن بود با مفهوم مهندسی پایه ی اصل سادگی، که به معنی ساده نگه داشتن یک طراحی و پیاده‌سازی آن و تنها برآورده کردن نیازهای ضروری اولیه آن است، در تضاد باشد.

اجازه دسترسی خارجی به یک فلگ سراسری .[۴] اعتماد بیش از حد به اینکه یک فلگ گلوبال هرگز به طور تصادفی یا خرابکارانه تنظیم نشود (غالباً یک فرض منطقی)، چنین پیاده‌سازی را برای اهداف تست و عیب‌زدایی توجیه می‌کند، به ویژه برای برنامه‌های کوچک با رابط‌های کاربری ساده. با این حال، اگر گسترش برنامه قابل توجه باشد، معمولاً فقط مسئله زمان است قبل از اینکه کسی آن فلگ را مقدار دهی کند. یک راه حل واضح این است که هرگز از یک متغیر گلوبال به چنین شکلی استفاده نشود. یک توسعه‌دهنده همچنین ممکن است فلگ را بسته به شرایطی قابل دسترسی کند. بنابراین، رشته جادویی خود به خود توسط برنامه مانند هر ورودی دیگر مورد برخورد قرار می‌گیرد.[۵] کاربر باید سپس تنظیمات را بازتولید کند و همچنین مجموعه‌ای از رویدادهای دیگر را تولید کند که رابط کاربری به طور محتاطانه اجازه دهد، تا فلگ مقدار دهی شود؛ سناریویی بسیار نامحتمل‌تر، هرچند همچنان ممکن.

فرمت کردن سرسختانه[ویرایش]

محدود کردن فرمت ورودی یک راه حل ممکن برای نگهداری (رفع اشکال) است. در واقع، این به معنای اعتبارسنجی اطلاعات ورودی برای بررسی این است که آیا اطلاعات در فرمت صحیح هستند یا نه که به منظور کاهش احتمال کشف رشته جادویی توسط کاربر انجام میشود. مثال‌ها شامل اعتبارسنجی یک شماره تلفن برای اطمینان از این است که فقط شامل اعداد (و احتمالاً فضاها و علائم نگارشی به میزان محدود) باشد یا بررسی اینکه نام یک شخص دارای نام و نام خانوادگی (و به طور مناسب با حروف بزرگ) است. یک استثناء برای رشته جادویی در کد اعتبارسنجی وجود دارد تا توسط اعتبارسنجی رد نشود. انتظار می‌رود که از آنجایی که کاربر به سرعت متوجه اجرای سختگیرانه فرمت خواهد شد، به ذهن کاربر خطور نخواهد کرد که سعی در وارد کردن رشته‌ای که مطابق با فرمت نیست داشته باشد. بنابراین، بسیار بعید است که کاربر سعی کند برای رشته ای جادویی وارد کند . مانند هر فرآیند اعتبارسنجی ورودی، مهم است اطمینان حاصل شود که فرمت به گونه‌ای محدودکننده نباشد که به طور ناخواسته استفاده از برنامه توسط برخی کاربران را محدود کند. یک مثال برای این، محدود کردن ورود شماره تلفن یا کد پستی [۶] براساس سامانه یک کشور (به عنوان مثال، نیاز داشتن همه کاربران به دادن یک زیپ‌کد پنج رقمی) است، که باعث مشکلات برای کاربرانی است که در سایر کشور‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌ها زندگی میکنند.

پیاده سازی هدفمند[ویرایش]

همانطور که اغلب در مورد الگوهای ضد الگو صادق است، سناریوهای خاصی وجود دارد که در آن‌ها رشته‌های جادویی یک راه حل صحیح برای پیاده‌سازی هستند. مثال‌ها شامل کدهای تقلب[۷] و ایستراگ ها هستند. علاوه بر این، مواردی وجود دارد که کاربران رشته‌های جادویی را اختراع می‌کنند و سیستم‌هایی که برای پذیرش آن‌ها کد زده نشده‌اند می‌توانند نتایج غیرمنتظره‌ای مانند بدون پلاک تولید کنند.[۸]

حوادث[ویرایش]

در ادامه فهرستی از برخی حوادث شناخته شده که استفاده از رشته جادویی باعث مشکلات شده است، آورده شده است.

  • در چندین مورد مختلف، رانندگانی که پلاک‌های شخصی سازی شده بر روی وسایل نقلیه خود داشتند، جریمه های ترافیکی نادرست دریافت کرده‌اند. در سیستم‌های صدور جریمه، وقتی افسران پلیس برای یک خودرو بدون پلاک، جریمه ترافیک را پر می‌کردند، “NOPLATE”، “NOTAG”، “MISSING” یا موارد مشابه را می‌نوشتند. این مسئله باعث مشکلات شد وقتی رانندگان پلاک‌های واقعی با این مقادیر گرفتند و در نتیجه شروع به دریافت تعداد زیادی بلیط ترافیک مخصوص به وسایل نقلیه بدون پلاک کردند[۸]
  • در سال 1999، هکرها یک نقص امنیتی در Hotmail را فاش کردند که به هر کس اجازه می‌داد با استفاده از رمز عبور ‘eh’ وارد هر حساب Hotmail شود که در آن زمان به عنوان “گسترده‌ترین حادثه امنیتی در تاریخ وب” نامیده شده بود.[۹]
  • افراد با نام خانوادگی Null گزارش داده‌اند که در استفاده از سامانه‌های آنلاین با مشکلات مختلفی روبرو شده‌اند، مانند عدم توانایی در رزرو بلیط هواپیما، استفاده از وب سایت‌های مالیات دولت، یا پرداخت قبض‌های خدمات عمومی.[۱۰] مشکل از این جا نشأت می‌گیرد که این سامانه‌ها نام آن‌ها را با اشاره‌گر هیچ‌مقدار (null pointer) اشتباه می‌گیرند. بسته به سامانه، این مشکل ممکن است باعث شود که سامانه نام آن‌ها را نشان ندهد، به کاربر بگوید که نام دیگر وارد کنید (گاه با پیغام ادعای اینکه فضای نام خالی گذاشته شده است)، یا پیغام خطا نشان دادن.[۱۱]


References[ویرایش]

  1. Chris Falter (2008-03-06), A Good Solution for Magic String Data, Egghead Cafe Tuturiols, retrieved 2009-05-11
  2. Wang Lam (2003-05-21), The Behavior of NULL's in SQL, Stanford University, retrieved 2009-05-13
  3. Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates; 2004, Head First Design Patterns, 1st ed., O'Reilly, Chapter 6, pg. 214, The Command Pattern, شابک ‎۰−۵۹۶−۰۰۷۱۲−۴, شابک ‎۹۷۸−۰−۵۹۶−۰۰۷۱۲−۶
  4. James McCaffrey (2009), Test Automation for ASP.NET Web Apps with SSL, Microsoft, retrieved 2009-05-13
  5. Andrew Cumming; 2007, SQL Hacks, 1st ed., O'Reilly, pg. 174, Prevent an SQL Injection Attack, شابک ‎۰−۵۹۶−۵۲۷۹۹−۳, شابک ‎۹۷۸−۰−۵۹۶−۵۲۷۹۹−۰
  6. Brian Knight, Allan Mitchell, Darren Green, Douglas Hinson, Kathi Kellenberger; 2005, Professional SQL server 2005 integration services, 1st ed., John Wiley and Sons, Chapter 5, pg. 129, Handling Dirty Data, شابک ‎۰−۷۶۴۵−۸۴۳۵−۹, شابک ‎۹۷۸−۰−۷۶۴۵−۸۴۳۵−۰
  7. Sezen, Tonguc Ibrahim; Isikoglu, Digdem (2007-04-27). "From Ozans to God-Modes: Cheating in Interactive Entertainment From Different Cultures" (PDF). p. 8. Retrieved 2009-01-24.
  8. ۸٫۰ ۸٫۱ "What Happens when Your License Plate Says 'NO PLATE'?". October 30, 1999.
  9. Glave, James (August 30, 1999). "Hotmail Hackers: 'We Did It'". Wired. Condé Nast. Retrieved 2007-11-03.
  10. Baraniuk, Chris (25 March 2016). "These unlucky people have names that break computers". بی‌بی‌سی آنلاین (به انگلیسی). Retrieved 30 January 2022.
  11. Null, Christopher (5 November 2015). "Hello, I'm Mr. Null. My Name Makes Me Invisible to Computers". Wired. Retrieved 30 January 2022.