Free PHP register/login system

[hm712]

h**p://www.geocities.com/hamidreza712/hamidreza_register_and_login_system.zip

یادتون نره برای دانلود بجای ستاره حرف t رو جایگزین کنید.



اگر ازش استفاده کردید/تستش کردید لطفا نظرتون رو دربارش بگید. اشکالات و باگهای احتمالی و پیشنهاد و کمبودهایی که بنظرتون میرسه.

[reza1357]

میشه بیشتر توضیح بدین چی هست ؟

کلا Php اپن سورس هست و نیازی به ریجستر نداره.

[hm712]

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

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

[hm712]

کد آپدیت شد.

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

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


سیستم سشن این پروژه ویژگیها و تدابیر امنیتی زیر پیاده میکنه (شاید همش یادم نباشه؛ در فایلها و داخل کد برنامه هم توضیحاتی هست):
- ایجاد مجدد سشن که ذکر شد.
- پاک شدن سشن منقضی شده (توسط اپلیکیشن) به همراه کوکی اون (زمان انقضای واقعی سشن در خود سشن ذخیره میشه)
- امکان تنظیم دایرکتوری ذخیرهء فایلهای سشن در سطح برنامه
- امکان تنظیم مدت انقضای فایلهای سشن (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');

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

[hm712]

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

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

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

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

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

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