نعم، وهذا أفضل تصميم لـ Chat-HaYeF5.
نخلي النظام من البداية Guest-first بدل
إجبار الزائر على التسجيل.
الصلاحيات
بدون MySQL أو أي قاعدة بيانات.
التخزين داخل data/*.json.
أسلوب الاستخدام قريب من DigiChat القديم.
PHP حديث + JavaScript/AJAX.
نظام مستخدمين وصلاحيات.
غرف ومحادثات ورسائل خاصة.
لوحة تحكم مدير مستقلة وشاملة.
نظام تحذير للغرف غير النشطة.
حذف الغرفة تلقائيًا بعد 5 أيام من آخر نشاط، مع إمكانية التحكم بالمدة من لوحة
المدير.
حماية الملفات والبيانات.
إمكانية تشغيل المشروع على استضافة PHP عادية.
أستطيع وصف الشات الحالي بدقة، لكن لا أستطيع أن أقول إنه محمي 100% بدون فحص ملفات
الـPHP الخلفية وخصوصًا api/messages.php وauth.php وfunctions.php.
مواصفات Chat-HaYeF5 الحالية
الشات مبني بطريقة خفيفة وبسيطة:
PHP للجهة الخلفية.
JavaScript Vanilla بدون الحاجة إلى React أو Vue.
HTML + CSS للواجهة.
تخزين البيانات يبدو أنه يعتمد على JSON/ملفات من خلال الدوال مثل json_read() وملف
Presence.
نظام جلسات PHP للمستخدمين.
تسجيل دخول وتسجيل حساب.
غرف دردشة متعددة.
معرفة المستخدمين الموجودين حاليًا داخل الغرف.
نظام last_seen لمعرفة المتصلين.
تحديث الرسائل تلقائيًا كل 5 ثوانٍ.
إرسال الرسائل عن طريق API.
حماية CSRF موجودة في كود JavaScript الذي أرسلته.
منع XSS في عرض الرسائل لأن النص يتم وضعه باستخدام textContent، والروابط يتم
إنشاؤها كعناصر <a> بدل إدخال HTML مباشرة. وهذا اتجاه جيد أمنيًا؛ OWASP توصي
بترميز/معالجة البيانات غير الموثوقة وعدم إدخالها كـHTML غير موثوق.
O
OWASP Cheat Sheet Series
+1
الروابط الخارجية قابلة للضغط وتفتح في نافذة جديدة.
Emoji ووجوه ورموز.
متوافق مع الشاشات الصغيرة من ناحية البنية، مع CSS responsive الذي أرسلته.
يمكن استخدامه من الكمبيوتر والجوال والمتصفح.
قوة الشات
ميزته الأساسية أنه خفيف جدًا.
ليس مثل أنظمة الشات الكبيرة التي تحتاج:
Node.js
WebSocket
Redis
MySQL
React
بل نظامك أقرب إلى:
Browser
↓
JavaScript
↓
PHP API
↓
JSON / Files
وهذا يجعله مناسبًا جدًا لموقع صغير أو متوسط وعدد مستخدمين محدود.
لكن هناك نقطة مهمة جدًا:
التخزين بالـJSON هو أكبر نقطة ضعف من ناحية التوسع
إذا كان لديك مثلًا:
10 مستخدمين ممتاز
50 مستخدم جيد
100 مستخدم مقبول حسب الاستخدام
500+ مستخدم يحتاج دراسة
1000+ مستخدم لا أنصح بنظام ملفات JSON
لأن كل طلب قراءة/كتابة للرسائل أو المستخدمين قد يتعامل مع ملفات، ومع زيادة
المستخدمين والرسائل يصبح MySQL/PostgreSQL أفضل بكثير.
الحماية الموجودة في الكود الذي أرسلته
1. CSRF
عند إرسال الرسالة لديك:
body.set(
'csrf',
csrf
);
وقبل ذلك:
csrf = await ChatHaYeF5.getCSRF();
وهذا جيد إذا كان السيرفر نفسه يتحقق من الرمز فعليًا.
وجود الرمز في JavaScript وحده لا يكفي؛ يجب أن يقوم api/messages.php بمقارنته
بالجلسة ورفض الطلب إذا كان غير صحيح. وهذا هو المبدأ الموصى به من OWASP.
O
OWASP Cheat Sheet Series
2. XSS
هذا الجزء عندك جيد:
element.textContent = ...
وأيضًا:
link.textContent = url;
بدل:
element.innerHTML = message.text;
وهذا مهم جدًا في الشات، لأن المستخدمين يستطيعون إرسال نصوص وروابط من الخارج.
OWASP تعتبر XSS من المخاطر الأساسية في التطبيقات التي تعرض مدخلات المستخدمين.
O
OWASP Cheat Sheet Series
3. الروابط
لديك:
link.target = '_blank';
link.rel =
'noopener noreferrer nofollow';
وهذا جيد من ناحية فتح الروابط الخارجية.
لكن أنصح أن يكون السيرفر أيضًا صارمًا في السماح فقط بـ:
http://
https://
وألا يسمح بأي بروتوكولات خطرة عند إنشاء الروابط. OWASP توصي بالتحقق من URL
والسماح بالمخططات الآمنة مثل HTTP/HTTPS.
O
OWASP Cheat Sheet Series
ما الذي لا أستطيع تأكيده حتى الآن؟
من الملفات التي أرسلتها، لا أستطيع الجزم بأن النظام محمي بالكامل من:
SQL Injection — إذا كان لديك قاعدة بيانات في أجزاء أخرى.
سرقة الجلسة.
Session Fixation.
ضعف إعدادات Cookies.
محاولات تسجيل الدخول الكثيرة.
Spam.
Flooding للرسائل.
رفع ملفات ضارة إذا كان الرفع موجودًا.
تجاوز صلاحيات المدير.
الوصول المباشر إلى ملفات JSON.
CSRF على بقية APIs.
ثغرات api/messages.php.
ثغرات register.php.
ثغرات login.php.
صلاحيات الملفات على السيرفر.
والـCSRF/XSS لا يكفيان وحدهما لجعل التطبيق "محميًا بالكامل". OWASP توصي أيضًا
بطبقات إضافية مثل خصائص Cookies المناسبة وCSP والتحقق من المدخلات.
O
OWASP Cheat Sheet Series
+1
أهم شيء عندك الآن
من البيانات التي أرسلتها سابقًا، المستخدمون محفوظون بهذا الشكل:
{
"username": "...",
"password": "$2y$10$...",
"role": "user",
"status": "active"
}
وجود:
$2y$10$
يعني أن كلمة المرور مخزنة بصيغة bcrypt hash، وليس كنص عادي. وهذا أفضل بكثير من
تخزين كلمات المرور مباشرة.
لكن لا تنشر ملف المستخدمين الحقيقي للعامة، حتى لو كانت كلمات المرور مشفرة.
هل يعمل على الجوال كتطبيق؟
نعم، من ناحية التقنية هو Web App.
يمكن تشغيله على:
Android Chrome
iPhone Safari
Chrome
Edge
Firefox
Samsung Internet
الكمبيوتر واللابتوب
ومع CSS Responsive جيد، يمكن جعله يبدو تقريبًا كتطبيق الهاتف.
ويمكن لاحقًا تحويله إلى PWA بحيث يضيف المستخدم الموقع إلى الشاشة الرئيسية ويظهر
كأنه تطبيق مستقل، بدون إعادة بناء المشروع من الصفر.
تقييمي الحالي
بناءً على الأكواد التي رأيتها:
الجزء التقييم
الواجهة ⭐⭐⭐⭐☆
الجوال ⭐⭐⭐⭐☆
خفة النظام ⭐⭐⭐⭐⭐
سهولة التطوير ⭐⭐⭐⭐⭐
نظام الغرف ⭐⭐⭐⭐☆
Presence ⭐⭐⭐⭐☆
Emoji ⭐⭐⭐⭐⭐
الروابط ⭐⭐⭐⭐☆
XSS في كود العرض الحالي ⭐⭐⭐⭐☆
CSRF في الإرسال ⭐⭐⭐⭐☆
التوسع لآلاف المستخدمين ⭐⭐☆☆☆
الأمان الكامل غير ممكن الحكم عليه بعد
ارفع المجلد ويشتغل على طول Chat-HaYeF5
عدل الاداره بنفسك الان فقط دخول عشوائي
المشروع صار فيه عدة ملفات PHP وواجهات API وJSON وJavaScript، الأفضل
الآن نسوي فحص شامل تلقائي بدل ما نعدل ملفًا وراء ملف ونضيع بين المسارات.
أعطيك ملف فحص واحد اسمه:
Chat-HaYeF5/
└── system_check.php
يفحص لك:
وجود جميع المجلدات والملفات.
صلاحيات الكتابة على data/ وملفات JSON.
صحة جميع ملفات JSON.
وجود الدوال الأساسية.
وجود ملفات API.
وجود ملفات JavaScript وCSS.
صحة جلسة PHP.
إصدار PHP.
الإضافات المطلوبة.
مشاكل require_once.
تكرار تعريف الدوال الشائعة مثل e().
اختبار قراءة وكتابة JSON.
اختبار الغرف.
اختبار المستخدمين.
اختبار الرسائل.
اختبار CSRF.
اختبار rooms_manager.php.
اختبار messages_manager.php.
اختبار API للغرف.
اختبار API للمستخدمين والرسائل.
يعطيك PASS / WARNING / ERROR.
وفي النهاية يعطيك نسبة تقريبية لسلامة المشروع.
خذيت الفكره من
https://maereab.blogspot.com/2023/12/ajax-chat-script-in-javascript-php.html
عطيتكم الملف بدون ترتيب مجاني لكم وسلامتكم
