আমার কাছে একটি ওয়েব ভিত্তিক প্রকল্প রয়েছে যা ব্যবহারকারীরা অনলাইনে এবং অফলাইন উভয় ক্ষেত্রেই কাজ করতে দেয় এবং আমি ক্লায়েন্টের পক্ষ থেকে রেকর্ডগুলির জন্য অনন্য আইডি উত্পন্ন করার উপায় খুঁজছি। আমি এমন একটি অ্যাপ্রোচ চাই যা ব্যবহারকারী অফলাইনে থাকাকালীন কাজ করে (অর্থাত্ সার্ভারের সাথে কথা বলতে অক্ষম), অনন্য হওয়ার গ্যারান্টিযুক্ত এবং সুরক্ষিত। "সুরক্ষিত" দ্বারা, আমি ক্লায়েন্টদের নকল আইডির (দূষিতভাবে বা অন্যথায়) জমা দেওয়ার এবং এর মাধ্যমে ডেটা অখণ্ডতার উপর সর্বনাশ ডেকে আনার বিষয়ে বিশেষভাবে উদ্বিগ্ন।
আমি কিছু গুগলিং করছি, আশা করছি এটি ইতিমধ্যে একটি সমাধান সমস্যা ছিল। আমি খুব নির্দিষ্ট কিছু খুঁজে পেলাম না, বিশেষত উত্পাদন ব্যবস্থায় ব্যবহৃত পদ্ধতির দিক থেকে। আমি সিস্টেমগুলির জন্য কয়েকটি উদাহরণ পেয়েছি যেখানে ব্যবহারকারীরা কেবল তাদের তৈরি করা ডেটা অ্যাক্সেস করতে পারে (যেমন টোডো তালিকা যা একাধিক ডিভাইসে অ্যাক্সেস করে তবে কেবল এটির ব্যবহারকারীরা) by দুর্ভাগ্যক্রমে, আমার আরও কিছু পরিশীলিত জিনিস দরকার। আমি এখানে কিছু সত্যই ভাল ধারণা পেয়েছি , যা আমি কীভাবে চিন্তা করি যে জিনিসগুলি কাজ করতে পারে তার সাথে সঙ্গতিপূর্ণ।
নীচে আমার প্রস্তাবিত সমাধান।
কিছু প্রয়োজনীয়তা
- আইডিগুলি বিশ্বব্যাপী অনন্য হওয়া উচিত (বা সিস্টেমের মধ্যে অন্তত অনন্য)
- ক্লায়েন্টে উত্পন্ন (যেমন ব্রাউজারে জাভাস্ক্রিপ্টের মাধ্যমে)
- সুরক্ষিত (উপরে বর্ণিত হিসাবে এবং অন্যথায়)
- ডেটা একাধিক ব্যবহারকারীর দ্বারা দেখা / সম্পাদনা করা যেতে পারে, যার দ্বারা এটি লেখেননি
- ব্যাকএন্ড ডিবি'র (যেমন মঙ্গোডিবি বা কাউচডিবি) এর জন্য উল্লেখযোগ্য পারফরম্যান্সের সমস্যা সৃষ্টি করে না
প্রস্তাবিত সমাধান
ব্যবহারকারীরা যখন কোনও অ্যাকাউন্ট তৈরি করেন, তাদের একটি ইউইড দেওয়া হবে যা সার্ভার দ্বারা উত্পাদিত হয়েছিল এবং এটি সিস্টেমের মধ্যে অনন্য হিসাবে পরিচিত। এই আইডিটি অবশ্যই ব্যবহারকারীদের প্রমাণীকরণ টোকেনের মতো হবে না। আসুন এই আইডি ব্যবহারকারীদের "আইডি টোকেন" বলি।
যখন কোনও ব্যবহারকারী একটি নতুন রেকর্ড তৈরি করে, তারা জাভাস্ক্রিপ্টে একটি নতুন ইউইড তৈরি করে (যখন পাওয়া যায় উইন্ডো ক্রাইপ্টো ব্যবহার করে উত্পন্ন হয় examples উদাহরণ এখানে দেখুন )। এই আইডিটি ব্যবহারকারী যখন তাদের অ্যাকাউন্ট তৈরি করেছে তখন প্রাপ্ত "আইডি টোকেন" দিয়ে তা সংযুক্ত করে। এই নতুন যৌগিক আইডি (সার্ভার সাইড আইডি টোকেন + ক্লায়েন্ট সাইড ইউইড) এখন রেকর্ডের জন্য অনন্য শনাক্তকারী। যখন ব্যবহারকারী অনলাইন থাকে এবং ব্যাকএন্ড সার্ভারে এই নতুন রেকর্ডটি জমা দেয় তখন সার্ভারটি:
- এটি একটি "সন্নিবেশ" ক্রিয়া হিসাবে চিহ্নিত করুন (যেমন কোনও আপডেট বা মুছা নয়)
- যৌগিক কী উভয় অংশ বৈধ uuids বৈধ করুন
- বৈঠক করুন যে সম্মিলিত আইডির প্রদত্ত "আইডি টোকেন" অংশটি বর্তমান ব্যবহারকারীর জন্য সঠিক (উদাহরণস্বরূপ এটি যখন তারা তাদের অ্যাকাউন্ট তৈরি করবেন তখন ব্যবহারকারীকে নির্ধারিত সার্ভারের সাথে আইডি টোকেনের সাথে মেলে)
- যদি সবকিছু ডিবি মধ্যে copasetic, ডাটা সন্নিবেশ আছে (সাবধান হচ্ছে একটি সন্নিবেশ এবং একটি "upsert" কি তাই যে যদি আইডি আছে আগে থেকেই আছে এটা ভুল করে একটি বিদ্যমান রেকর্ড আপডেট করে না)
প্রশ্ন, আপডেট এবং মুছে ফেলার জন্য কোনও বিশেষ যুক্তির প্রয়োজন হবে না। তারা traditionalতিহ্যগত অ্যাপ্লিকেশনগুলির মতো একইভাবে রেকর্ডের জন্য আইডিটি ব্যবহার করতে পারে।
এই পদ্ধতির সুবিধা কি কি?
ক্লায়েন্ট কোড অফলাইনে থাকাকালীন নতুন ডেটা তৈরি করতে পারে এবং তত্ক্ষণাত সেই রেকর্ডটির আইডি জানতে পারে। আমি বিকল্প পদ্ধতি বিবেচনা করেছি যেখানে ক্লায়েন্টের উপর অস্থায়ী আইডি উত্পন্ন হবে যা সিস্টেমটি অনলাইনে থাকাকালীন পরে একটি "চূড়ান্ত" আইডি সরিয়ে নেওয়া হবে। তবে এটি খুব ভঙ্গুর মনে হয়েছিল। বিশেষত যখন আপনি বিদেশী কীগুলি সহ শিশুদের ডেটা তৈরির বিষয়ে চিন্তাভাবনা শুরু করেন যা আপডেট করাও প্রয়োজন। ইউআরএলগুলির সাথে ডিলের কথা উল্লেখ করা উচিত নয় যা আইডি পরিবর্তিত হবে।
আইডিএসকে একটি ক্লায়েন্ট উত্পাদিত মান এবং একটি সার্ভার উত্পন্ন মানের সংমিশ্রণ তৈরি করে প্রতিটি ব্যবহারকারী কার্যকরভাবে একটি স্যান্ডবক্সে আইডি তৈরি করে। এটি দূষিত / দুর্বৃত্ত ক্লায়েন্ট দ্বারা যে ক্ষয়টি করা যেতে পারে তা সীমাবদ্ধ করার উদ্দেশ্যে। এছাড়াও, কোনও আইডি সংঘর্ষগুলি প্রতিটি ব্যবহারকারী ভিত্তিতে হয়, পুরো সিস্টেমে বৈশ্বিক নয়।
যেহেতু কোনও ব্যবহারকারী আইডি টোকেন তাদের অ্যাকাউন্টে আবদ্ধ রয়েছে, তাই আইডিগুলি কেবলমাত্র ব্যবহারকারীদের স্যান্ডবক্সে প্রমাণিত যা ক্লায়েন্টদের দ্বারা উত্পন্ন করা যায় (যেমন যেখানে ব্যবহারকারী সফলভাবে লগ ইন করেছেন)। এটি ব্যবহারকারীর জন্য খারাপ আইডি তৈরি করা থেকে দূষিত ক্লায়েন্টদের রাখার উদ্দেশ্যে। অবশ্যই যদি কোনও ব্যবহারকারী লেখক টোকেন কোনও দূষিত ক্লায়েন্ট দ্বারা চুরি হয়ে যায় তবে তারা খারাপ কাজ করতে পারে। তবে, একবার কোনও লেখক টোকেন চুরি হয়ে গেলে অ্যাকাউন্টটি কোনওভাবেই আপোস করা হয়। এই ঘটনাটি ঘটলে, ক্ষতিটি আপোষকৃত অ্যাকাউন্টের মধ্যে সীমাবদ্ধ থাকবে (পুরো সিস্টেম নয়)।
উদ্বেগ
এই পদ্ধতির সাথে আমার কিছু উদ্বেগ এখানে
এটি কি বড় আকারের অ্যাপ্লিকেশনটির জন্য পর্যাপ্ত অনন্য আইডি তৈরি করবে? এর ফলে আইডি সংঘর্ষের ফলস্বরূপ ভাবার কোন কারণ আছে কি? জাভাস্ক্রিপ্ট এ কাজ করার জন্য পর্যাপ্ত পরিমাণে এলোমেলো ইউইড তৈরি করতে পারে? দেখে মনে হচ্ছে উইন্ডো। ক্রাইপ্টো মোটামুটিভাবে উপলব্ধ এবং এই প্রকল্পটির জন্য ইতিমধ্যে যুক্তিসঙ্গতভাবে আধুনিক ব্রাউজারগুলির প্রয়োজন। ( এই প্রশ্নের এখন নিজস্ব একটি পৃথক এসও প্রশ্ন রয়েছে )
আমি কি এমন কোনও ফাঁক ফাঁস করছি যা একটি দূষিত ব্যবহারকারীকে সিস্টেমের সাথে আপোস করার অনুমতি দিতে পারে?
2 ইউইউডের সমন্বিত সমন্বিত কীটির জন্য অনুসন্ধান করার সময় ডিবি পারফরম্যান্স নিয়ে চিন্তার কারণ রয়েছে কি? সেরা পারফরম্যান্সের জন্য এই আইডিটি কীভাবে সংরক্ষণ করা উচিত? দুটি পৃথক ক্ষেত্র বা একটি একক অবজেক্ট? মঙ্গো বনাম পালঙ্কের জন্য কি আলাদা "সেরা" পদ্ধতির ব্যবস্থা থাকতে পারে? আমি জানি যে একটি অ-অনুক্রমিক প্রাথমিক কী থাকা সন্নিবেশগুলি করার সময় উল্লেখযোগ্য পারফরম্যান্স সমস্যার কারণ হতে পারে। প্রাথমিক কীটির জন্য একটি স্বয়ংক্রিয় উত্পাদিত মান থাকা এবং এই আইডিটিকে একটি পৃথক ক্ষেত্র হিসাবে সঞ্চয় করা কী চৌর্য হবে? ( এই প্রশ্নের এখন নিজস্ব একটি পৃথক এসও প্রশ্ন রয়েছে )
এই কৌশলটির সাহায্যে এটি নির্ধারণ করা সহজ হবে যে নির্দিষ্ট ব্যবহারকারীদের দ্বারা রেকর্ডের একটি নির্দিষ্ট সেট তৈরি করা হয়েছিল (যেহেতু তারা সকলেই একই প্রকাশ্যে দৃশ্যমান আইডি টোকেন ভাগ করে নেবে)। যদিও আমি এটির সাথে কোনও তাত্ক্ষণিক সমস্যা দেখতে পাচ্ছি না, প্রয়োজনের তুলনায় অভ্যন্তরীণ বিশদ সম্পর্কিত আরও তথ্য লিক না করা ভাল। আর একটি সম্ভাবনা হ'ল সংমিশ্রিত কীটি হ্যাশ করা হবে তবে এটি মনে হয় এটির মূল্যটি এর চেয়ে বেশি সমস্যা হতে পারে।
যদি কোনও ব্যবহারকারীর জন্য আইডি সংঘর্ষ হয় তবে পুনরুদ্ধার করার সহজ উপায় নেই। আমি মনে করি ক্লায়েন্টটি একটি নতুন আইডি তৈরি করতে পারে, তবে এটি এমন একটি প্রান্তের ক্ষেত্রে প্রচুর কাজ বলে মনে হচ্ছে যা সত্যিই কখনও ঘটে না। আমি এই উদাসীন ছেড়ে যাওয়ার ইচ্ছা করছি।
কেবলমাত্র অনুমোদিত ব্যবহারকারীগণই ডেটা দেখতে এবং / বা সম্পাদনা করতে পারবেন। এটি আমার সিস্টেমের জন্য একটি গ্রহণযোগ্য সীমাবদ্ধতা।
উপসংহার
একটি যুক্তিসঙ্গত পরিকল্পনা উপরে? আমি বুঝতে পারি যে এগুলির কিছুটি প্রশ্নের মধ্যে থাকা অ্যাপ্লিকেশনটির সম্পূর্ণ বোঝার উপর ভিত্তি করে রায় সিদ্ধান্তে নেমে এসেছে।