سیستم رجیستر و لاگین (یک پروژهء تقریبا ناتمام!)

[eshpilen]

این یک پروژهء سیستم رجیستر و لاگین هست که چند سال قبل بعنوان اولین پروژم بعد از یادگیری PHP انجام دادم.
اون زمان بیشتر از این پیش نرفتم ولی بنظرم برنامهء حرفه ای و قابل استفاده ای هست اگر کمی بیشتر روش کار بشه.

چیزهایی که کم داره و میشه بهش اضافه کرد مثلا اینهاست:

- تایید صحت ایمیل از طریق کلیک بر روی لینک فعال سازی
- تغییر کلید لاگین ذخیره شده در کوکی در هربار لاگین شدن (برای امنیت بیشتر و جلوگیری از سرقت و سوء استفادهء طولانی مدت از کوکی)
- فارسی سازی و یوزرفرند کردن بیشتر پیامهای ارائه شده به کاربر
- برطرف کردن حدقل یک حفرهء امنیتی احتمالی (هنوز درجهء خطرش رو بررسی نکردم)
- اضافه و اصلاح بعضی روشهای کانفیگ برای راحتی بیشتر
- اضافه کردن salt برای ذخیرهء پسوردها در دیتابیس
- قفل شدن IP کاربر به مدت خاصی بعد از چند بار تلاش ناموفق در ورود
...؟

راستی اگر میخواید تستش کنید حتما در ریشهء وب قرارش بدید. البته قراردادنش در دایرکتوری های دیگر هم ممکن هست ولی چون نیاز به دستکاری در چند نقطهء کد داره مشکله (اضافه کردن یک گزینهء پیکربندی که گفتم برای همین مد نظرم بود)

برنامه چند اسکریپت PHP اضافه همراه خودش داره که ضروری نیستن ولی برای تست و راحت کردن بعضی کارها یا بعنوان نمونه کد همراهش گذاشتم.
حالا توضیح بیشتر بماند چون چند سال پیش نوشتم و خودم حضور ذهن ندارم الان. اگر کسی سوالی داشت بپرسه حتما جواب میدم (وگرنه که صرف نمیکنه :لبخند:).

[eshpilen]

پستهای بعدی ای که درج میکنم مال همون زمان هستن که این پروژه رو در یک فروم دیگه درج کرده بودم.
چون این پستها حاوی اطلاعات مفید فنی هستن، اونها رو بصورت نقل قول درج میکنم.

[eshpilen]

کد آپدیت شد.

امکانات جدیدی به سیستم اضافه شد؛ تعدادی باگ جزیی غیرامنیتی یا بهینه سازی صورت گرفت.
قبلا سیستم اتولاگین با سشن به کاملی و هوشمندی وضعیت فعلی نبود. اگر فایل سشن از روی سرور پاک میشد (بطور مثال رفتگر سیستم سشن پی اچ پی ممکنه اینکار رو انجام بده) سیستم تا لاگین دستی بعدی به حالت کوکی احراز هویت معمولی که مستلزم ارتباط با دیتابیس هست سویچ میکرد.
اما حالا با از بین رفتن سشن، چه از طرف سرور و چه از طرف کلاینت (پاک شدن کوکی سشن)، اگر اجازهء حالت کوکی معمولی هم داده شده باشه ابتدا با روش تطبیق کوکی غیرسشن احراز هویت با اطلاعات دیتابیس انجام میشه و بلافاصله یک سشن اتولاگین جدید ایجاد میشه با تاریخ انقضای مطابق با زمان تعیین شدهء سشن قبلی که فعلا همون تاریخ انقضای کوکی غیرسشن هست.
(البته امکان غیرفعال کردن این ویژگی هم وجود داره که توضیحش در کد خود صفحات داده شده).
بنابراین دفهء بعدی و دفه های بعد تا زمانی که مجددا تخریب سشن رخ نداده سیستم از اتولاگین با سشن استفاده میکنه.
به این وسیله از امکانات سشن پی اچ پی استفادهء بسیار بهینه تری میتونه صورت بگیره در چنین مواردی و این مطلب تاحد مطلوبی مستقل از تنظیمات سیستم سشن پی اچ پی عمل میکنه و کاراییش رو گسترش میده در عین حالی که در کارکرد نرمالش با شرایط عادی اختلالی ایجاد نمیکنه.
البته این درصورت استفاده از سشن و کوکی معمولی همراه با هم هست که بطور پیشفرض در برنامه فعال هست؛ ولی میشه سه حالت مختلف رو براحتی تنظیم کرد: فقط استفاده از سشن - فقط استفاده از کوکی غیرسشن احراز هویت (در سطح اپلیکیشن) - استفاده از هردو روش ذکر شده.

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


سیستم سشن این پروژه ویژگیها و تدابیر امنیتی زیر پیاده میکنه (شاید همش یادم نباشه؛ در فایلها و داخل کد برنامه هم توضیحاتی هست):
- ایجاد مجدد سشن که ذکر شد.
- پاک شدن سشن منقضی شده (توسط اپلیکیشن) به همراه کوکی اون (زمان انقضای واقعی سشن در خود سشن ذخیره میشه)
- امکان تنظیم دایرکتوری ذخیرهء فایلهای سشن در سطح برنامه
- امکان تنظیم مدت انقضای فایلهای سشن (PHP session garbage collection) در سطح برنامه (منظور اینکه مال خود نرم افزار و جدا/مستقل از فایلهای پیکربندی روی سرور هست)
- تغییر دادن سشن آی دی (تمهید امنیتی) در هربار استفاده از سشن (همچنین موقع ذخیرهء سشن)

ضمنا نام سشن (که کوکی سشن هم با اون نام ذخیره میشه) در فایلهای اطلاعاتی برنامه (به include/info/ مراجعه کنید) قابل تغییر هست و با پیشفرض پی اچ پی فرق داره و بنابراین با سشنهای دیگری اپلیکیشن تداخل نمیکنه.

این برنامه صرفنظر از تنظیمات بخشهای دیگر برنامه یا فایلهای پیکربندی پی اچ پی و آپاچی، صرفا از کوکی برای سشن استفاده میکنه و بعد از استفادهء خودش تنظیمات رو به حالت قبل برمیگردونه.

تنظیم دایرکتوری ذخیرهء سشن مزایای امنیتی قابل توجهی داره و از سرقت سشن یا اطلاعات توسط کاربران مشترک روی یک سرور غیراختصاصی جلوگیری میکنه؛ البته توجه دارید که یک دایرکتوری شخصی (غیر عمومی) باید برای اینکار انتخاب بشه که منطقا در دایرکتوری خانگی هر کاربر هست ولی خارج از دایرکتوری وب که قابل دسترسی وب نباشه. تنظیم مدت انقضا هم تقریبا فقط در چنین حالتی معنا و اطمینان کافی داره. چون تنظیمات برنامه های دیگر خود یا کاربران دیگر برای این زمان انقضای سطح سرور میتونه براحتی تنظیمات ما رو خنثی کنه (اگر دایرکتوری ذخیرهء سشنها مشترک باشه).

برنامه پس از انجام احراز هویت و بقیهء اعمالی که نیاز به کار با سشن دارن، کلیهء تنظیمات رو به حالت قبل از کار خودش برمیگردونه؛ لذا اختلال و نگرانی ای رو متوجه ترکیبش با قسمتهای دیگر برنامه نمیکنه.

فقط یادتون باشه چون اصل و اساس بخش عمدهء سیستم احراز هویت بر استفاده از کوکیها استوار هست، احراز هویت اکثرا باید قبل از ارسال هر خروجی غیر هدری به مرورگر انجام بشه؛ چون ست کردن کوکی با هدرهای اچ تی تی پی صورت میگیره.
بهتره که احراز هویت قبل از هر بخش دیگر برنامه باشه؛ بخصوص که اگر سشن بازی در برنامهء شما باشه با استفاده از احراز هویت خودکار، بسته و اطلاعاتش از محیط برنامه خارج میشه (البته اطلاعات در سشن مربوطه ذخیره هست و با باز شدن مجددش باید در دسترس باشه)
احراز هویت خودکار براحتی از طریق oper_identify.php صورت میگیره؛ به این نحو که شما فقط این اسکریپت رو اینکلود میکنید و اسکریپت خودش کارهای لازم رو انجام میده و بوسیلهء متغییرهایی که ست میکنه اعلام میکنه که کاربری با چه نام کاربری احراز هویت شده یا نشده؛ و ضمنا آخرین مکانیزم مورد استفاده برای شناسایی کاربر چی بوده. پیغام خطای احتمالی هم درصورت مشکل در کارکرد سیستم احراز هویت در متغییر دیگری ذخیره میشه.
فقط سیو کردن هویت کاربر رو بطور دستی میتونید انجام بدید اگر لازم باشه که اونهم کار بسیار راحتی هست و با پاس کردن آرگومانهای ساده به متد سیو منعطفی که کلاس کاربری داره میشه مکانیزم سیو شدن رو تعیین کرد (سشن، کوکی عادی، یا هردو).

از امکانات جالب دیگری که برنامه داره اینه که سعی شده مکان قرار گیری فایلهاش اختلالی در کارکرد برنامه ایجاد نکنه و بطور خودکار تشخیص و ارجاعات لازم انجام بشه و نیاز به هیچ دخالتی جز تعیین دایرکتوری ریشهء پروژه و همچنین نام یا مسیر دایرکتوری فایلهای اینکلودی (کلاسها، توابع، اپراتورها و ... - تقریبا هسته و بخشهای اصلی عملیاتی برنامه) نباشه. شما این تنظیمات رو در includer.php انجام میدید و این فایل رو در DOCUMENT_ROOT قرار میدید. به این وسیله بقیهء بخشهای برنامه میتونه هرجایی باشه و حتی دایرکتوری فایلهای اینکلودی میتونه خارج از دایرکتوری وب هم قرار بگیره!! تقریبا هر صفحه ای تقریبا در هر جایی قرار بگیره، بازهم کار میکنه؛ مثلا ایندکس خودتون رو به یک زیردایرکتوری از دایرکتوری ریشهء تعیین شده ببرید بازهم همهء کارکردها و محتویات اون (لاگین، احراز هویت) دست نخورده بنظر میرسه! اما البته نباید از دایرکتوری ریشهء تعیین شده بالاتر بیایید، ولی میشه تاهرجایی پایینتر رفت.
البته توجه دارید که لینکهای به صفحات دیگه در هر صفحه با تغییر مکان اون صفحه باید اصلاح بشه و این مکانیزم دیگه غیب گو نیست و معجزه نمیکنه و هوش بشری هم نداره!! البته لینک دادن به فایلهایی که همواره در دایرکتوری ریشه هستن رو میشه بازهم با کمک کاربرد غیرمستقیمی از includer.php، کاملا به راحتی به همون صورت خودکار درآورد که بطور مثال در فایل اینکلودی success.php نمونش پیاده شده. توجه دارید که ریشهء این پروژه میتونه DOCUMENT_ROOT نباشه و در هر سابدایرکتوری ای از اون با هر عمقی باشه.

اما البته فایلهای داخل دایرکتوری اینکلود نباید به جای دیگه ای برن مگر همه بطور یکجا و با حفظ ساختار و مکان خودشون در داخل این دایرکتوری؛ درواقع شما میتونید دایرکتوری اینکلود رو بطور کلی از جای خودش کنده و به جای دیگری ببرید، اما نه محتویات داخلش رو به تنهایی یا با تغییر داخلی.

البته حتی نام دایرکتوریهای داخلی دایرکتوری اینکلود هم در فایل includer.php قابل تغییر و همچنین اضافه و حذف هستن که اگر بخوایم پروژه رو گسترش یا تغییر بدیم، و یا از این مکانیزم در اپلیکیشن خودمون استفاده کنیم و بعضی یا همهء بخشهای اپلیکیشن با این سیستم یکپارچه باشن میتونیم از این امکان هم سود ببریم.

هر اسکریپت به includer.php میگه که چه فایل یا فایلهایی رو میخواد (نام فایل/فایلها رو بهش میده در یک آرایه) و نوع فایل رو هم طبق موارد مشخص شده در داخل includer.php مشخص میکنه (بطور مثال کلاس یا تابع یا بخشی از ساختار یک صفحهء اچ تی ام ال) و دیگه کاری به چیز دیگری مثل نام دایرکتوری ای که اون فایل درش قرار داره و مکان دایرکتوری اینکلود و غیره نداره؛ includer.php بقیهء کارها رو خودش انجام میده. اینطور در آینده اگر دایرکتوری هر فایلی، اعم از اینکلود کننده یا اینکلود شونده، تغییری بکنه نیازی به تغییری در جاهای متعددی از اسکریپتهای متعددی نیست و چیزی از زیر دست در نمیره؛ تنها کافیه این تغییرات رو در includer.php منعکس کنیم.
خود includer.php هم همونطور که گفتیم همواره در DOCUMENT_ROOT هست و هر فایلی از هرجایی میتونه آدرسش رو بده بدون اینکه هرگز به تغییری بر اساس مکان فایل اینکلود کننده نیاز باشه.

پیغامهای خطای نمایش داده شده در پروژه دستی تنظیم شدن و مختصر هستن.
برای باگیابی، پیغامهای خطای اصلی و تکنیکی متدهای هر کلاسی رو میشه با مراجعه به متغییر پیغام خطای اون مشخص کرد. بطور مثال با مشاهدهء خطای احراز هویت میتونیم به $user->err_msg مراجعه کنیم. پیغامهای خطای تکنیکی هرگز به مرورگر کاربران ارسال نمیشن به علت مسایل امنیتی؛ اما خطاها بصورت مشخص و در صفحهء توقف مخصوص خودشون به مرورگر ارسال میشن که کار گسترش و باگیابی و آگاه شدن از اختلال در کارکرد پروژه راحت باشه از هر طرفی.

ضمنا نمایش تمام انواع پیغامهایی که از سوی خود پی اچ پی هست در این برنامه بعلت نیاز به تست و باگیابی و آگاهی کامل از همهء جزییات کارکردش، با خطوط لازم زیر در ابتدای فایلهای اصلی برنامه (فایلهایی غیر اینکلود شونده)، فعال شده:


error_reporting(E_ALL);
ini_set('display_errors', '1');

اگر لازم بود (گاهی یا شاید بسیاری مواقع بخاطر مسایل امنیتی) میتونید این دستورات رو بردارید یا با تغییر همینها نمایش بعضی یا تمام پیغامها رو غیرفعال کنید. ضمنا نمایش پیغامهای خطای تکنیکی به کاربران عادی غیر متخصص معمولا تجربهء کسل کننده و منفور کننده ای رو ایجاد میکنه!
بهرحال برای آگاهی از مشکلات نهان برنامه میشه از راههایی مثل تنظیم برای ثبت در فایل لاگ پیغامهای پی اچ پی استفاده کرد.
بنظر من در ابتدا که تست میکنید این پیغامها رو فعال بذارید تا از کارکرد بدون نقص و بی باگ بودن برنامه اطمینان حاصل بشه؛ اگر موردی از خطا مشاهده شد لطفا گزارش کنید.
..........

[eshpilen]

برنامه/پکیج آپدیت شده.

ابتدا کمی سازماندهی اصولی بهتر و منتقل کردن بعضی تنظیمات در کلاس کاربر که جاشون در فایلهای پیکربندی/اطلاعاتی برنامه بود. اینک تمام تنظیمات لازم در یک دایرکتوری و براحتی قابل دسترسی و تنظیم کاربر قرار دارن. کامنتهای کافی هم برای هر مورد درج شده که توضیح داده هر مورد چیکار میکنه و اگر لازم بوده پیشنهادات و راهنمایی و مثال.

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

ضمنا این برنامه بطور کلی درحال حاضر یک سیستم رجیستر و لاگین آزاد رو دراختیار میذاره؛ بخشهایی مثل Verify کردن ایمیل (با فرستادن لینک حاوی کد تایید به آدرس ایمیل) و همچنین کدهای تصویری که مربوط به جلوگیری از رجیستر خودکار (بدون دخالت مستقیم انسان) هستن در برنامه موجود نیستن.
قولی برای کار روی اینطور امکانات دیگه نمیدم؛ همونطور که گفتم این پروژهء شخصی بوده که حالت تمرین هم داشته؛ تا حد نیاز معقول بهش پرداخته شده. البته بخاطر ارایهء عمومی واقعا بیشتر از اون حد هم روش کار شده و منعطفتر و مجهزتر و تمیزترش کردم.

نسخهء فعلی ۱.۱ با تاریخ آخرین آپدیت ۴ اکتبر ۲۰۰۷

دیگه موارد جزیی و تغییرات غیراساسی رو فکر نمیکنم گزارش کنم. فقط این مورد مهم بود که ذکر شد.
..........

[eshpilen]

سلام
از آخرین پست این تاپیک زمان زیادی میگذره
اما ازتون میخوام یه توضیحی هم در مورد نحوه استفاده از این کد اینجا قرار بدین
ممنون


مقدار زیادی حق با شماست!
برای اینکه مطمئن باشم خودم دانلود و راه اندازیش کردم و الان مراحلش رو براتون میگم.
ابتدا آخرین نسخه رو دانلود کنید:
h**p://www.geocities.com/hamidreza712/hamidreza_register_and_login_system.zip?NoCachedVe rsionPlease
فایل زیپ رو داخل دایرکتوری ریشهء وبسایت که در اینجا دایرکتوری ریشهء localhost بنده بوده قرار داده و همونجا extract here میکنیم. درسایت آنلاین هم روشش فرقی نمیکنه و فقط اسم دایرکتوری ممکنه متفاوت باشه، مثلا در سرورهای لینوکس دایرکتوری ریشهء وب، همون www یا public_html هست.
حالا باید یک دایرکتوری بنام reg8log در اونجا داشته باشید و یک فایل بنام includer.php که ضروری هست که این فایل در دایرکتوری ریشهء وب ما باشه تا تمام صفحات صرفنظر از مکان خودشون بتونن این فایل رو اینکلود کنن.
حالا این آدرس رو در مرورگر وب وارد کنید:
http://localhost/reg8log/
اگر روی سایت آنلاین هستید بجای localhost نام دامین سایت رو قرار بدید.

روی لینک Setup project's database کلیک کنید.

اگر اطلاعات نام کاربری و پسورد نمایش داده شده برای اتصال به مای اسکیوال صحیح نیست (جزو کاربرهای تعریف شده نیست) یا باید کاربری با اون نام و پسورد رو به مای اسکیوال خودتون اضافه کنید یا در فایل info_dbms.php (با جستجو پیداش کنید!) اطلاعات یک کاربر موجود رو مثلا به اینصورت وارد کنید و سیو کنید (بقیهء کدها رو هم پاک نکنید!):


$dbms_info=array(
'host'=>'localhost',
'user'=>'MyUser',
'pass'=>'MyPass'
);

دکمهء Setup project's database(s) and table(s) رو بزنید.
اگر مشکلی با نام کاربری و اختیاراتش و پسورد مورد نظر نباشه باید پیام موفقیت رو ببینید:


/reg8log/extra/setup_db.php: Database 'user' created successfully.
Table 'id' created succesfully.

یعنی دیتابیس و جدول برنامهء ما با موفقیت ایجاد شدن.
با کلیک روی Home به صفحهء اصلی میرید که گزینه های مختلف برنامه درش هست که بعضی از این گزینه ها نمایشی و برای راه اندازی و تست برنامه هست (Page1، Current registered users in database، Increase delete counter، Test browser cookie storing، Setup project's database) و اصولا در یک سایت واقعی وجود ندارن و باید این گزینه ها و فایلهایی رو که مربوط به این گزینه ها هستن از دسترس خارج کنید (بسادگی، دلیت کنید!).

خب حالا باید بتونید کاربر رجیستر کنید، و با نام کاربری و پسورد ثبت شده وارد بشید.
اگر در صفحهء خود پروژه این کار انجام بشه دیگه مشکلی نیست جز اینکه چطور این امکانات رو به صفحات خودتون اضافه کنید.
وقت و انرژی لازم رو میخواد تا اینها رو بطور کامل و دقیق و با مثال مطرح کنم و این یک کار آموزشی میشه که بنده ازش معذورم، اما تاحدی که بتونم اطلاعات پایهء لازم رو در اختیار قرار میدم.
این یه پروژه آموزشی و آزمایشی و تخصصی بوده که کامل هم نیست (مثلا میشه امکان ارسال لینک بررسی صحت ایمیل رو بهش اضافه کرد) و برای دیگران طراحی نکردم اما دراختیار قرار دادم و فرض شده که کسی که میخواد ازش استفاده کنه اینقدری حوصله و دانش لازم رو داره که با مطالعه و بررسی و دستکاری کدهای صفحات (عمدتا http://localhost/reg8log/index.php و http://localhost/reg8log/page1.php) پروژه در صفحات خودش سر از کارش دربیاره و راه اندازیش کنه.
صفحهء index.php نمونهء یک صفحه ای هست که درش فرم لاگین هم داریم و اگر کاربر قبلا لاگین باشه کاربر رو شناسایی میکنه، و اگر لاگین نباشه یا بعنوان یک کاربر موجود با اطلاعات هویت صحیح شناسایی نشه یک فرم لاگین در صفحه درج میکنه.
صفحهء page1.php هم نمونهء یک صفحه ای هست که درش فرم لاگین نداریم (مثلا فرض کنید فرم ورود رو فقط در صفحهء اول سایت داریم) و فقط اگر کاربری با اطلاعات صحیح قبلا لاگین باشه این کاربر رو شناسایی میکنه تا فرضا بهش دسترسی و اطلاعاتی رو که لازمه و به کاربران غیرعضو داده نمیشه، بده.
طرز اضافه کردن امکان شناسایی کاربری که لاگین هست (درصورت وجود - یعنی کوکی احراز هویت در سیستمش موجود هست) خیلی ساده هست؛ کافیه این کد رو به اون صفحه اضافه کنیم:


$parent_page=true;
$include_request=array(
'reg8log',
'oper_identify.php'=>'oper'
);
include $_SERVER['DOCUMENT_ROOT'].'/includer.php';

توضیح اینکه $parent_page=true; رو در ابتدای تمام صفحاتی که از این برنامه استفاده میکنن باید قرار داد (یعنی قبل از کدهای دیگر مربوط به این برنامه).
حالا بعد از این کدهای احراز هویت، اگر مشکلی فنی در کارکرد سیستم ما پیش اومده باشه میتونیم این امر رو با if($identify_error) چک کنیم.
که در page1.php این کد به اینصورت نوشته شده که یک صفحهء خطای سیستم رو نشون میده و اجرای صفحهء جاری رو با دستور exit خاتمه میده:


if($identify_error) {
$failure_msg=($tech_err_msg)? $user->err_msg : 'Identification error';
$include_request=array(
'reg8log',
'page_failure.php'=>'page'
);
include $_SERVER['DOCUMENT_ROOT'].'/includer.php';
exit;
}

شما میتونید دقیقا همین کد رو بعد از قطعه کد قبلی در صفحهء خودتون درج کنید، یا میتونید محتویات دستور شرط رو عوض کنید تا کار دیگری انجام بده (مثلا صفحه یا پیام خطای مورد نظر خودتون رو نشون بده)، یا کلا ازش صرفنظر کنید؛ ولی چک نکردن و نشان ندادن خطای سیستم اصولی نیست و در اینصورت خطاهای احتمالی در سیستم مخفی میمونه و بررسی و کشفش سخت میشه؛ خصوصا کاربر شما سردرگم میشه و نمیفهمه اشکالی در کارکرد سیستم بوجود آمده (مثلا عدم دسترسی به دیتابیس و غیره) و از طرف اون نیست.
البته اگر دقیقا همین کد رو درج کردید، در ابتدای صفحه (بعد از $parent_page=true;) این قطعه کد رو هم درج کنید:


$include_request=array(
'reg8log',
'common.php'=>''
);
include $_SERVER['DOCUMENT_ROOT'].'/includer.php';


خب اگر در سیستم احراز هویت خطایی پیش نیامده باشه حالا ما میتونیم با دستور if(!is_null($identified_username)) چک کنیم که آیا کاربری با اطلاعات صحیح توسط سیستم شناسایی شده یا نه و اگر این شرط درست باشه یعنی یک کاربر شناسایی شده و نام کاربری این کاربر هم در متغییر $identified_username هست که میتونید ازش استفاده کنید.
مثلا من یک صفحه با آدرس http://localhost/test.php درست کردم که محتویاتش اینه و بخوبی کار میکنه:


<?php
$parent_page=true;

$include_request=array(
'reg8log',
'common.php'=>''
);

include $_SERVER['DOCUMENT_ROOT'].'/includer.php';
$include_request=array(
'reg8log',
'oper_identify.php'=>'oper'
);
include $_SERVER['DOCUMENT_ROOT'].'/includer.php';

if($identify_error) {
$failure_msg=($tech_err_msg)? $user->err_msg : 'Identification error';
$include_request=array(
'reg8log',
'page_failure.php'=>'page'
);
include $_SERVER['DOCUMENT_ROOT'].'/includer.php';
exit;
}

if(!is_null($identified_username)) echo "Hi $identified_username!";
else echo "Hi guest!";

?>

بقیه به شما مربوط میشه و برنامه نویسی و طراحی شما. این فقط یک سیستم ثبت نام و ورود و شناسایی هست و نه یک سایت کامل یا نرم افزار سایت ساز. مخاطب یک برنامه نویس و طراح متوسط فرض شده.

کمی توضیح هم درمورد صفحهء index.php میدم.
در این صفحه هم مثل صفحه های دیگه اول چک میکنیم که کاربری لاگین هست یا خیر، تا فقط درصورت عدم شناسایی یک کاربر مجاز، فرم لاگین رو در صفحه درج کنیم.
فقط نکته این هست که چون این صفحه دریافت کنندهء اطلاعات فرم لاگین هم هست باید اول چک کنیم که کاربر بوسیلهء فرم لاگین موجود در این صفحه اطلاعات نام کاربری و پسوردی رو ارسال کرده یا خیر، و اگر ارسال کرده باید این اطلاعات رو در ساختاری که سیستم ما وجودش رو تشخیص میده و ازش استفاده میکنه وارد کنیم تا کاربر بتونه شناسایی بشه.
این کد این کار رو میکنه:


if(isset($_POST['username']) and isset($_POST['password']))
$manual_identify=array('username'=>$_POST['username'], 'password'=>$_POST['password']);

بعدش هم که کد احراز هویت مطابق همون نمونهء صفحهء عادی ای که بالاتر گفتم اومده:


$include_request=array(
'reg8log',
'oper_identify.php'=>'oper'
);
include $_SERVER['DOCUMENT_ROOT'].'/includer.php';

if($identify_error) {
$failure_msg=($tech_err_msg)? $user->err_msg : 'Identification error';
$include_request=array(
'reg8log',
'page_failure.php'=>'page'
);
include $_SERVER['DOCUMENT_ROOT'].'/includer.php';
exit;
}

این کد:


if(isset($_POST['remember'])) $remember=true;
else $remember=false;

مربوط میشه به گزینهء ذخیرهء دایمی اطلاعات کاربر روی سیستم کاربر که در فرم لاگین تیک زده (یا نزده) و با متغییر $remember به سیستم ما میگه که اطلاعات کاربر رو بصورت موقتی ذخیره کنه یا بصورت دایمی که با بسته شدن مرورگر هم از بین نره و مثلا تا چند ماه باقی بمونه. میزان این زمان در فایل پیکربندی مربوطه (info_identify.php) قابل تعیین هست.
خب حالا باید چک کنیم که اگر کاربر ما (درصورت شناسایی شده بودن یک کاربر با شرط !is_null($identified_username)) همین الان اطلاعات خودش رو ارسال کرده بوده و بنابراین هنوز اطلاعات لاگین خودکار در سیستمش ذخیره نشده، ما باید اینکار رو بکنیم تا کاربر در تمام صفحات دیگر و تا زمان بسته شدن مرورگر یا حتی زمان طولانی تر در آینده، بطور خودکار توسط سیستم شناسایی بشه (autologin). این قطعه کد همین کار رو انجام میده:


if($identify_method=='manual') {
if($remember) $user->save_identity('permanent');
else $user->save_identity('session');

البته چون این کد کوکی به سیستم کاربر میفرسته، قبلش نباید خروجی ای (غیر از هدرها) به مرورگر کاربر فرستاده باشیم (یعنی مثلا با دستور echo). پس این مجموعه کدها معمولا در اوایل صفحه قرار میگیرن.
نهایتا این کد:


else {//Not identified
if($identify_method=='manual') $msg='You are not authenticated!<br />Check your login information.';
$include_request=array(
'reg8log',
'page_login_form.php'=>'page'
);
include $_SERVER['DOCUMENT_ROOT'].'/includer.php';
}//Not identified

بررسی میکنه که اگر کاربر اطلاعاتی رو ارسال کرده بوده (از $identify_method=='manual' مشخص میشه) ولی برای سیستم شناسایی نشده، یک پیام خطای مناسب رو در متغییر $msg ذخیره میکنه که صفحهء page_login_form.php که محتوی فرم لاگین ما هست اون رو میخونه و در خودش درج میکنه. بعد هم که فرم لاگین (page_login_form.php) رو درج کردیم. دقت کنید چه کاربر اطلاعاتی رو ارسال کرده باشه و چه نکرده باشه، درصورتیکه سیستم کاربری رو شناسایی نکرده باشه این فرم به صفحه اضافه میشه.

حالا شما میتونید برای ورود کاربر لینکی به صفحهء ورود برنامه بدید (و این صفحه رو دستکاری و سفارشی کنید) یا اینکه این کدها رو در صفحهء خودتون بذارید و اگر خواستید شکل و شمایل و اندازه و متن های فرم لاگین رو که در page_login_form.php قرار داره دستکاری کنید و غیره. اینا دیگه همش نیاز به مطالعه و تست داره و سطح لازم از تخصص های لازم رو میطلبه تا جاهایی که ایراد احتمالی پیش میاد بتونید برطرف کنید.
..........