ব্যবহারকারীর প্রমাণীকরণ (ভূমিকা ও অধিকার) মডিউলটি ডিজাইন করা


15

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

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

আমি প্রতিটি ইভেন্টে যখন কোনও ব্যবহারকারী লগ ইন করে আউট হয়ে যায় তার জন্যও একটি ইভেন্ট লগ করতে চাই। আমি এটি ভবিষ্যতে অতিরিক্ত ইভেন্টগুলিতে প্রসারিত করতে পারি।

নীচে আপনি এটিতে আমার প্রথম ক্র্যাক পাবেন। এটির উন্নতি করার জন্য দয়া করে আমাকে কোনও পরামর্শ জানান, কারণ এটি আমার প্রথম কাজ।

আপনি কী ভূমিকা-ভিত্তিক সুরক্ষা এবং পাসওয়ার্ডের নিয়ম / মেয়াদোত্তীর্ণ সময়কালের জন্য বাধাগুলির জন্য অতিরিক্ত বৈশিষ্ট্যের কোনও প্রয়োজন দেখেন?

ডিবি ডিজাইন


একটি বিশদ ব্লগ এখানে: goo.gl/ATnj6j
সুরেশ কামরুশি

1
আমি কিছু বুঝতে পারি না। ব্যবহারকারীর টেবিলে আপনার গ্রুপ_আইড রয়েছে। কোনও ব্যক্তি কি একাধিক গ্রুপের সদস্য হতে পারেন?
জনি

উত্তর:


11

আপনার বর্ণিত প্রয়োজনীয়তার ভিত্তিতে, আপনার মডেলটি বেশ ভাল আকারে রয়েছে।

উন্নতির জন্য এখানে কিছু পরামর্শ দেওয়া হল:

  • আপনি এতটা স্পষ্ট করে বলবেন না, তাই বলা শক্ত - তবে মনে হচ্ছে আপনি সম্ভবত ব্যবহারকারীর পাসওয়ার্ড সরাসরি সংরক্ষণ করছেন। এটা খুব খারাপ হবে! আপনি যদি সাধারণ প্রমাণীকরণের ডাটাবেসগুলিতে লক্ষ্য করেন তবে পাসওয়ার্ডগুলি এনক্রিপ্ট করা আকারে সংরক্ষণ করা হয়। আপনি প্রায়শই একটি passwordকলাম এবং কলাম উভয়ই দেখতে পাবেন password_salt

  • আপনার USER_LOGSটেবিলের একটি Eventকলাম রয়েছে। কীভাবে এটি জনবহুল হবে সে সম্পর্কে আপনি পরিষ্কার নন। রেফারেন্স কোন EVENT_TYPEটেবিল থাকা উচিত USER_LOGS? এটি বন্ধুত্বপূর্ণ রিপোর্টিংয়ের জন্য তৈরি করতে পারে। সাধারণ ইভেন্টগুলির মধ্যে লগ-ইন, লগ-আউট, পাসওয়ার্ড ব্যর্থ হওয়া, পাসওয়ার্ড পরিবর্তন, পাসওয়ার্ড পুনরায় সেট করা, লক আউট, আনলক, ...

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

আপনার বর্ণিত ব্যবসায়ের প্রয়োজনীয়তার চারপাশে এখানে কয়েকটি প্রশ্ন রয়েছে যা কয়েকটি উপায়ে "পাঠ্যপুস্তক" রোল-ভিত্তিক সুরক্ষা প্যাটার্ন থেকে পৃথক:

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

  • আপনার নকশা কেবল অনুদানযোগ্য। কিছু সিস্টেমে অনুদান এবং প্রত্যাহার অন্তর্ভুক্ত । এটি আপনাকে বলতে অনুমতি দেয় যে একটি বিস্তৃতভাবে উপলব্ধ কোনও নির্দিষ্ট গোষ্ঠীতে উপলব্ধ right

  • USERSআপনার নকশায় যেমন ব্যবহারকারীর অ্যাকাউন্ট রয়েছে । লোক এবং ব্যবহারকারী ID এর মধ্যে প্রায়শই পার্থক্য রয়েছে । কিছু ব্যবহারকারী আইডি টিম বা মেশিনের জন্য হয় এবং কিছু লোকের বিভিন্ন উদ্দেশ্যে একাধিক ব্যবহারকারী আইডি থাকে। এটি কি কোনও পার্থক্য যা আপনার পক্ষে সহায়ক হবে?


3

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

নীচে কয়েকটি নমুনা ডেটা সহ একটি নমুনা টেবিল রয়েছে:

সারণী 1 : অনুমতি টেবিলের সাথে অনুমতি নামের সাথে এটি 1,2,4,8..etc (2 এর একাধিক) সংরক্ষণ করুন

CREATE TABLE IF NOT EXISTS `permission` (
  `bit` int(11) NOT NULL,
  `name` varchar(50) NOT NULL,
  PRIMARY KEY (`bit`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

সারণিতে কিছু নমুনা তথ্য প্রবেশ করান।

INSERT INTO `permission` (`bit`, `name`) VALUES
(1, 'User-Add'),
(2, 'User-Edit'),
(4, 'User-Delete'),
(8, 'User-View'),
(16, 'Blog-Add'),
(32, 'Blog-Edit'),
(64, 'Blog-Delete'),
(128, 'Blog-View');

সারণী 2 : ব্যবহারকারীর আইডি, নাম এবং ভূমিকা রাখতে ব্যবহারকারী সারণী table ভূমিকার অনুমতি হিসাবে যোগফল হিসাবে গণনা করা হবে।
উদাহরণ:
যদি ব্যবহারকারী 'কেতন' এর সাথে 'ব্যবহারকারী-যোগ' (বিট = 1) এবং 'ব্লগ-মুছুন' (বিট -৪)) অনুমতি থাকে তবে ভূমিকাটি 65 (1 + 64) হয়ে যাবে।
যদি ব্যবহারকারী 'মেহতা' 'ব্লগ-ভিউ' (বিট = 128) এবং 'ব্যবহারকারী-মুছুন' (বিট -4) এর অনুমতি পেয়ে থাকেন তবে ভূমিকাটি হবে 132 (128 + 4)।

CREATE TABLE IF NOT EXISTS `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(50) NOT NULL,
  `role` int(11) NOT NULL,
  `created_date` datetime NOT NULL
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1;

নমুনা তথ্য-

INSERT INTO `user` (`id`, `name`, `role`, `created_date`)
   VALUES (NULL, 'Ketan', '65', '2013-01-09 00:00:00'),
   (NULL, 'Mehata', '132', '2013-01-09 00:00:00');

ব্যবহারকারীর লডিংয়ের অনুমতি লগইনের পরে যদি আমরা ব্যবহারকারীর অনুমতি লোড করতে চাই তবে অনুমতিগুলি পাওয়ার জন্য নীচে জিজ্ঞাসা করতে পারি:

SELECT permission.bit,permission.name  
   FROM user LEFT JOIN permission ON user.role & permission.bit
 WHERE user.id = 1

এখানে ব্যবহারকারীর "" "অনুমতি.বিট একটি বিটওয়াস অপারেটর যা আউটপুট হিসাবে দেবে -

User-Add - 1
Blog-Delete - 64

আমরা যদি আবহাওয়া পরীক্ষা করতে চাই তবে নির্দিষ্ট ব্যবহারকারীর ব্যবহারকারীর সম্পাদনার অনুমতি আছে বা না-

  SELECT * FROM `user` 
     WHERE role & (select bit from permission where name='user-edit')

আউটপুট = কোনও সারি নেই।

আপনি আরও দেখতে পারেন: http://goo.gl/ATnj6j


100 এর মতো অনুমতিগুলি অনেক হলে আমরা কী করব?
ypercubeᵀᴹ

2
আপনি তিনটি অভিন্ন উত্তর পোস্ট করেছেন - বিভিন্ন প্রশ্নের! -, কয়েক মিনিটের ব্যবধানে সবাই আজ পোস্ট করেছে। এটি ভাল অনুশীলন নয়। যদি আপনি মনে করেন যে প্রশ্নগুলি অভিন্ন বা যথেষ্ট পরিমাণে সমান, তবে আপনি সেগুলি নকল হিসাবে বন্ধ করতে ভোট দিতে পারেন (বা বন্ধ করার পক্ষে যদি আপনার সুনাম না থাকে তবে এগুলি পতাকাঙ্কিত করুন)।
ypercubeᵀᴹ

দয়া করে আপনার
লিঙ্কটিও

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