روش انجام کار
دسترسی به داده؛ مدیر، همکار و مالک رکورد
برای هر نقش، خواندن، ساختن، ویرایش و حذف را مشخص کن و بررسی مجوز را در سمت سرور هم بخواه. با دو کاربر جدا آزمایش کن؛ پنهانکردن دکمه یا لینک، جای کنترل دسترسی به داده را نمیگیرد.
در این راهنما
#یک جدول مجوز بنویس
برای هر نوع داده، خواندن، ساختن، ویرایش و حذف را جدا مشخص کن. نقش «همکار محیط ساخت» را با نقش «کاربر اپ» یکی نگیر.
| نقش نمونه | دسترسی موردنیاز |
|---|---|
| مدیر اپ | مدیریت اعضا و مشاهدهٔ دادهٔ مجاز تیم. |
| همکار اپ | فقط مشتریان تخصیصدادهشده به خودش. |
| مهمان | فقط صفحات عمومی؛ بدون دادهٔ مشتری. |
#مجوز را در سمت سرور هم بخواه
پنهانکردن دکمه کافی نیست. درخواست مستقیم برای داده باید هم هویت و هم مجوز همان کاربر را بررسی کند.
هر مشتری مالک یا مسئول داشته باشد. خواندن و ویرایش داده در سمت سرور هم محدود شود. کاربر عادی حتی با تغییر شناسهٔ رکورد نتواند مشتری همکار دیگر را ببیند. آزمون مجاز و غیرمجاز را با دادهٔ ساختگی توضیح بده.
#آزمون منفی را فراموش نکن
- دو کاربر مجزا بساز
از دو نشست جدا استفاده کن تا ورود مدیر روی نتیجه اثر نگذارد.
- یک داده برای هر کاربر ثبت کن
هر کاربر باید دادهٔ خودش را ببیند و دادهٔ دیگری را نبیند.
- مسیر مستقیم را بررسی کن
لینک رکورد خصوصی را در نشست دیگر باز کن؛ پاسخ نباید محتوای آن را نشان بدهد.
#چه زمانی انتشار را متوقف کنی؟
اگر کاربر دوم دادهٔ اول را دید، تا رفع و آزمون دوباره دادهٔ واقعی وارد نکن. نتیجهٔ اسکن امنیتی کمککننده است اما جای آزمون مجوزهای مخصوص اپ را نمیگیرد.
#پیش از دادن دسترسی به دادهٔ واقعی
- برای هر عمل، مالک داده و نقش مجاز مشخص است.
- کاربر نامجاز با بازکردن مستقیم نشانی هم محتوا را نمیبیند.
- ورود موفق، اجازهٔ دیدن همهٔ رکوردها محسوب نمیشود.
- آزمون را پس از تغییر ورود، نقش یا ساختار داده دوباره انجام بده.
#اگر به نتیجه نرسیدی
| نشانه | اقدام بعدی |
|---|---|
| کاربر دوم رکورد خصوصی اول را دید | استفاده از دادهٔ واقعی را متوقف کن و کنترل مجوز سمت سرور را اصلاح و دوباره آزمایش کن. |
| مدیر میبیند اما کاربر مجاز نمیبیند | نقش و مسئول رکورد را بررسی کن؛ عمومیکردن همهٔ دادهها راهحل نیست. |
قدم بعد