Що таке керування доступом? 
За допомогою FastComments SSO Access Control, іноді званого RBAC, користувачам можна обмежити доступ лише до певних сторінок або стрічок коментарів. Крім того, користувачі можуть @mention один одного лише в межах тієї ж групи.
Детальніше
Ми можемо розміщувати Users і за потреби Pages у групах.
Коли Users розміщені в групах і в Налаштуваннях віджета увімкнено Limit Comments by SSO User Groups, користувачі бачитимуть лише коментарі від користувачів зі своїх груп і зможуть @mention тільки користувачів тієї ж групи.
Додатково, Pages можна розміщувати у групах, і тоді користувачі зможуть отримувати доступ лише до коментарів для сторінок, до яких вони мають доступ.
Ми називаємо це "User-Level" groups на відміну від "Page-Level" groups.
То який підходить вам?
Use User-Level Groups if...
- Ви хочете використовувати один і той же
urlId(URL сторінки або ID статті), але обмежити коментарі за групами. - Наприклад, ви хочете мати групи «Новий користувач» і «Досвідчений користувач», і вони ніколи не повинні бачити коментарі один одного на тих самих сторінках.
Use Page-Level Groups if...
- Ваші групи прив'язані до конкретних сторінок.
- Наприклад, користувачі в групі «Публічні сторінки» ніколи не повинні переглядати статті в групі «Цілком секретні».
Як це працює
FastComments Access Control працює шляхом призначення Pages і Users у потрібні групи.
Група — це просто рядковий ідентифікатор, наприклад GREEN або abc-123.
Users і Pages не обмежуються лише однією групою. Вони обмежені 100 і 1000 групами відповідно.
Доступ до неавторизованих сторінок
Якщо користувач намагається отримати доступ до сторінки, до якої він не має доступу, він побачить повідомлення про помилку, як показано нижче:
Текст повідомлення можна налаштувати.
Специфікація
Визначення того, як кілька користувачів взаємодіють, і тестування цього є складним. Ось специфікація, яку ми використовуємо для контролю доступу, яку ви можете використати для тестування вашої реалізації:
Page with null group ids, user with null group ids - повинен мати доступ.
Page with null group ids, user with group ids - повинен мати доступ.
Page with group ids, user with null group ids - повинен мати доступ.
Page with group ids, user with empty list - НЕ повинен мати доступ.
Page with group ids, user with group ids - intersection exists - повинен мати доступ.
Page with group ids, user with group ids - intersection does not exist - НЕ повинен мати доступ.
Page with empty list of group ids (nobody has access), user with null - НЕ повинен мати доступ.
SSO User A = group ids не визначені (null = повний доступ).
SSO User B = group ids не визначені (null = повний доступ).
A може @B.
SSO User A = group ids не визначені (null = повний доступ).
SSO User B = group ids визначені.
A може @B.
SSO User A = group ids визначені.
SSO User B = group ids не визначені (null = повний доступ).
A може @B.
SSO User A = group ids = [a].
SSO User B = group ids = [b].
A НЕ може @B.
SSO User A = group ids = [a].
SSO User B = group ids = [a, b].
A може @B.Реалізація
Згадування користувачів в інших групах
Якщо двоє користувачів належать до двох різних наборів груп, і між ними немає перетину, вони не зможуть @mention один одного.
Якщо користувач вручну введе @mention і відправить свій коментар, воно залишиться як звичайний текст. Інший користувач не буде позначений.
Підтримка груп
Groups визначаються за допомогою API-ресурсів Pages і SSOUsers відповідно.
API Pages може бути викликано, щоб визначити набір груп, яким дозволено доступ до сторінки. За замовчуванням доступ мають усі групи, та користувачі, які не належать до жодної групи.
Аналогічно, API SSOUsers може бути викликано, щоб визначити групи, пов'язані з кожним користувачем.
Для обох ресурсів немає обмежень щодо того, коли групи можуть бути встановлені або оновлені.
Якщо бажано лише обмежити можливість користувачів @mention один одного, тоді Pages не потрібно брати до уваги.
Примітка!
Визначення та оновлення груп користувачів SSO не вимагає використання API і натомість може оновлюватися автоматично шляхом визначення group ids у SSO payload, що передається віджету коментарів. Однак для великих списків груп цього не рекомендовано, оскільки користувачу доведеться надсилати цей payload при кожному завантаженні сторінки.
Приклади викликів API
Тут ми пройдемо процес виклику API FastComments для налаштування контролю доступу.
Перш ніж почати, зауважте, що нам не потрібно явно створювати структуру Group. Групи — це просто ідентифікатори
додані до Users та Pages. Додавання групи до користувача або сторінки автоматично "creates" the group.
Спочатку створимо двох користувачів, User A та User B; розмістимо їх у Group X:
Тепер створимо Page. Назвемо її Confidential Page, і наразі жоден із цих користувачів не матиме до неї доступу, оскільки вона належатиме групі CONFIDENTIAL:
Користувачі A і B наразі НЕ МАЮТЬ доступу до нової сторінки. Однак, оскільки вони в одній групі, GROUP-X, вони можуть @mention один одного.
Оновимо User B, щоб він тепер міг отримати доступ до сторінки:
User B тепер належить до обох груп. Наші користувачі досі можуть @mention один одного, але тільки User B може переглядати нашу конфіденційну сторінку.
Зробимо так, щоб User B міг бачити тільки конфіденційну сторінку:
Тепер він може переглядати конфіденційну сторінку, але жоден з наших користувачів не може @mention один одного, оскільки вони в різних групах.
Однак будь-який користувач, який не є частиною контролю доступу, зможе отримати доступ до нашої сторінки. Щоб уникнути цього, переконайтеся, що жоден SSO Users не має groupIds, встановленого в null. Наприклад, створімо User C, який має доступ до всього:
Встановивши groupIds в null, ми вказуємо, що вони не обмежені контролем доступу.
Тепер створімо сторінку, до якої мають доступ усі:
Встановивши accessibleByGroupIds в null, ми вказуємо, що ця Page не контролюється через контроль доступу, і обидва користувачі можуть отримати до неї доступ.
Це завершує наш огляд API щодо контролю доступу.