Jsonwebtoken: что такое полезная нагрузка
я хочу использовать веб-токены json для проверки пользователя, и я собираюсь использовать метод jwt.sign, но термин «полезная нагрузка» смутил меня в соответствии с определением полезной нагрузки википедии (в вычислениях):
In computing and telecommunications, the payload is the part of transmitted data that is the actual intended message. Headers and metadata are sent only to enable payload delivery.[1][2]
но согласно среднему коду
const jwt = require('jsonwebtoken');
app.post('/api/authenticate', function(req, res) {
const { email, password } = req.body;
User.findOne({ email }, function(err, user) {
if (err) {
console.error(err);
res.status(500)
.json({
error: 'Internal error please try again'
});
} else if (!user) {
res.status(401)
.json({
error: 'Incorrect email or password'
});
} else {
user.isCorrectPassword(password, function(err, same) {
if (err) {
res.status(500)
.json({
error: 'Internal error please try again'
});
} else if (!same) {
res.status(401)
.json({
error: 'Incorrect email or password'
});
} else {
// Issue token
const payload = { email };
const token = jwt.sign(payload, secret, {
expiresIn: '1h'
});
res.cookie('token', token, { httpOnly: true })
.sendStatus(200);
}
});
}
});
});
полезная нагрузка - это электронная почта, предоставленная пользователем для аутентификации, что меня смутило, я буду рад, если кто-нибудь объяснит, что такое полезная нагрузка и какова роль полезной нагрузки в jwt.sign()
Ответы 1
В веб-токенах JSON полезная нагрузка представляет собой набор полей, которые вы хотите включить в создаваемый токен; Вещи, которые понадобятся вашему API, например, для получения правильных данных для конкретного пользователя.
Это всего лишь простой объект JSON, который обычно используется для включения идентификационных данных пользователя, таких как идентификатор пользователя, идентификатор учетной записи или адрес электронной почты. Однако он также может содержать любые произвольные данные, которые могут вам понадобиться, такие как полное имя пользователя, языковые настройки и т. д.
Пример полезной нагрузки может выглядеть следующим образом, если предположить, что это поля, от которых зависит ваш API для получения сведений о пользователе/учетной записи, которым принадлежит токен. Обратите внимание, что это будет считаться довольно большой полезной нагрузкой; Большинство полезных нагрузок имеют только одно поле идентификатора пользователя, поскольку обычно это все, что нужно конечной точке для правильной идентификации пользователя.
{
user_id: 303,
account_id: 909,
email: '[email protected]',
full_name: 'Joe Blow',
default_language: 'en_US'
}
ПРЕДУПРЕЖДЕНИЕ: Полезная нагрузка зашифрована НЕТ, поэтому убедитесь, что вы не храните в ней такие вещи, как пароли, секретные ключи, номера кредитных карт, остатки на банковских счетах и т. д. Должны сохраняться только идентификаторы, такие как идентификаторы, которые вы видите в URL-адресе, или открытые ключи.
Кроме того, полезная нагрузка влияет на общую длину токена (больше данных означает более длинные токены), поэтому вам нужно включать только самые важные части данных. В противном случае вы будете отправлять очень большой токен при каждом запросе, который потребляет полосу пропускания и, теоретически, требует больше ресурсов сервера для декодирования.
Наконец, JWT не имеют состояния, то есть они не являются сеансами. Поэтому не включайте данные, которые часто меняются, такие как счет в игре, последний вход и т. д.
@Джейк, это может быть все, что ты захочешь. Посмотрите мой пример, который я добавил с пользователем full_name.
я должен включить этот вид данных?
@ Джейк снова, я ответил на это в ответе. Вы должны включить минимум информации, необходимой для правильной идентификации пользователя в вашем API, не более того. Большинство JWT включают идентификатор пользователя и все.
ах. понял, я использую уникальные имена пользователей, так что этого будет достаточно, я думаю
@Jake, если имя пользователя может быть изменено пользователем, то это плохой идентификатор.
как насчет user._id?
не будет ли это уязвимостью? или я должен объявить другое поле (в db (mongo)) как id с автоматической реализацией и использовать это
@Jake Как я уже сказал в своем ответе, идентификатор пользователя (в вашем случае идентификатор пользовательского документа) можно хранить в JWT. Это не уязвимость, точно так же, как знание имени пользователя не является уязвимостью; Они общедоступны. Уязвимость существует только в том случае, если у злоумышленника есть личная идентификационная информация, такая как пароль или закрытый ключ.
это должен быть идентификатор пользователя или это может быть что угодно, например случайная строка?