জাভাস্ক্রিপ্ট: ক্লায়েন্ট-সাইড বনাম সার্ভার-সাইডের বৈধতা


179

ক্লায়েন্ট সাইড বা সার্ভার সাইডের বৈধতা যা করা ভাল?

আমাদের পরিস্থিতিতে আমরা ব্যবহার করছি

  • jQuery এবং এমভিসি।
  • আমাদের ভিউ এবং কন্ট্রোলারের মধ্যে পাস করার জন্য জেএসএন ডেটা।

ব্যবহারকারীদের প্রবেশ করার সাথে সাথে আমি যা যা করি তা প্রচুর পরিমাণে ডেটা যাচাই করা হয়। উদাহরণস্বরূপ আমি keypressকোনও পাঠ্য বাক্সে অক্ষরগুলি রোধ করতে ইভেন্টটি ব্যবহার করি , সর্বাধিক সংখ্যক অক্ষর সেট করি এবং একটি সংখ্যা একটি ব্যাপ্তিতে থাকে।

আমি অনুমান করি আরও ভাল প্রশ্নটি হবে, ক্লায়েন্টের পাশ দিয়ে সার্ভার সাইডের বৈধতা দেওয়ার কোনও সুবিধা আছে কি?


দুর্দান্ত উত্তর প্রত্যেককে। আমাদের কাছে থাকা ওয়েবসাইটটি পাসওয়ার্ড সুরক্ষিত এবং একটি ছোট ব্যবহারকারীর জন্য (<50)। যদি তারা জাভাস্ক্রিপ্ট না চালাচ্ছে তবে আমরা নিনজাস প্রেরণ করব। তবে আমরা যদি সবার জন্য একটি সাইট ডিজাইন করতাম তবে আমি উভয় পক্ষেই বৈধতা দিতে রাজি।


2
জাভাস্ক্রিপ্ট অক্ষম করা যেতে পারে
Enrico Murru

জাভাস্ক্রিপ্ট অক্ষম করা ব্যবহারকারীদের ব্লক করার কোনও নিশ্চিত উপায় নেই। যদি ব্যবহারকারী আপনার পৃষ্ঠায় জেএস সক্ষম করে আসে এবং তারপরে এটি অক্ষম করে তোলে, আপনার করার মতো কিছুই নেই। (ঠিক আছে, আপনি জমা নিয়ন্ত্রণটি কার্যকর করতে জেএস ব্যবহার করতে পারেন, যাতে এটি এই দৃশ্যে কাজ করা বন্ধ করে দেয়, তবে এটি অন্য সমস্ত কিছুর মতোই ছাড়িয়ে যেতে পারে))
স্টিয়ার্ট

উত্তর:


347

অন্যরা যেমন বলেছে, আপনার দুটোই করা উচিত। কারণটা এখানে:

মক্কেলের পক্ষে

আপনি প্রথমে ক্লায়েন্ট পক্ষের ইনপুটটি বৈধ করতে চান কারণ আপনি গড় ব্যবহারকারীর পক্ষে আরও ভাল প্রতিক্রিয়া জানাতে পারেন । উদাহরণস্বরূপ, যদি তারা একটি অবৈধ ইমেল ঠিকানা প্রবেশ করে এবং পরবর্তী ক্ষেত্রে চলে যায়, আপনি তত্ক্ষণাত ত্রুটি বার্তাটি প্রদর্শন করতে পারেন। এই পদ্ধতিতে ব্যবহারকারীরা ফর্মটি জমা দেওয়ার আগে প্রতিটি ক্ষেত্র সংশোধন করতে পারেন ।

আপনি যদি কেবল সার্ভারে বৈধতা দিয়ে থাকেন তবে তাদের ফর্মটি জমা দিতে হবে, একটি ত্রুটি বার্তা পেতে হবে এবং সমস্যাটি অনুসন্ধান করার চেষ্টা করতে হবে।

(ব্যবহারকারীর আসল ইনপুট ভরাট করে সার্ভার ফর্মটি পুনরায় রেন্ডার করে এ ব্যথা লাঘব করা যায়, তবে ক্লায়েন্ট-সাইডের বৈধতা এখনও আরও দ্রুত))

সার্ভার সাইড

আপনি সার্ভারের পাশ দিয়ে বৈধতা দিতে চান কারণ আপনি সেই দূষিত ব্যবহারকারীর হাত থেকে রক্ষা করতে পারবেন , যিনি সহজেই আপনার জাভাস্ক্রিপ্টটি বাইপাস করতে পারেন এবং সার্ভারে বিপজ্জনক ইনপুট জমা দিতে পারেন।

আপনার ইউআই-তে বিশ্বাস করা খুব বিপজ্জনক। তারা কেবল আপনার ইউআই-কে অপব্যবহার করতে পারে না, তবে তারা আপনার ইউআই মোটেও ব্যবহার করতে পারে না, এমনকি একটি ব্রাউজারও ব্যবহার করতে পারে না । ব্যবহারকারী যদি ম্যানুয়ালি ইউআরএল সম্পাদনা করে, বা তাদের নিজস্ব জাভাস্ক্রিপ্ট চালায়, বা অন্য সরঞ্জামের সাহায্যে তাদের এইচটিটিপি অনুরোধগুলি টুইট করে? যদি তারা curlউদাহরণস্বরূপ বা কোনও স্ক্রিপ্ট থেকে কাস্টম এইচটিটিপি অনুরোধগুলি প্রেরণ করে ?

( এটি তাত্ত্বিক নয়; উদাহরণস্বরূপ, আমি একটি ট্র্যাভেল সার্চ ইঞ্জিনে কাজ করেছি যা ব্যবহারকারীর অনুসন্ধানটি অনেক অংশীদার এয়ারলাইনস, বাস সংস্থাগুলি ইত্যাদিতে পুনরায় জমা দিয়েছিল যাতে POSTঅনুরোধ প্রেরণ করে যে ব্যবহারকারী প্রতিটি সংস্থার অনুসন্ধান ফর্ম পূরণ করেছে, তারপরে জড়ো এবং সাজানো হয়েছে) সমস্ত ফলাফল Those এই সংস্থাগুলির ফর্ম জেএস কখনই কার্যকর করা হয়নি এবং এটি আমাদের পক্ষে অত্যন্ত গুরুত্বপূর্ণ যে তারা ফেরত এইচটিএমএলে ত্রুটি বার্তা সরবরাহ করে। অবশ্যই, একটি এআইপিআই চমৎকার হত তবে আমাদের এটিই করতে হয়েছিল had )

এটির জন্য অনুমতি না দেওয়া কেবল সুরক্ষা দৃষ্টিকোণ থেকে নির্বুদ্ধ নয়, মানহীনও নয়: কোনও ক্লায়েন্টকে তারা যা খুশি তাই HTTP প্রেরণের অনুমতি দেওয়া উচিত এবং আপনার সঠিক প্রতিক্রিয়া জানানো উচিত। এর মধ্যে বৈধতা রয়েছে।

সামঞ্জস্যের জন্য সার্ভার সাইডের বৈধতাও গুরুত্বপূর্ণ - সমস্ত ব্যবহারকারী, এমনকি তারা ব্রাউজার ব্যবহার করছেন না কেন, জাভাস্ক্রিপ্ট সক্ষম করা থাকবে।

সংযোজন - ডিসেম্বর 2016

কিছু বৈধতা রয়েছে যা সার্ভার-সাইড অ্যাপ্লিকেশন কোডেও সঠিকভাবে করা যায় না এবং ক্লায়েন্ট-সাইড কোডে একেবারে অসম্ভব , কারণ তারা ডাটাবেসের বর্তমান অবস্থার উপর নির্ভর করে। উদাহরণস্বরূপ, "অন্য কেউ সেই ব্যবহারকারীর নামটি নিবন্ধভুক্ত করেনি", বা "আপনি যে ব্লগ পোস্টে মন্তব্য করছেন সেগুলি এখনও বিদ্যমান", বা "কোনও বিদ্যমান সংরক্ষণ আপনার অনুরোধের তারিখগুলিকে ওভারল্যাপ করে না", বা "আপনার অ্যাকাউন্টের ভারসাম্য এখনও সেই ক্রয়টি কভার করার জন্য যথেষ্ট নয়" । " কেবলমাত্র ডাটাবেসই নির্ভরযোগ্যভাবে ডেটা যাচাই করতে পারে যা সম্পর্কিত ডেটার উপর নির্ভর করে। বিকাশকারীরা নিয়মিত এটি স্ক্রু করে তবে পোস্টগ্রিএসকিউএল কিছু ভাল সমাধান সরবরাহ করে


30
এটি 6 বছর পরেও গ্রহণযোগ্য উত্তর হওয়া উচিত: পি
জ্যাকব ম্যাককে

17
হ্যাঁ, আমি নিশ্চিত হতে প্রায় 10 বছর অপেক্ষা করতে চেয়েছিলাম।
ব্র্যাড 8118

2
@ কিডমোসে "এটি DRY নীতিগুলির একটি সুস্পষ্ট লঙ্ঘন" হ্যাঁ, যার অর্থ আমাদের মতো প্রোগ্রামারদের জন্য ব্যথা। তবে একটি সাইনআপ ফর্মটি কল্পনা করুন। যদি ক্লায়েন্ট কোডটিতে "একটি ইমেল ঠিকানায় অবশ্যই একটি @" জ্ঞানটি নকল করা থাকে তবে ব্যবহারকারীরা দ্রুত প্রতিক্রিয়া পান এবং তাদের মধ্যে বেশিরভাগ সাইন আপ করে, ফলে প্রতি বছর k 100k অতিরিক্ত আয় হয়, এটি অতিরিক্ত রক্ষণাবেক্ষণ ব্যয়ের চেয়ে বেশি দেয়। ডিআরওয়াই একটি খুব ভাল নীতি, তবে এটি কেবল বিবেচ্য নয়। কোডের গুণমানটি ব্যয় / উপকার বিশ্লেষণে এটি ব্যবহারকারী এবং একটি সংস্থাকে কতটা ভাল পরিবেশন করে তা পরিমাপ করা হয়।
নাথান লং

1
@ অরুনআরাজ হ্যাঁ, এবং আপনি বেশিরভাগ সমস্যা সেভাবেই ধরবেন তবে এটি 100% নির্ভরযোগ্য নয়। যদি দু'জন ব্যবহারকারী একই সাথে ফর্মটি পূরণ করে তবে তাদের উভয়কেই বলা যেতে পারে যে user1এটি একটি উপলব্ধ ব্যবহারকারীর নাম। যখন তারা জমা দেয়, তারা উভয়ই একই ব্যবহারকারীর নামটি পাবেন যদি না আপনি সার্ভারের দিকটি আবার পরীক্ষা করেন। এমনকি সার্ভার অ্যাপ্লিকেশন কোডের একটি চেক একই সমস্যা হতে পারে: দুটি অনুরোধ আসে, প্রথমটি ডাটাবেস চেক করে ঠিক থাকে, দ্বিতীয়টি ডাটাবেস চেক করে ঠিক আছে, দ্বিতীয়টি সংরক্ষণ করা হয় সদৃশ হিসাবে শুধুমাত্র একটি ডিবি অনন্য সীমাবদ্ধতা স্বতন্ত্রতার গ্যারান্টি দেয়।
নাথান লং

1
@ নাথানলং জাতির অবস্থার সাথে সংবেদনশীল ডেটাতে যাচাইকরণ এ বাক্যটি যত শব্দ করে ততটা অক্ষম নয়। এটি সঠিকভাবে করতে ব্যথা, তবে একটি রিজার্ভেশন মেকানিজম তৈরি করুন যা অনুরোধ করার জন্য একটি সিঙ্ক্রোনাইজড রিসোর্স ব্যবহার করে। সুতরাং ব্যবহারকারী যদি সার্ভারে "ব্যবহারকারীর নাম" একটি স্বতন্ত্রতা পরীক্ষা করে থাকেন তবে এটি অনন্য কিনা তা পরীক্ষা করতে একসাথে একাধিক কলকে নিষিদ্ধ করে; যদি অনন্য থাকে তবে ক্লায়েন্টকে বরাদ্দ করা অস্থায়ী টোকেন সহ এটি সংরক্ষণও করুন যা একই সেশনের আইডি দ্বারা পৃথক ব্যবহারকারীর নাম পরীক্ষা করা হলেও প্রকাশিত হয়। টোকেনটি একটি যুক্তিসঙ্গত সময়ের পরে শেষ হওয়া উচিত। উদাহরণ: টিকিটমাস্টার আসন রিজার্ভ।
এলাশকানোরে

79

হ্যাঁ, ক্লায়েন্ট সাইডের বৈধতা সর্বদা বাইপাস করা যায়। আপনাকে আরও ভাল ব্যবহারকারীর অভিজ্ঞতা সরবরাহ করার জন্য ক্লায়েন্ট সাইড এবং সার্ভারের দিক উভয়ই আপনার করা ইনপুটটি যাচাই করা হয়েছে এবং ক্লায়েন্টের দ্বারা কেবলমাত্র বৈধ হিসাবে প্রমাণিত নয় তা নিশ্চিত হতে হবে।


43

আমি কেবল এটির পুনরাবৃত্তি করতে যাচ্ছি, কারণ এটি বেশ গুরুত্বপূর্ণ:

সর্বদা সার্ভারে বৈধতা দিন

এবং ব্যবহারকারীর প্রতিক্রিয়াশীলতার জন্য জাভাস্ক্রিপ্ট যুক্ত করুন।


31

ক্লায়েন্ট সাইডের বৈধতার চেয়ে সার্ভার সাইডের বৈধতা দেওয়ার সুবিধাটি হ'ল ক্লায়েন্টের পাশের বৈধতা বাইপাস / ম্যানিপুলেটেড করা যায়:

  • শেষ ব্যবহারকারী জাভাস্ক্রিপ্ট পরিবর্তন করতে পারে
  • ডেটা সরাসরি আপনার সার্ভারে এমন কোনও ব্যক্তির দ্বারা প্রেরণ করা যেতে পারে যা এটির জন্য ডিজাইন করা একটি কাস্টম অ্যাপ্লিকেশন সহ এমনকি আপনার সাইটটি ব্যবহার করছে না
  • আপনার পৃষ্ঠায় একটি জাভাস্ক্রিপ্ট ত্রুটি (যে কোনও সংখ্যক জিনিসের দ্বারা সৃষ্ট) এর ফলে আপনার বৈধতার কিছু চলতে পারে তবে সমস্ত নয়

সংক্ষেপে - সর্বদা, সর্বদা সার্ভার-সাইডটি বৈধতা দিন এবং তারপরে শেষ ব্যবহারকারীর অভিজ্ঞতা বাড়ানোর জন্য ক্লায়েন্ট-সাইডের বৈধতাটিকে একটি অতিরিক্ত "অতিরিক্ত" হিসাবে বিবেচনা করুন।


18

আপনাকে অবশ্যই সর্বদা সার্ভারে যাচাই করতে হবে

এছাড়াও ক্লায়েন্টের বৈধতা ব্যবহারকারীদের পক্ষে দুর্দান্ত তবে এটি সম্পূর্ণ অনিরাপদ।


9

ঠিক আছে, আমি উত্তর দেওয়ার জন্য এখনও কিছু জায়গা পেয়েছি।

রব এবং নাথনের উত্তরগুলি ছাড়াও, আমি যুক্ত করব যে ক্লায়েন্ট-পার্শ্বের বৈধতাগুলি গুরুত্বপূর্ণ। আপনি যখন আপনার ওয়েবফর্মগুলিতে বৈধতা প্রয়োগ করছেন তখন আপনাকে অবশ্যই এই নির্দেশিকা অনুসরণ করতে হবে:

মক্কেলের পক্ষে

  1. আপনার ওয়েবসাইটে সত্যিকারের ব্যবহারকারীদের থেকে আসা আসল অনুরোধগুলি ফিল্টার করতে অবশ্যই ক্লায়েন্ট-পার্শ্বের বৈধতা অবশ্যই ব্যবহার করতে হবে।
  2. সার্ভার সাইড প্রসেসিংয়ের সময় যে ত্রুটিগুলি ঘটতে পারে তা হ্রাস করতে ক্লায়েন্ট-সাইডের বৈধতা ব্যবহার করা উচিত।
  3. সার্ভার-সাইড রাউন্ড-ট্রিপগুলি হ্রাস করার জন্য ক্লায়েন্ট-সাইডের বৈধতা ব্যবহার করা উচিত যাতে আপনি ব্যান্ডউইথ এবং ব্যবহারকারী প্রতি অনুরোধগুলি সংরক্ষণ করতে পারেন।

সার্ভার সাইড

  1. আপনি গ্রাহক পক্ষের সাফল্যের সাথে সম্পন্ন বৈধতাটি 100% নিখুঁত বলে ধরে নেওয়া উচিত নয়। এটি 50 টিরও কম ব্যবহারকারীকে পরিষেবা দেয় তা বিবেচনা করে না। আপনি কখনই জানেন না যে আপনার ব্যবহারকারীর / ক্ষমতার কোনটি "দুষ্ট" রূপান্তরিত হয়েছে এবং আপনার জায়গায় যথাযথ বৈধতা নেই তা জেনে কিছু ক্ষতিকারক কার্যকলাপ করবেন।
  2. এমনকি ইমেল ঠিকানা, ফোন নম্বর যাচাই বা কিছু বৈধ ইনপুট চেক করার ক্ষেত্রে এটি সঠিক কিনা এতে খুব ক্ষতিকারক ডেটা থাকতে পারে। যা সার্ভার-সাইডে ফিল্টার করা দরকার এটি সঠিক বা ভুল কিনা।
  3. যদি ক্লায়েন্ট-পার্শ্বের বৈধতাটিকে বাইপাস করা হয় তবে আপনার সার্ভার-সাইডের বৈধতাগুলি আপনার সার্ভার-সাইড প্রসেসিংয়ের যে কোনও সম্ভাব্য ক্ষতি থেকে আপনাকে উদ্ধার করতে পারে। সাম্প্রতিক সময়ে, আমরা ইতিমধ্যে এসকিউএল ইনজেকশনের প্রচুর গল্প এবং অন্যান্য ধরণের কৌশলগুলি শুনেছি যা কিছু মন্দ সুবিধা অর্জনের জন্য প্রয়োগ করা যেতে পারে।

উভয় ধরণের বৈধতা তাদের নিজ নিজ ক্ষেত্রে গুরুত্বপূর্ণ ভূমিকা পালন করে তবে সবচেয়ে শক্তিশালী সার্ভার-সাইড। আপনি যদি একক সময়ে 10 কে ব্যবহারকারী পান তবে আপনি অবশ্যই আপনার ওয়েবসভারে আসা অনুরোধের সংখ্যা ফিল্টার করে ফেলবেন। যদি আপনি দেখতে পান যে অবৈধ ইমেল ঠিকানার মতো কোনও ভুল ছিল তবে তারা আবার ফর্মটি পোস্ট করে এবং আপনার ব্যবহারকারীকে এটি সংশোধন করতে বলে যা অবশ্যই আপনার সার্ভারের সংস্থান এবং ব্যান্ডউইথ খেয়ে ফেলবে। এত ভাল আপনি জাভাস্ক্রিপ্ট বৈধতা প্রয়োগ। যদি জাভাস্ক্রিপ্ট অক্ষম করা থাকে তবে আপনার সার্ভার পার্শ্বের বৈধতা উদ্ধার করতে আসবে এবং আমি বাজি ধরছি যে 99.99% ওয়েবসাইট জাভাস্ক্রিপ্ট ব্যবহার করে এবং এরই মধ্যে সমস্ত আধুনিক ব্রাউজারগুলিতে এটি ইতিমধ্যে সক্ষম হয়েছে এমন কয়েকজন ব্যবহারকারীই দুর্ঘটনাক্রমে এটি অক্ষম করতে পারেন।


আমি লোকদের পুরোপুরি কোড ইঞ্জেকশন থেকে রক্ষা করতে অবহেলা দেখেছি, কেবল ক্লায়েন্টের পক্ষেই এটি করার কোনও কারণ নেই। এবং কোড ইনজেকশন সম্পর্কিত কোনও রেফারেন্স এর লিঙ্ক ছাড়াই সম্পূর্ণ নয়: xkcd.com/327 :)
স্টিয়ার্ট

8

আপনি সার্ভার সাইডের বৈধতা করতে পারেন এবং ক্লায়েন্ট জাভাস্ক্রিপ্টকে ন্যূনতম (কেবলমাত্র ফলাফল প্রদর্শন করে) রেখে এবং এখনও ক্লায়েন্ট এবং সার্ভার উভয় ক্ষেত্রেই নিজেকে পুনরাবৃত্তি না করে একটি ব্যবহারকারী বান্ধব অভিজ্ঞতা অর্জনের জন্য প্রতিটি ক্ষেত্রের বৈধতা ফলাফলের সাথে একটি JSON অবজেক্টটি ফেরত পাঠাতে পারেন।


3
ব্যবহারকারী বান্ধব? হতে পারে. প্রায় তাত্ক্ষণিক এবং buttery মসৃণ? সম্ভবত না.
quadrupleslap

4

ক্লায়েন্ট পক্ষের মাধ্যমে একটি মৌলিক বৈধতা ব্যবহার করা উচিত এইচটিএমএল 5 ইনপুট ধরণের এবং প্যাটার্ন বৈশিষ্ট্যের এবং এগুলি কেবল উন্নত ব্যবহারকারীর অভিজ্ঞতার জন্য প্রগতিশীল বর্ধনের জন্য ব্যবহৃত হয় (যদিও তারা <আই 9 এবং সাফারিতে সমর্থন করে না তবে আমরা তাদের উপর নির্ভর করি না)। তবে মূল বৈধতা সার্ভারের দিকে হওয়া উচিত ..


"তবে মূল বৈধতা সার্ভারের দিকে হওয়া উচিত।" উচিত নয়, অবশ্যই।
স্টিয়ার্ট

4

আমি ক্লায়েন্ট এবং সার্ভার বৈধতা উভয়ই প্রয়োগ করার পরামর্শ দেব যা এটি প্রকল্পকে আরও সুরক্ষিত রাখে ...... যদি আমাকে একটি চয়ন করতে হয় তবে আমি সার্ভারের পাশের যাচাইকরণের সাথে যাব।

আপনি এখানে কিছু প্রাসঙ্গিক তথ্য পেতে পারেন https://web.archive.org/web/20131210085944/http://www.webexpertlabs.com/server-side-form-ificationsation- using-regular-expression/


2

জাভাস্ক্রিপ্ট রানটাইমে সংশোধন করা যেতে পারে।

আমি সার্ভারে একটি বৈধতা কাঠামো তৈরি করার, এবং এটি ক্লায়েন্টের সাথে ভাগ করার একটি প্যাটার্ন সুপারিশ করি।

আপনার উভয় প্রান্তে পৃথক বৈধতা যুক্তির প্রয়োজন হবে, যেমন:

"required"inputsক্লায়েন্ট পক্ষের বৈশিষ্ট্য

field.length > 0 সার্ভার সাইড।

তবে একই বৈধকরণের স্পেসিফিকেশন ব্যবহার করে উভয় প্রান্তে মিররিং বৈধকরণের কিছু বাড়াবাড়ি (এবং ভুল) দূর করা হবে।


2

ক্লায়েন্টের পার্শ্ব ডেটা যাচাইকরণ আরও ভাল ব্যবহারকারীর অভিজ্ঞতার জন্য দরকারী হতে পারে: উদাহরণস্বরূপ, আমি এমন একজন ব্যবহারকারী যা তার ইমেল ঠিকানাটি ভুলভাবে টাইপ করে, তার অনুরোধটি তিনি যে টাইপোটি সম্পর্কে শিখছেন তার জন্য কোনও দূরবর্তী সার্ভার দ্বারা প্রক্রিয়া করা না হওয়া অবধি অপেক্ষা করা উচিত নয়।

তবুও, আক্রমণকারী যেমন ক্লায়েন্টের পাশের বৈধতাটিকে বাইপাস করতে পারে (এবং এমনকি ব্রাউজারটি একেবারেই ব্যবহার নাও করতে পারে), সার্ভার সাইডের বৈধতা প্রয়োজন এবং আপনার ব্যাক-এন্ডকে দুষ্টু ব্যবহারকারীদের থেকে সুরক্ষিত করার জন্য আসল গেট হতে হবে।


1

আমি একটি আকর্ষণীয় লিঙ্ক জুড়ে এসেছি যা স্থূল, নিয়মিত, এলোমেলো ত্রুটির মধ্যে পার্থক্য তৈরি করে

Client-Side validationস্থূল এবং এলোমেলো ত্রুটি প্রতিরোধের জন্য পুরোপুরি মামলা। টেক্সচার এবং ইনপুটটির জন্য সাধারণত সর্বাধিক দৈর্ঘ্য। সার্ভার-সাইড বৈধতা নিয়মের নকল করবেন না; আপনার নিজস্ব স্থূল, থাম্ব বৈধতা নিয়মের বিধি সরবরাহ করুন (ক্লায়েন্ট-সাইডে 200 অক্ষর; nএকটি শক্তিশালী ব্যবসায়িক বিধি দ্বারা নির্ধারিত সার্ভার-সাইডে)।

Server-side validationপদ্ধতিগত ত্রুটি প্রতিরোধের জন্য পুরোপুরি মামলা; এটি ব্যবসায়ের বিধি কার্যকর করবে।

একটি প্রকল্পে আমি জড়িত, বৈধতা আজাক্স অনুরোধের মাধ্যমে সার্ভারে সম্পন্ন করা হয়। ক্লায়েন্টে আমি ত্রুটি বার্তাগুলি সেই অনুযায়ী প্রদর্শন করি।

আরও পড়া: স্থূল, নিয়মিত, এলোমেলো ত্রুটি:

https://answers.yahoo.com/question/index?qid=20080918203131AAEt6GO


-2

আপনি যদি হালকা বৈধতা করছেন, ক্লায়েন্টের উপর এটি করা ভাল। এটি নেটওয়ার্ক ট্র্যাফিককে বাঁচাবে যা আপনার সার্ভারকে আরও ভালভাবে সম্পাদন করতে সহায়তা করবে। যদি এটির বৈধতা যদি জটিল হয় যা কোনও ডাটাবেস বা পাসওয়ার্ডের মতো কিছু থেকে ডেটা টানা জড়িত থাকে, তবে সার্ভারে এটি করা ভাল যেখানে ডেটা নিরাপদে চেক করা যায়।


2
আপনি যেটি পছন্দ করছেন তা সেরা ধারণা নয়। ব্যবহারকারীরা সর্বদা ক্লায়েন্ট-পার্শ্বের বৈধতা বাইপাস করতে পারে এবং তারা ডাটাবেসে যা খুশি তা জমা দিতে পারে।
ক্রেমুয়া
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.