|
Скрыть поля в таблице users
|
|||
---|---|---|---|
#18+
Добрый день! Есть таблица users, в ней пользователи хранят свои персональные данные. Часть полей, такие как email или phoneNumber являются обязательными для заполнения, но тем, не менее, пользователь по желанию хотел бы закрыть эти поля для публики. На таблицу смотрит сервер node.js и на сайт выводит json по полям этой таблицы. Если пользователь не хочет, чтобы его данные были доступны всем пользователям сайта, то где в базе хранить эти запреты? Как это оптимальнее всего спроектировать? Как это делают социальные сети обычно? Мне На ум приходит только создать еще поле типа hideEmail = true или hidePhone = true и программно анализировать эти поля и в зависимости от этого уже выводить эту информацию или нет. Буду рад любым идеям на этот счет. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2021, 14:17 |
|
Скрыть поля в таблице users
|
|||
---|---|---|---|
#18+
Elfix Мне На ум приходит только создать еще поле типа hideEmail = true или hidePhone = true и программно анализировать эти поля и в зависимости от этого уже выводить эту информацию или нет. А что, есть какой--то иной путь? Не можно конечно управлять видимостью объектов на форме/странице, но это некорректно. Корректно именно что никак не выдавать инфу на клиента, если она закрыта. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2021, 14:31 |
|
Скрыть поля в таблице users
|
|||
---|---|---|---|
#18+
Elfix Как это оптимальнее всего спроектировать? Без взгляда на проект в целом это довольно бессмысленный вопрос. Решений может быть множество, но если попытаться угадать.... я бы вообще разделил "обязательные по бизнес-логике внутренние поля" и "то, что показывается публике". То есть пусть будет таблица users, где эти поля обязательные, и будет таблица user_info, где пользователь отмечает только то, что хочет показать (в том числе, возможно, другой емейл, отличный от того, с которым он зарегистрирован в системе). ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2021, 15:10 |
|
Скрыть поля в таблице users
|
|||
---|---|---|---|
#18+
Кесарь, об этом и речь. Сервер должен в json не выводить поля, к которым пользователь не хочет давать доступ. А клиент в свою очередь в браузере уже будет размещать на формах те значения, которые пришли с сервера. Вопрос в том, как правильнее хранить эти поля в базе, чтобы серверу откуда-то читать предпочтения пользователя. авторБез взгляда на проект в целом это довольно бессмысленный вопрос. Решений может быть множество, но если попытаться угадать.... я бы вообще разделил "обязательные по бизнес-логике внутренние поля" и "то, что показывается публике". То есть пусть будет таблица users, где эти поля обязательные, и будет таблица user_info, где пользователь отмечает только то, что хочет показать (в том числе, возможно, другой емейл, отличный от того, с которым он зарегистрирован в системе).Там смотреть не на что :) Одна таблица users. Я думаю это не очень хорошая идея дублировать информацию по одному и тому же пользователю. По сути есть два пути: 1. В таблице users сделать еще поля с типом boolean, с префиксом hide. 2. Создать еще таблицу с вторичным ключом и перечислить наименования столбцов, доступ к которым запрещен. Или есть еще какой-то способ? По мне, первый метод очень перегружает таблицу, а второй серьезно усложняет работу с ней на сервере перед тем как отдавать json клиенту. Что скажете? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2021, 16:08 |
|
Скрыть поля в таблице users
|
|||
---|---|---|---|
#18+
Elfix, если вы не хотите делать широкую таблицу (хотя как её сильно уж расширят два битовых поля?), то можете вынести эти данные в отдельную таблицу и сделать связь один к одному. User (ID ...) UserInfo (ID, Email, EmailIsHide, Phone, PhoneIsHide) и два покрывающих индекса по ней: idx1 (ID, EmailIsHide) include (Email) idx2 (ID, PhoneIsHide) include (Phone) которые будете использовать примерно так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2021, 18:14 |
|
Скрыть поля в таблице users
|
|||
---|---|---|---|
#18+
Кесарь, Проблема в том, что таких полей в таблице уже около 20 (телефон, почта, адрес, город и т. п.). И добавление построчно этих полей в отдельную таблицу и многократное левое соединение кажется мне очень трудоемкой операцией в данном случае. Опять же, на форме я представляю себе, что пользователь вводит данные в поле и слева ставит галку "скрыть от посторонних". А значит при сохранении мне нужно будет обновить две таблицы одновременно, что тоже представляется мне не очень быстрой операцией... Все же наверное придется пользоваться широкой таблицей для этого случая. Или... а что если в поле phoneNumber например хранить json? В формате: { value: +790611455121 visibled: false } Или выборка и анализ в такой базе будет сильно усложнен? Работаю в PostgreSQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2021, 21:00 |
|
Скрыть поля в таблице users
|
|||
---|---|---|---|
#18+
Поле типа int32 (или int64) с битовой маской для показа/скрытия ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2021, 22:46 |
|
Скрыть поля в таблице users
|
|||
---|---|---|---|
#18+
SERG1257 Поле типа int32 (или int64) с битовой маской для показа/скрытия ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2021, 22:50 |
|
Скрыть поля в таблице users
|
|||
---|---|---|---|
#18+
Elfix Кесарь, Проблема в том, что таких полей в таблице уже около 20 (телефон, почта, адрес, город и т. п.). И добавление построчно этих полей в отдельную таблицу и многократное левое соединение кажется мне очень трудоемкой операцией в данном случае. Ну так вы ж не сказали, что их уже 20-ть. Вопрос, зачем и почему пользователю разрешено/предложено управлять видимостью на таком атомарном уровне? показать/скрыть телефон, емейл, адрес (без разбиения) и всё, достаточно. Что за задача такая? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2021, 23:54 |
|
Скрыть поля в таблице users
|
|||
---|---|---|---|
#18+
ElfixНе понял, можно подробнее? https://ru.wikipedia.org/wiki/Битовая_маска Одно поле int32 на все 20 полей (показывать или нет). Также можно использовать массив битовых значений. https://www.postgresql.org/docs/current/arrays.html Будет по сути тоже самое Нарушение конечно первой нормальной формы. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2021, 00:32 |
|
Скрыть поля в таблице users
|
|||
---|---|---|---|
#18+
Elfix Как это делают социальные сети обычно? Социальные сети обычно эти данные не показывают по умолчанию, иначе бы в них никто не регистрировался, за исключением тех сетей которые без этого не могут существовать (ватсап и т.д. без телефона не имеют смысла)... С одной стороны при регистрации телефон и почта могут быть обязательными реквизитами. С другой стороны, юзер при регистрации может указать способ обращения к нему других юзеров: - никак - только по почте - только по телефону - любым способом, только зарегистрированные - только по почте не зарегистрированные ... Для этого достаточно одного поля integer в таблице users, которое и заполняет юзер при регистрации и может потом изменить его как один из параметров личных данных. Соответственно в интерфейсе от этого параметра и будет зависеть показ контактов для других юзеров, json должен вытаскивать или реальные значения или показывать пустышку в зависимости от установленного юзером параметра... Возможны случаи когда вопрос с контактами определяется на уровне Администратора сети, но и тогда скорее всего будет кнопка "Написать" Юзеру (без разглашения почтового ящика) или будет кнопка "Позвонить", только после нажатия на которую появиться телефон куда звонить... Ну как бы по умолчанию показывать все контакты это только для внутренней сети нормально... ... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2021, 13:33 |
|
Скрыть поля в таблице users
|
|||
---|---|---|---|
#18+
Elfix, Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). Вам на сколько понимаю нужен ABAC Вот здесь немного: https://habr.com/ru/company/custis/blog/248649/ Вообще посмотрите GraphQl+JWT готовые реализации. Пример библиотечки https://casbin.org/docs/en/supported-models ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2021, 17:37 |
|
Скрыть поля в таблице users
|
|||
---|---|---|---|
#18+
Elfix, Если у вас PostgreSQL, то возможно вам будет достаточно RLS, Row-Level Security https://postgrespro.ru/docs/postgrespro/9.6/ddl-rowsecurity ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2021, 18:48 |
|
|
start [/forum/topic.php?fid=32&gotolast=1&tid=1539782]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
63ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
2ms |
others: | 11ms |
total: | 170ms |
0 / 0 |