2015-10-29 5 views
4

Я создаю приложение флеш-карты со средним стеком и пытаюсь имитировать процесс, указанный в этом уроке https://thinkster.io/mean-stack-tutorial#wiring-everything-up.Сколько информации должно быть указано в полезной нагрузке JWT?

При регистрации нового пользователя Я хочу, чтобы возвратить информацию этого пользователя в объекте пользователя: текущая и последняя колода карточек изучается текущая и последняя карта изучается и т.д.

Мой вопрос сколько этой информации должно войти в полезную нагрузку JWT?

В учебнике thinkster.io полезная информация JWT содержит только имя_пользователя, имя пользователя и дату истечения срока действия. Я беспокоюсь, если дополнительная информация не должна входить в JWT, потому что это сделает JWT слишком большим. Затем я просто отправлю JWT обратно вместе с пользовательским объектом, который возвращается после сохранения пользователя с помощью метода mongoose.save? Эта стратегия звучит, как он соответствует следующей цитате из:

https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/#token-size

Каждый раз, когда вы делаете запрос API, вы должны послать маркер в заголовке авторизации.

В зависимости от того, сколько информации вы храните в этом токене, оно может получить большой размер. С другой стороны, файлы cookie сеанса обычно представляют собой только идентификатор (connect.sid, PHPSESSID и т. Д.), А остальная часть контента живет на сервере (в памяти, если у вас только один сервер или база данных , если вы запускаете на ферме серверов).

Теперь ничто не мешает вам реализовать аналогичный механизм с токенами . У токена была бы необходимая базовая информация, а на стороне сервера вы могли бы обогатить ее большим количеством данных при каждом вызове API. Это - это точно то же самое, что и куки, с той разницей, что у вас есть дополнительное преимущество, которое теперь является сознательным решением, у вас есть полный контроль и является частью вашего кода.

/зарегистрировать маршрут код, который я пытаюсь имитировать от thinkster.io является следующее:

router.post('/register', function(req, res, next){ 
    if(!req.body.username || !req.body.password){ 
    return res.status(400).json({message: 'Please fill out all fields'}); 
    } 

    var user = new User(); 

    user.username = req.body.username; 

    user.setPassword(req.body.password) 

    user.save(function (err){ 
    if(err){ return next(err); } 

    return res.json({token: user.generateJWT()}) 
    }); 
}); 

Могу ли я просто отредактировать сохранить метод часть в нижней части, чтобы выглядеть следующим образом:

user.save(function (err, user){ 
    if(err){ return next(err); } 

    return res.json({token: user.generateJWT(), 
        user: user}) 
    }); 

Или должна ли быть добавлена ​​дополнительная информация пользователя в JWT, и только JWT будет передан обратно?

+0

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

ответ

1

Вам необходимо использовать в соответствии с вашими требованиями безопасности.

Для моих приложений, например, я следую вашему примеру. Токен хранится в файле cookie клиента, и в рамках проверки подлинности я делаю одно:

  • Декодирование JWT и заполнение request.user с помощью _id и другого первичного ключа.
  • Отправьте обратно токен и информацию о пользователе.

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

Вам не нужно смешивать много мусора в вашем JWT. Его еще нужно декодировать.

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