ক্লায়েন্ট-পাশের জাভাস্ক্রিপ্ট থেকে সরাসরি কোনও ডাটাবেসে না যাওয়ার কোনও কারণ আছে?

62

সম্ভাব্য সদৃশ:
ওয়েব "সার্ভার কম" অ্যাপ্লিকেশন রচনা করা

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

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

সম্পাদনা: দেখে মনে হচ্ছে এখানে এখানেও একই রকম আলোচনা রয়েছে: ওয়েবকে "সার্ভার কম" অ্যাপ্লিকেশন লেখার জন্য

সম্পাদনা: এখনও অবধি দুর্দান্ত আলোচনা, এবং আমি সবার প্রতিক্রিয়াটির প্রশংসা করি! আমার মনে হচ্ছে বিশেষ করে কাউচডিবি এবং অ্যাঙ্গুলারজেএসকে কল করার পরিবর্তে আমার কয়েকটি জেনেরিক অনুমান যুক্ত করা উচিত। সুতরাং আসুন ধরে নেওয়া যাক:

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

— ক্রিস স্মিথ
সূত্র

একেবারে খাঁটি "ক্লায়েন্টের পক্ষে ডাটাবেস" নয়, তবে আপনি কী পার্স এবং ফায়ারবেসের দিকে নজর দিয়েছেন? (এবং কিছু স্তরের উল্কাও), তাদের সবার কিছুটা প্রাসঙ্গিক ধারণা রয়েছে এবং সমস্ত সৃজনশীল উপায়ে সুরক্ষা পরিচালনা করে। যেমন এটি দেখুন: blog.firebase.com/post/38234264120/…

— মেডান

হ্যাঁ! আমি পার্সের কথা আগে শুনেছিলাম তবে ফায়ারবেস নয়। খুব আকর্ষণীয় এবং স্পষ্টভাবে আমি কী ভাবছিলাম তার লাইন ধরে।

— ক্রিস স্মিথ

আপনার ডাটাবেস কীভাবে জাভাস্ক্রিপ্ট থেকে এসকিউএল ইঞ্জেকশন বা এক্সএসএস প্রেরণ করা থেকে রক্ষা করবে? আপনি যে ক্লায়েন্টের কাছ থেকে প্রেরণ করা হয়েছে তা যেহেতু এটি অনিরাপদ রয়েছে তার থেকে অনেক কিছুই প্রেরণ করা হয়েছে, তাই ডাটাবেসটিতে বৈধতা রয়েছে কি না তা নিশ্চিত করার জন্য আপনি ডেটা ফিল্টার করতে পারবেন এবং প্রস্তুত বিবৃতি দিয়ে ডেটা ?োকাতে পারবেন?

— zuallauz

6

অন্য সব কিছু উপেক্ষা করে আপনি একটি 2 স্তরের অ্যাপ্লিকেশন তৈরি করছেন যা আপনার ইউআইটিকে ডাটাবেসের সাথে শক্তভাবে সংযুক্ত করে। আপনার অ্যাপ্লিকেশন যদি তুচ্ছ না হয় তবে সত্যই ভাল ধারণা নয়।

— অ্যান্ডি

12

এসএসএল কাউকে চলমান থামবে নাDELETE FROM ImportantData;

— ব্যবহারকারী 253751

48

আপনার পরামর্শ অনুসারে কাজটি আপনার ক্লায়েন্টের পাশের ভাষা এবং আপনার ডাটাবেসের মধ্যে একটি শক্ত (সংযুক্ত) মিলন তৈরি করে।

এটি ঠিকঠাক হতে পারে - লেখার এবং বজায় রাখার মতো কম কোড রয়েছে এবং তাত্ত্বিকভাবে ডিবাগিংয়ে আরও দ্রুত যেতে পারে / হওয়া উচিত।

অন্যদিকে, এটি অন্যান্য দিকগুলি আরও কঠিন করে তোলে। যদি / যখন আপনাকে সেই প্রযুক্তিগুলির মধ্যে যে কোনও একটির পরিবর্তন করার প্রয়োজন হয়, তাদের মধ্যে শক্ত সংযোগের কারণে আপনার আরও শক্ত সময় কাটাতে হবে।

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

আমি এটি সুপারিশ করব না, এবং অনেকে আপনাকে দৃ not়তার সাথে বলবেন না যে। কিন্তু এটা করতে কাজ করতে হবে।

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

— ক্রিস স্মিথ

1

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

7

@ ক্রিসমিথ - আপনি যতক্ষণ মনে করেন যে আপনি সুরক্ষা উদ্বেগের সমাধান করছেন তারপরে আপনি যে প্রস্তাবটি দিয়েছেন তার প্রাথমিক আপত্তিটি পরিচালনা করছেন। যদি আপনি সেগুলি পরিচালনা করেন বা মনে করেন আপনি এটি করেন তবে এটির জন্য যান। আপনার প্রশ্নের সহজ সংস্করণটি হ'ল: আপনি জিজ্ঞাসা করেছিলেন কেন লোকেরা এবিসি করেন না। প্রাথমিক উত্তরটি সুরক্ষা এবং আঁটসাঁট পোশাক। এই উদ্বেগ এবং কোড দূরে সমাধান করুন।

2

আপনার কাছে প্রায়শই অনুরোধ করা ডেটা ক্যাশে রাখার জায়গা নেই তা উল্লেখ করার দরকার নেই, তাই আপনাকে প্রতিবারই ডিবিতে আঘাত করতে হবে। অবশ্যই, আপনার ডিবি ড্রাইভারটি কিছু ক্যাচিং করে তবে এটি কতটা সুরক্ষিত? এটি থ্রেড জুড়ে ভাগ করে নেবে?

— টিএমএন

1

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

— নাথান পিলিং

36

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

আপনার যদি সমর্থনমূলক প্রমাণের প্রয়োজন হয় তবে প্রচুর উদ্বেগ রয়েছে - সমস্ত দুর্লভ নয়, তবে ভেবে দেখার প্রচুর। কোনও নির্দিষ্ট ক্রমে নয়, এখানে কয়েকটি দেওয়া হল:

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

... এবং আমি নিশ্চিত যে অন্যান্য উদ্বেগ আছে। এবং আমি নিশ্চিত যে এর বেশিরভাগ ক্ষেত্রেই এর সমাধান রয়েছে - যদি এই সমস্ত উদ্বেগ না থাকে। তবে, আপনাকে শুরু করার জন্য একটি তালিকা রয়েছে!

— svidgen
সূত্র

1

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

— ডেভ

16

আমি কল্পনা করতে পারি সেরা একক কারণ: কারণ এই পদ্ধতিটি কোনও জড়িত পক্ষ দ্বারা সরাসরি সমর্থিত বা প্রস্তাবিত নয়।

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

আমি বলছি না এটি সম্ভব নয়। আমি কেবল এটিই বলছি এটি "চাকাটিকে পুনরায় উদ্ভাবন করা" এর চেয়ে কম এবং ব্রাউজার-ভিত্তিক ক্লায়েন্ট-সার্ভার ইন্টারঅ্যাকশন পুনরায় উদ্ভাবনের মতো।

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

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

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

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

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

আসল বিষয়টি হ'ল ফাইলগুলি পরিবেশন করার জন্য আপনার এখনও একটি এইচটিটিপি সার্ভারের প্রয়োজন হবে, কারণ ডাটাবেস সিস্টেমগুলি এটি করে না। একই সময়ে, আপনার প্রস্তাবিত সমস্ত কিছু আপনার পাতায় ডাটাবেসে একটি রেস্টস্টুল ইন্টারফেস প্রকাশ করার জন্য একটি পাতলা সার্ভার মডেল (যেমন নোডেজ সহ) ব্যবহার করে প্রাপ্ত করা যেতে পারে। এটি একটি কারণে জনপ্রিয় - এটি কাজ করে, সুরক্ষা স্তরগুলির পিছনে ডাটাবেসকে গোপন রাখে, অত্যন্ত স্কেলযোগ্য এবং তবুও আপনি আপনার ডাটাবেসটিকে যতটা ঘন বা তত যত্নবান হিসাবে তৈরি করতে দেয়।

— BrianH
সূত্র

8

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

ওয়েল, আপনার অনুমোদন (সুরক্ষা উদ্বেগ) এবং লজিক বৈধতা ডাটাবেস থেকে দূরে রাখা আপনার সফ্টওয়্যার সিস্টেমে উদ্বেগের বিচ্ছেদ প্রদান করে। সুতরাং আপনি সিস্টেমে কার্যকারিতা ব্রেক করার কম ঝুঁকি নিয়ে আপনার লজিকাল কোড ব্লকটি পরীক্ষা, পরিচালনা, স্কেল এবং পুনরায় ব্যবহার করতে পারেন।

ক্লায়েন্ট ইনপুট জন্য ডেটাবেস সঙ্গে সরাসরি যোগাযোগের জন্য দক্ষতা সরবরাহের ডেটা স্ক্রু আপ করার খুব বড় সম্ভাবনা রয়েছে ।

এর অর্থ হ'ল টাইট কাপলিং এড়ানো / অপসারণ করা আপনার সফ্টওয়্যার সিস্টেমকে আরও রক্ষণাবেক্ষণযোগ্য এবং সলিড করে।

— ই এল ইউসুবভ
সূত্র

1

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

— ক্রিস স্মিথ

2

ক্লায়েন্ট-পাশের বৈধতা থাকা ক্লায়েন্টের পক্ষে দুর্দান্ত তবে এটি আপনার সার্ভারের পাশে থাকা আগের চেয়ে আরও জটিল critical কারণ, আপনার ক্লায়েন্টের পক্ষের অনুরোধটি সহজেই অনুকরণ করা যায়। যৌক্তিক পৃথকীকরণ এবং / অথবা স্তরগুলি সামাজিকতা এবং রক্ষণাবেক্ষণে সহায়তা করে।

— EL Yusubov

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

— ক্রিস স্মিথ

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

— EL Yusubov

ডিবি ইঞ্জিনগুলি হ'ল ডেটা সঞ্চয় এবং পুনরুদ্ধার করতে বোঝায়, এটি ব্যবহার বা বৈধকরণের উদ্দেশ্যে নয়। অবশ্যই আপনি এটি আপনার উপায়ে করতে পারেন, তবে এটি অনুসরণ করার দক্ষ উপায় নয়।

— ই এল ইউসুভভ

6

ব্যবহারকারীকে সরাসরি ডাটাবেসের সাথে ইন্টারঅ্যাক্ট করা আমার পক্ষে বিপদজনক বলে মনে হয়।

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

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

— ফিলিপ
সূত্র

1

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

— ক্রিস স্মিথ

6

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

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

আপনি যদি একটি দ্বি-স্তরের সিস্টেম ব্যবহার করছেন এবং আপনার সমস্ত সার্ভার-সাইড লজিকের জন্য ডাটাবেসে ভরসা করছেন, আপনি কীভাবে টোকেনটি যাচাই করবেন? হ্যাঁ, আমি মনে করি কোনও সঞ্চিত প্রক্রিয়া লিখতে ডিবিএমএসের উপর নির্ভর করে তাত্ত্বিকভাবে সম্ভব হতে পারে যা কোনওরকম শেল কল করে এবং যথাযথ যুক্তি দিয়ে কার্লের আবেদন করে। এটি প্রায় অবশ্যই একটি ভয়ঙ্কর ধারণা: সুরক্ষা দুর্বলতার বিরুদ্ধে ইনপুট ফিল্টারিং এবং রক্ষা করা ভয়ঙ্কর হবে; ত্রুটি পরিচালনা ও সময়সীমা নিয়ে আপনার কোনও ঝামেলা হবে; এবং আপনাকে নিজের প্রতিক্রিয়াটি নিজেরাই পার্স করতে হবে। একটি ডিবিএমএস এটি করার উদ্দেশ্যে নয় তা উল্লেখ করার দরকার নেই, সুতরাং কার্যকারিতা, স্থিতিশীলতা, থ্রেড-সুরক্ষা ইত্যাদি ভাবার কোনও কারণ নেই ... এটি সমস্যা হবেনা। উদাহরণস্বরূপ, এই থ্রেডটি দেখুন , যা পোস্টগ্র্রেসের জন্য এই কয়েকটি বিষয় নিয়ে আলোচনা করে।

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

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

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

— জ্যাচ লিপটন
সূত্র

5

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

— মাইকেল ব্রাউন
সূত্র

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

— ক্রিস স্মিথ

2

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

আপনার স্ট্যাকওভারফ্লো ক্লোন উদাহরণ অনুসরণ করে:

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

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

— Jbm
সূত্র

1

ফায়ারবগে পৃষ্ঠা সম্পাদনা করুন এবং এক পর্যায়ে এটির অনুরূপ একটি লাইন রাখুন:

ExecDbCommand("DROP TABLE Users")

চালাও এটা.

সম্পাদনা:

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

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

— AZ01
সূত্র

কাউচডিবি কি করবে তা জানত না তবে আমি আপনার বক্তব্যটি পেয়েছি। যদি অনুমতিগুলি যথাযথভাবে সেট করা থাকে তবে এ জাতীয় জিনিসের প্রতিক্রিয়া 401 অননুমোদিত।

— ক্রিস স্মিথ

-1, আপনি যখন এসকিউএল কোড পোস্ট করেন তখন আপনি অবশ্যই জানেন না যে কাউচডিবি কী। এছাড়াও, কেবল কাউচডিবিতে অ্যাডমিন অ্যাকাউন্ট তৈরি করে আপনি ইতিমধ্যে অন্য যে কোনও ব্যবহারকারীকে সবচেয়ে বিপজ্জনক ক্রিয়াকলাপ করা থেকে বিরত রেখেছেন।

— ফিলিপ

যথেষ্ট ন্যায্য। আমি প্রশ্নটিতে কাউচডিবিতে অংশটি এড়িয়েছি এবং কেবল এটি "ক্লায়েন্টের পাশের জেএস থেকে সরাসরি ডেটা স্টোর" হিসাবে নিবন্ধিত করেছি। আমি প্রতিক্রিয়া সম্পাদনা করব।

— এজেড 01

1

+1, এসকিউএল বা না, এখনও তার পয়েন্টটি ধরে আছে। কীভাবে ডেটা অ্যাক্সেস করা হয় তা পরিবর্তনের জন্য একটি জেএস ডিবাগার ব্যবহার করা যেতে পারে।

— গ্র্যান্ডমাস্টারবি

1

পুরানো প্রশ্ন, আমি জানি, তবে আমি চিমটি দিতে চেয়েছিলাম কারণ আমার অভিজ্ঞতা অন্যান্য প্রতিক্রিয়াগুলির তুলনায় একেবারেই আলাদা।

আমি রিয়েল-টাইম, সহযোগী অ্যাপ্লিকেশন লেখার জন্য অনেক বছর ব্যয় করেছি। এই অ্যাপ্লিকেশনগুলির জন্য সাধারণ পদ্ধতি হ'ল স্থানীয়ভাবে তথ্য প্রতিলিপি করা এবং যত দ্রুত সম্ভব সাথীদের সাথে পরিবর্তনগুলি সমন্বয়সাধন করা। ডেটাতে সমস্ত ক্রিয়াকলাপ স্থানীয়, সুতরাং সমস্ত ডেটা সঞ্চয়স্থান, ডেটা অ্যাক্সেস, ব্যবসায়িক যুক্তি এবং ব্যবহারকারী ইন্টারফেস স্তরগুলি স্থানীয়। "অফলাইন প্রথম" আন্দোলন ( http://offlinefirst.org/ ) অফলাইন ওয়েব অ্যাপ্লিকেশনগুলি তৈরি করার জন্য এই পদ্ধতি গ্রহণ করেছে এবং এতে কিছু প্রাসঙ্গিক সংস্থান থাকতে পারে। এই ধরণের ব্যবহারের ক্ষেত্রে কেবল আপনি ক্লায়েন্টদের কাছে আপনার ডেটা অ্যাক্সেস স্তরটিই খোলার আদেশ দেয় তা নয়, ডেটা স্টোরেজও! আমি জানি আমি জানি. মনে হচ্ছে পাগল, তাই না?

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

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

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

আমি বর্তমানে কাউচডিবি ব্যবহার করে একটি সিস্টেম তৈরি করছি যেখানে ব্যবহারকারীদের একটি ডেটাसेट তৈরি করতে ডেটাতে সহযোগিতা করা দরকার যা তখন কিউএ / কিউসি কর্মপ্রবাহের মাধ্যমে "প্রকাশিত" হয়। সহযোগিতাটি তথ্যগুলির একটি প্রতিরূপে পরিচালিত হয় (আমরা একে স্টেজিং বা ওয়ার্কিং ডাটাবেস বলি) এবং একবার সম্পূর্ণ হয়ে গেলে কোনও দায়িত্বশীল ব্যক্তি ডেটাতে কিউএ / কিউসি সঞ্চালন করে এবং তারপরেই এটি পুনরায় মূল ভান্ডারে প্রতিলিপি করা হয়।

এ থেকে অনেক সুবিধা প্রবাহিত হয় যা অন্যান্য সিস্টেমে অর্জন করা শক্ত - যেমন সংস্করণ নিয়ন্ত্রণ, প্রতিলিপি এবং সহযোগিতা (অফলাইনে কাজ করা যাক!) ট্র্যাডিশনাল তিন স্তরের সিআরইউডি অ্যাপ্লিকেশনগুলির জন্য অত্যন্ত শক্ত is

আমার পরামর্শ - যদি আপনার অ্যাপ্লিকেশনটি "চিরাচরিত" হয় তবে এটি প্রচলিত পদ্ধতিতে করুন do আমি উপরে উল্লিখিত জিনিসগুলির মধ্যে যদি (যদিও আরও অনেকগুলি ...) আপনার ক্ষেত্রে প্রযোজ্য হয় তবে বিকল্প স্থাপত্যগুলি বিবেচনা করুন এবং বিলম্বিতভাবে ভাবতে প্রস্তুত থাকুন।

— ড্যানিয়েল পল
সূত্র

0

আমি মনে করি, আপনার সমস্ত অনুমানের পরে, ক্লায়েন্টের কাছ থেকে সরাসরি ডাটাবেসে যাওয়া সম্ভব। যাইহোক, আপনার অনুমানগুলি বৈধ কিনা এবং ভবিষ্যতেও এটি সম্ভবত রয়ে যাওয়ার সম্ভাবনা রয়েছে কিনা তা দেখার পক্ষে যুক্তিসঙ্গত।

আমি উদ্বিগ্ন হব যে ভবিষ্যতে সকলের পক্ষে সমস্ত ডেটা পড়া ঠিক হবে না এবং বিশেষত ভবিষ্যতে এটি আরও ব্যবসায়িক যুক্তি বিকাশ করতে পারে। এই দুটি প্রকল্পই সফল হলে বেশি সম্ভাবনা রয়েছে।

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

তবে আমি স্পষ্টতই দেখতে পেলাম যে এটি পরে ঝুঁকির চেয়ে কম কারণ যেখানে আজ কম চলমান অংশগুলির সুবিধা vs

— PSR
সূত্র

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

— ক্রিস স্মিথ

0

সবার আগে বাক্স আউট করার জন্য ধন্যবাদ .... :)

তবে আমি যা পরামর্শ দেব তা হ'ল; আপনার 3 স্তরের মাঝে সর্বদা আলাদা করার চেষ্টা করুন। যা উপস্থাপনা / ব্যবসা এবং ডেটাবেস বা ডিএও কারণ এটি সেই ধরণের প্রয়োজনীয়তা এবং সেটআপগুলিতে সর্বোত্তম অনুশীলন হবে যেখানে প্রতিদিন প্রচুর পরিবর্তন হবে।

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

এবং বিজনেস লজিক অবশ্যই প্রেজেন্টেশন লেয়ার এবং ডাটাবেস / দাও লেয়ারের মধ্যে ক্ষেত্রের ingালাইয়ের মতো কিছু ব্যবসায়ের বৈধতা ইত্যাদি আপনার প্রশ্নের মত জাভাস্ক্রিপ্ট বিভাগের পরিবর্তে বিজনেস লেয়ারে পরিচালনা করা উচিত।

এই বিভাজনটি আপনাকে জটিল পরিস্থিতিতে, কার্যকারিতা- এবং এমনকি জটিল বৈধতাগুলির সময় দুর্দান্ত স্বাচ্ছন্দ্য এবং সংযোগ সরবরাহ করে। সর্বোত্তম সুবিধা হ'ল: এই স্তরগুলি বাস্তবায়নের জন্য আপনার কাছে বিভিন্ন প্রযুক্তি থাকতে পারে এবং ব্যবসায়ের প্রয়োজন বা সুযোগ অনুযায়ী পরিবর্তন করা যেতে পারে।

ধন্যবাদ

— Logicalj
সূত্র

0

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

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

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

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

— ডানুবিয়ান নাবিক
সূত্র

0

আমি দুটি সমস্যা দেখতে পাচ্ছি:

টাইট কাপলিং: আপনার ডিবি বিকল্পটি পরিবর্তন করবেন? ভাল, এখন আপনি আপনার সমস্ত ক্লায়েন্ট-পাশের কোডটিও পরিবর্তন করতে হবে। আমাকে বিশ্বাস কর. আমাদের ক্লায়েন্ট-সাইডে আরও সমস্যা দরকার নেই।

২. টিএমআই সুরক্ষা ইস্যু: স্টাফ কীভাবে কাজ করে সে সম্পর্কে খুব বেশি প্রকাশ করে। প্রমাণীকরণ এখনও একটি বাধা হতে পারে তবে সার্ভার-সাইডে ঠিক কী ঘটছে তা আপনি যখন জানবেন তখন শোষণ খুঁজে পাওয়া অনেক সহজ কাজ।

খুব খুব পাতলা মাঝারি স্তর হ'ল আরও ভাল উপায় হতে পারে।

— এরিক রেপেন
সূত্র

-1

জাভাস্ক্রিপ্টটি কেবলমাত্র ডাটাবেস-অ্যাক্সেস-স্তর থাকলে জাভাস্ক্রিপ্ট অক্ষম করা থাকলে (বা তার ডিভাইসের ব্রাউজারে সমর্থিত নয়) আপনার ক্লায়েন্ট আপনার ওয়েব অ্যাপ্লিকেশনটি ব্যবহার করতে পারবেন না।

— k3b
সূত্র

2

এহ, এ নিয়ে খুব বেশি চিন্তিত নন। ওয়েবের বেশিরভাগ অংশ এখনই জাভাস্ক্রিপ্টের উপর নির্ভর করে। আমার কেবলমাত্র <নোগ্রিপ্ট> ট্যাগগুলি বের করে দিতে হবে এবং তাদের বলার দরকার আছে যে তারা যদি আমার সাইট (এবং সেখানে অন্যান্য 80% লোকের) কাজ করতে চায় তবে তাদের এটি চালু করতে হবে।

— ক্রিস স্মিথ