всем привет,
такая ситуация:
есть группа непостоянных случайных юзеров, которых не хотят или нет необходимости делать Портальными пользователями.
Эти сайтовые юзеры создают запись, и после могут ее редактировать. Но как обеспечить доступ юзера только к собственным записям?
здесь не идет речь об создании кастомной аутентификации сайтовых юзеров (кстати, мы обсуждали уже это и пришли к выводу, что проще купить портальные лицензии)
здесь нужно правильно ограничить доступ юзеролв к записям. понятно что для системы сайтовый юзер - он всегда один, и поэтому он имеет доступ ко всем записям опредленной категории. как обезопасить доступ к записям?
вопрос возник из идеи давать юзерам номер записи (который последователен у всех записей). Это приведет к тому что можно предугать номер чужой записи и по нему получить чужую запись на редактирование. У меня была идея генерировать токен, и давать юзеру для ввода номер записи + токен.
но менеджер предложил: да зачем париться, давайте ID записи и берите только этот ID для ввода при получении записи на редактирование, и все, а давать ли номер записи - это уже ваше дело, все равно юзер его не использует в данном сценарии.
Что вы думаете по этому поводу?
всем привет, такая ситуация: есть группа непостоянных случайных юзеров, которых не хотят или нет необходимости делать Портальными пользователями. Эти сайтовые юзеры создают запись, и после могут ее редактировать. Но как обеспечить доступ юзера только к собственным записям? здесь не идет речь об создании кастомной аутентификации сайтовых юзеров (кстати, мы обсуждали уже это и пришли к выводу, что проще купить портальные лицензии) здесь нужно правильно ограничить доступ юзеролв к записям. понятно что для системы сайтовый юзер - он всегда [b]один[/b], и поэтому он имеет доступ ко всем записям опредленной категории. как обезопасить доступ к записям? вопрос возник из идеи давать юзерам номер записи (который последователен у всех записей). Это приведет к тому что можно предугать номер чужой записи и по нему получить чужую запись на редактирование. У меня была идея генерировать токен, и давать юзеру для ввода номер записи + токен. но менеджер предложил: да зачем париться, давайте ID записи и берите только этот ID для ввода при получении записи на редактирование, и все, а давать ли номер записи - это уже ваше дело, все равно юзер его не использует в данном сценарии. Что вы думаете по этому поводу?
Id вполне сойдет для пользорвателя чтобы ограничить его в правах на запись - это если предполагается что пользователь знает эти Id и хранит их у себя (в виде ссылки или чисто Id). Не думаю что среднестатистический пользователь сможет подобрать Id не своих записей.
Собственно так и работают многим прилаги с которыми я сталкивался - генерится какой-то объект, например предложение о чем либо, индивидуальное - просто на мыло отсылается линк на страницу, которая перевариваем этот Id. Пользователь имеет ссылку, значит имеет право открыть запись.
Если что-то посложнее - то только кастомная авторизация, но я тут не будут описывать как ее реализовать Все опытные - делали 100 раз.
Id вполне сойдет для пользорвателя чтобы ограничить его в правах на запись - это если предполагается что пользователь знает эти Id и хранит их у себя (в виде ссылки или чисто Id). Не думаю что среднестатистический пользователь сможет подобрать Id не своих записей. Собственно так и работают многим прилаги с которыми я сталкивался - генерится какой-то объект, например предложение о чем либо, индивидуальное - просто на мыло отсылается линк на страницу, которая перевариваем этот Id. Пользователь имеет ссылку, значит имеет право открыть запись. Если что-то посложнее - то только кастомная авторизация, но я тут не будут описывать как ее реализовать :) Все опытные - делали 100 раз.
да, это правильно.
но сбивают с толку встречающиеся в жизни "традиционные" варианты, когда после сохранения записи выдается какое-то сообщение пользователю, какие-то указания, как быть дальше. Обычно дается какой то номер и линк на страницу, где это можно проверить. в таком случае пользователь должен сохранить и линк и номер для ввода. А если пользователю предложить уже готовый линк с урл параметром? выглядит хорошо, хотя привычным кажется "традиционая" схема: страница и номер для ввода.
[quote="Dmitry Shnyrev"] просто на мыло отсылается линк на страницу, которая перевариваем этот Id[/quote] да, это правильно. но сбивают с толку встречающиеся в жизни "традиционные" варианты, когда после сохранения записи выдается какое-то сообщение пользователю, какие-то указания, как быть дальше. Обычно дается какой то номер и линк на страницу, где это можно проверить. в таком случае пользователь должен сохранить и линк и номер для ввода. А если пользователю предложить уже готовый линк с урл параметром? выглядит хорошо, хотя привычным кажется "традиционая" схема: страница и номер для ввода.
А если использовать "половинчатую" авторизацию - зашел пользователь на сайт, ему предлагается ввести какой-нибудь keyword, который потом кладётся в cookies и прикрепляется к записям в кастомное поле, например с именем Tag__c. И соответственно пользователю фильтровать записи только с этим тэгом.
А если использовать "половинчатую" авторизацию - зашел пользователь на сайт, ему предлагается ввести какой-нибудь keyword, который потом кладётся в cookies и прикрепляется к записям в кастомное поле, например с именем Tag__c. И соответственно пользователю фильтровать записи только с этим тэгом.
Поддержу эту идею.
Не соглашусь с отсутствием необходимости шифровать id, они секвентальны и лучше эту информацию от пользователя скрыть за простейшим токеном сгенерированым приватным ключом.
[quote="ilya leshchuk"]А если использовать "половинчатую" авторизацию - зашел пользователь на сайт, ему предлагается ввести какой-нибудь keyword, который потом кладётся в cookies и прикрепляется к записям в кастомное поле, например с именем Tag__c. И соответственно пользователю фильтровать записи только с этим тэгом.[/quote] Поддержу эту идею. Не соглашусь с отсутствием необходимости шифровать id, они секвентальны и лучше эту информацию от пользователя скрыть за простейшим токеном сгенерированым приватным ключом.