Разрешение облачной функции против validationHandler

Нашел себе открытие нескольких функций для доступа к пользователям с недействительными токенами сеанса. Единственный способ, который я смог найти, - перехватить запрос с помощью bodyParser, прежде чем Parse получит запрос и удалит sessionToken из запроса.Разрешение облачной функции против validationHandler

Теперь пытается сделать лучшую работу управления разрешением на все функции - Мой вопрос являются:

я могу расслабиться требование, если sessionToken включен, он должен быть действителен в любой другой форме? Проверяется ли проверка маркера сеанса с помощью параметра validationHandler по умолчанию, который может быть заменен или выполняется в другом месте?
для управления доступом к облачным функциям, есть ли что-то вроде роли ACL? действительно ли функция validationHandler для облачной функции принимает только параметр? или я могу также проверить объект пользователя?

источник

2016-08-06 Ron Bresler

Да. В parse-сервере вы можете убедиться, что сеансы действительны, потому что если вы попытаетесь запустить любую операцию CRUD с недопустимым сеансом, вы получите сообщение об ошибке http 403, что ваш сеанс недействителен или истек. Вы можете контролировать «Длина» вашего сеанса, изменив значение sessionLength в вашем синтаксическом аналитическом приложении. Значение по умолчанию 1 год
Там нет контроля доступа к облачным функциям, но вы можете проверить, если вход в триггере пользователя этой функции, проверяя, если request.user не определен. Облачные функции могут получать только параметры в парах ключ-значение, и эти параметры не могут быть элементами анализа. если вы хотите отправить ParseObject, вы можете отправить объекту objectId объекта parse, а затем запросить его в облачном коде, чтобы получить полный объект. Вы всегда можете получить доступ к контексту пользователя в request.user (только если код облака был вызван пользователем). Если вы все же хотите «защитить» свой облачный код, вы можете проверить, имеет ли вызывающий пользователь роль, запросив Бит роли и проверить, содержится ли там пользователь.

источник

2016-08-06 18:12:12

Спасибо Ran, может быть, я должен быть более ясным - 1) Я действительно спрашивал, есть ли способ разрешить недействительные токены доступа к моей функции облачного кода. Причина, по которой я спрашиваю об этом, состоит в том, что некоторые функции доступны для доступа неавторизованных пользователей. Однако, если у пользователя есть устаревшая сессия в его запросе, ему будет отказано. Обходной путь, который я нашел для этого, - это перехват запроса до его получения сервером анализа и удаление любого токена сеанса, если он передан этим общедоступным запросам. только тогда я могу обеспечить, чтобы синтаксический анализ обрабатывал запросы. Но я надеялся, что есть лучший способ. –

2) Есть некоторые правила доступа, которые мне нужно применять - я не полагаюсь только на ACL для авторизации. Поэтому мне нужен еще один механизм авторизации. Но validationHandler получает только параметры, а не request.user. Мне нужно запустить общий код для соответствия параметрам каждого запроса с привилегиями пользователя. Поэтому мне нужно что-то похожее на validationHandler, только у которого есть доступ к объекту пользователя. Опять же, я могу, возможно, сделать это, обернув каждый обработчик функции с помощью функции проверки проверки полномочий, но если я могу вместо этого зарегистрировать функции проверки полномочий, это было бы лучше –

. Вы можете отправить идентификатор объекта пользователя с клиента, а затем читать его в облачном коде? –

Разрешение облачной функции против validationHandler

ответ

Смежные вопросы