2016-06-22 2 views
1

Я хочу полностью отделить свое клиентское приложение от сервера Parse, чтобы облегчить переход на другой Baas/custom backend в будущем. Таким образом, весь запрос клиента указывает на сервер node.js, который сделает запрос на Parse от имени пользователя.Parse Server Node.js SDK: альтернатива Parse.User.become?

Client <--> Node.js Server <--> Parse Server 

Таким образом, мне нужен сервер Node.js, чтобы иметь возможность переключаться между пользователями, так что я могу держать контекст их аутентификации.

Я знаю, как сначала авторизуйтесь, а затем сохранить sessionToken пользователя, и я видел во время моего исследования, чем «принято» решение этой проблемы должно было назвать Parse.User.disableUnsafeCurrentUser, а затем с помощью Parse.User.become() для переключения текущего пользователя к одному сделать запрос.

Но это чувствует себя взломанным, и я уверен, что это рано или поздно приведет к состоянию гонки, когда текущий пользователь переключается до того, как запрос будет сделан в Parse.

Другое решение, которое я нашел, было не заботится о Parse.User и использовать masterKey, чтобы сохранить все на сервере, но это сделает сервер ответственным за ACL.

Есть ли способ сделать запрос от другого пользователя, кроме thoses two?

ответ

1

Любой запрос к серверу (query.find(), object.save() и т. Д.) Принимает в качестве последнего аргумента необязательный параметр options. Это позволяет вам указывать дополнительные уровни разрешений, такие как принудительный мастер-ключ или использование определенного токена сеанса.

Если у вас есть токен сеанса, код сервера может сделать запрос от имени этого пользователя, сохраняя разрешения ACL.

Предположим, у вас есть таблица из Item объектов, где мы полагаемся на списки ACL, чтобы пользователь мог только получить свои собственные Элементы. Следующий код будет использовать явный маркер сеанса и возвращать только товары пользователь может видеть:

// fetch items visible to the user associate with `token` 
fetchItems(token) { 
    new Parse.Query('Item') 
    .find({ sessionToken: token }) 
    .then((results) => { 
     // do something with the items 
    }); 
} 

become() был действительно разработан для окружающей среды Анализировать Облако кода, где каждый запрос живет в песочнице, и вы можете рассчитывать на глобальный текущий пользователь для каждого запроса. Это не имеет смысла в приложении Node.js, и мы, вероятно, будем его осуждать.

0

Недавно я написал приложение NodeJS и имел ту же проблему. Я обнаружил, что комбинация Parse.User.disableUnsafeCurrentUser и Parse.User.become() была не только хакерской, но и вызвала несколько других проблем, которые я не мог предвидеть. Итак, вот что я сделал: я использовал Parse.Cloud.useMasterKey();, а затем загрузил текущего пользователя с помощью идентификатора сеанса, как если бы это был обычный пользовательский объект. Это выглядело примерно так:

module.exports = function(req, res, next) { 
    var Parse = req.app.locals.parse, query; 
    res.locals.parse = Parse; 
    if (req.session.userid === undefined) { 
    res.locals.user = undefined; 
    return next(); 
    } 
    Parse.Cloud.useMasterKey(); 
    query = new Parse.Query(Parse.User); 
    query.equalTo("objectId", req.session.userid); 
    query.first().then(function(result) { 
    res.locals.user = result; 
    return next(); 
    }, function(err) { 
    res.locals.user = undefined; 
    console.error("error recovering user " + req.session.userid); 
    return next(); 
    }); 

}; 

Этот код, очевидно, может быть оптимизирован, но вы можете увидеть общую идею. Потенциал: он работает! Даунсайд: больше не использовать Parse.User.current(), и необходимо проявлять особую заботу в бэкэнд, чтобы не возникало никаких условий, когда кто-то перезаписывает данные без разрешения.

+0

Итак, вы используете второе найденное мной решение. Я признателен, что кто-то подтвердил это, но если это вообще возможно, я предпочитаю не выполнять проверку разрешений на сервере. – DrakaSAN

+0

Упс - Я как бы пропустил этот абзац в вашем вопросе о втором решении. Сожалею!Да, отсутствие принудительного исполнения ACL вызывает раздражение, это по сути означает, что вам нужно будет проверить для каждого пользователя явно, разрешено ли ему читать или писать. –

+0

Объяснение нисходящего потока было бы неплохо ... –

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