আপনি কি ক্লায়েন্ট-সাইড এবং সার্ভার-সাইড বৈধকরণ কৌশলগুলি উভয়ই ব্যবহার করেন?


10

কোনও ব্যবহারকারীর কাছ থেকে ইনপুট বৈধকরণের সময় আপনি কি ক্লায়েন্ট-সাইড এবং সার্ভার-সাইড বৈধকরণ কৌশল পাশাপাশি ব্যবহার করেন, যেমন কোনও যোগাযোগের ফর্মের মাধ্যমে?

যদি তাই হয়, এটি কি সত্যিই প্রয়োজনীয়? আপনি ইঞ্জিনিয়ারিং শেষ?


এটি আকর্ষণীয়: স্ম্যাশিংমাগাজাইন.
com

উত্তর:


27

হ্যাঁ, এবং আপনার উচিত।

এটি নষ্ট পোস্টব্যাকগুলি ছাড়াই তাত্ক্ষণিক ব্যবহারকারীর প্রতিক্রিয়া বজায় রাখে যখন জাভাস্ক্রিপ্ট অক্ষম করা ব্যবহারকারীদের বিরুদ্ধেও রক্ষা করে।

এএসপি.এনইটি বৈধকরণ নিয়ন্ত্রণগুলি এভাবে কাজ করে।

অন্যটি ব্যতীত একটি ব্যবহারের অসুবিধা রয়েছে বলে এটি অবশ্যই অতিরিক্ত ইঞ্জিনিয়ারিং নয়।


8
+1 টি। সার্ভার সাইডের বৈধতা ইমো না থাকার জন্য কোনও অজুহাত নেই।
ডি ব্ল্যাকবারো

11
সার্ভারের দিকটি প্রয়োজনীয়, ক্লায়েন্টের দিকটি সুবিধা। ওয়েব অ্যাপ্লিকেশনগুলিতে আপনি ক্লায়েন্টের পক্ষে বৈধতার উপর নির্ভর করতে পারবেন না।
বিলথোর

@ বিল্টহোর - হ্যাঁ ঠিক ঠিক
বিলি.বব

বুদ্ধিমান ব্যবহারকারীরা অবশ্যই আপনার অ্যাপ্লিকেশনটিকে আপত্তিজনকভাবে ব্যবহার করতে পারবেন যদি আপনার ক্লায়েন্টের পাশের বৈধতা না থাকে
উমায়ের

6

যদি তাই হয়, এটি কি সত্যিই প্রয়োজনীয়?

হ্যাঁ.

আপনি ইঞ্জিনিয়ারিং শেষ?

না।

ফ্রন্ট-এন্ড বৈধতা যদি এটি একটি সমৃদ্ধ ইন্টারফেস হয় তবে তাৎক্ষণিক প্রতিক্রিয়া জানাতে পারে।

ব্যাক-এন্ড একাধিক ফ্রন্ট-এন্ড ব্যবহার করতে পারে। এবং এটি কেবলমাত্র এইচটিএমএল (জাভাস্ক্রিপ্ট নয়) পতিত-ব্যাক পরিকল্পনার একমাত্র বৈধতা।


6

সুরক্ষা সম্পর্কে আমি যে প্রথম মৌলিক বিষয়গুলি শিখেছিলাম তার মধ্যে একটি হ্যাকাররা কখনই আপনার ইউআই ব্যবহার করবে না।

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

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


+1, আমি অনেকগুলি উদাহরণ দেখেছি যেখানে ক্লায়েন্টের পক্ষে সম্পূর্ণরূপে বৈধকরণ করা হয়েছিল
কার্ল

2

সার্ভার সাইডের বৈধতা সর্বনিম্ন হওয়া উচিত।

এবং ইনপুটটির জন্য যা ভুল হতে পারে, আপনার ক্লায়েন্টের পাশের চেকও যুক্ত করা উচিত ..

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


1
"এটি অকার্যকর তা পরীক্ষা করা" যাচাইকরণের বৈধতা নয় তাই এটি প্রযোজ্য নয়। পার্থক্যটি বুঝে নিন।
বিলি.বব

2
এমনকি আপনি যা পোস্ট করেছেন তা কি পড়েছেন? ইমেলটি অনন্য যাচাই করা বৈধতা। চেক করা, বলুন যে ইমেল এবং পাসওয়ার্ডটি বৈধ শংসাপত্রগুলি যাচাইকরণ। যাই হোক না কেন, এটি কেবল একটি পরিভাষার বিষয়।
এন্ড্রেয়া

1

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

2 কারণে সার্ভারে ঠিক একই বৈধতাটির নকল করাও গুরুত্বপূর্ণ: 1) যদি জাভাস্ক্রিপ্ট অক্ষম করা থাকে তবে কী হবে?

2) ব্যবহারকারী দূষিতভাবে আপনার ক্লায়েন্ট-পাশের বৈধতাটিকে বাইপাস করার চেষ্টা করেছিল, যা সত্যই সহজ।

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