فى هذا الكود
http://midoall.96.lt/test.txtمثلا لو ادخلت الاسم و الايميل ثم ادخلت نفس البيانات سوف تضاف الى قاعدة البيانات
كيف امنع من اضافة الايميل مرتين فى قاعدة البيانات ؟
عدم ادخال شى مرتين php
ببساطة تفقد هل البريد الإلكتروني موجود أو لا !
أيضا أخي الكود الذي تستعمله غير امن فهو معرض لثغرة SQL injection
هذا مثال "امن" ويحتوي التحقق من وجود البريد الإلكتروني قبل إضافته لقاعدة البيانات
<?php
require_once('path/to/connection/file.php');
$name = mysql_real_escape_string($_POST['name']);
$mail = mysql_real_escape_string($_POST['mail']);
$res = mysql_query("SELECT `mail` FROM `all` WHERE `mail` = '$mail'");
if(mysql_num_rows($res) > 0){
echo 'هذا البريد مستعمل مسبقا !';
}else{
mysql_query("INSERT INTO `all`(`id`, `name`, `mail`)VALUES (NULL, '$name', '$mail')");
}
هذه الطريقة في التحقق من عدم وجود البريد ثم إضافة سجد جديد لا تعمل إلى في بيئة منعزلة غير متوازية. لكن الإنترنت بيئة متوازية أي يسمح للخادم (خادم الويب أو خادم mysql) الحديث مع أكثر من وكيل دفعة واحدة.
وتحدث المشكلة مثلا عند الضغط على زر submit مرتين أو عند فتح متصفحين أو مستخدمين من جهازين مختلفين .... إلخ فإذا حاولا إضافة نفس البريد وقام كل منهما بالفحص فلن يجد البريد وسيضيف السجل مرتين. والحل هو عمل قفل في التطبيق (غير عملي) أو وهذا هو الأفضل عمل شرط على مستوى قاعدة البيانات من خلال عمل فهرس فريد كما ذكرت في ردي الآخر
هل تضن أن فعلا أن صاحب الموضوع يحتاج كل هذا ؟ لا أضن !
التحسينات الضرورية ربما هي :
التحقق من أن البريد المُدخل يتبع نمط البريد الإلكتروني
أيضا عليه عدم إستعمال mysql_ و التوجه ل PDO أو mysqli_
إستعمال unique index حل جيد في حالة إحتمال وجود ضغط على التطبيق , لكن لا أضنه يكفي ولا أنصح بالإعتماد عليه فقط , قاعدة البيانات يجب أن تكون مكان للتخزين فقط, المنطق يجب أن يكون في التطبيق .
التحقق من أن البريد المُدخل يتبع نمط البريد الإلكتروني
طبعا.
أيضا عليه عدم إستعمال mysql_ و التوجه ل PDO أو mysqli_
كلامي عام لا يخص لغة أو مكتبة بعينها.
إستعمال unique index حل جيد في حالة إحتمال وجود ضغط على التطبيق , لكن لا أضنه يكفي ولا أنصح بالإعتماد عليه فقط , قاعدة البيانات يجب أن تكون مكان للتخزين فقط, المنطق يجب أن يكون في التطبيق .
بالعكس تماما أخي الحبيب. هذا ليس "منطق" أو كود store procedure أو trigger أو شيء معقد. هذا مجرد فهرس وهو يعتبر جزء من إعلان طبيعة البيانات DDL. فهو أسرع وآمن ولا يمكن الالتفاف حوله بل نصيحتي هي دفع أي ثمن مقابل الحصول على بيانات مضمونة data integrity مثل استعمال محرك innodb والمفاتيح الغريبة والفهارس الفريدة واستعمال not null (عند اللزوم) ...إلخ. تماما كما تقول لقاعدة البيانات أن الاسم هو سلسلة نصية من 30 حرف كحد أقصى تخبره أن البريد فريد ومحرك قاعدة البيانات يضمن ويتكفل بأن يقوم بذلك بأسرع وآمن طريقة ممكنة. ما تقترحه يشبه أنه لا داع لنخبر قاعدة البيانات أن الحقل الفلاني رقم صحيح مثلا.
نقله إلى التطبيق يجلب الكثير من المشاكل الناتجة عن وضع قاعدة البيانات في بيئة متوازية (خادم يتصل به أكثر من وكيل) أو من عدم تطبيق الفحص في أجزاء من الكود عندما يكبر المشروع.
لم أقل أن unique index أو المفاتيح الخارجية ... سيئة بل لا يجب الإعتماد عليها وحدها , عملت على إصلاح عدة تطبيقات تعتمد على هذا المنهج -أي الإعتماد على قاعدة البيانات- وكان سبب ضهور المشاكل هو خطأ في عملية إستيراد قاعدة البيانات بعد الإنتقال لإستضافة جديدة , بحيث ولسبب ما لم تطبق جميع constraints فأدى ذلك لضهور أخطاء في تلك التطبيقات .
التعليقات