Керування доступом SSO
Що таке керування доступом? 
Завдяки FastComments SSO Access Control, який іноді називають RBAC, користувачів можна обмежити доступом лише до певних сторінок або гілок коментарів. Крім того,
користувачі можуть згадувати один одного через @mention лише в межах однієї групи.
Детальніше
Ми можемо розмістити Users і, за бажанням, Pages у групах.
Коли Users розміщені в групах, і в налаштуваннях віджета увімкнено Limit Comments by SSO User Groups, користувачі
бачитимуть лише коментарі користувачів зі своїх груп і зможуть згадувати через @mention лише користувачів із тих самих груп.
Крім того, Pages можна розмістити в групах, і тоді користувачі зможуть отримувати доступ лише до коментарів сторінок, до яких мають доступ.
Ми називаємо це групами «рівня користувача» на противагу групам «рівня сторінки».
То який варіант підходить саме вам?
Використовуйте групи рівня користувача, якщо...
- Ви хочете використовувати однакове значення
urlId(URL сторінки або ID статті), але обмежувати коментарі за групами. - Наприклад, ви хочете мати групи «Новий користувач» і «Досвідчений користувач», і вони ніколи не повинні бачити коментарі одне одного на одних і тих самих сторінках.
Використовуйте групи рівня сторінки, якщо...
- Ваші групи мають конкретні сторінки.
- Наприклад, користувачі в групі «Публічні сторінки» ніколи не повинні переглядати статті з розділу «Цілком таємно».
Як це працює
FastComments Access Control працює шляхом призначення Pages і Users у потрібні групи.
Група — це просто рядковий ідентифікатор, наприклад GREEN або abc-123.
Users і Pages не обмежуються лише однією групою. Вони обмежені 100 і 1000 групами відповідно.
Доступ до неавторизованих сторінок
Якщо користувач намагається отримати доступ до сторінки, до якої він не має доступу, він побачить повідомлення про помилку, як показано нижче:
Текст повідомлення можна налаштувати.
Специфікація
Визначення того, як взаємодіють кілька користувачів, і її тестування — це складне завдання. Ось специфікація, якої ми дотримуємося для контролю доступу, і яку ви можете використати для тестування своєї реалізації:
Сторінка з null group ids, користувач з null group ids - доступ має бути.
Сторінка з null group ids, користувач з group ids - доступ має бути.
Сторінка з group ids, користувач з null group ids - доступ має бути.
Сторінка з group ids, користувач з порожнім списком - доступу НЕ має бути.
Сторінка з group ids, користувач з group ids - перетин існує - доступ має бути.
Сторінка з group ids, користувач з group ids - перетин відсутній - доступу НЕ має бути.
Сторінка з порожнім списком group ids (доступ ні в кого), користувач з 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 щодо контролю доступу.