Drobne zmiany:
Te ważniejsze:
obecnie zwracamy refresh_token wraz z access_token w jednym JSON w /auth/login. jest to spoko, ale żeby front mógł z tego skorzystać to musi ten refresh_token gdzieś zapisać w przeglądarce. najlpewniej byłby to localstorage ale że on jest podatny na XSS to po naszej stronie zamienimy żeby refresh_token był jako cookie i nie dostępny dla JS w przeglądarce
res.cookie('refresh_token', refresh_token, {
httpOnly: true,
secure: configService.getOrThrow<string>('NODE_ENV') === 'production',
sameSite: 'strict',
maxAge: configService.getOrThrow<number>('REFRESH_TOKEN_TTL_DAYS') * 24 * 60 * 60 * 1000,
domain: configService.getOrThrow<string>('APP_DOMAIN'),
path: '/api/v3/auth',
});
Drobne zmiany:
ResetPasswordDtododać@IsNotEmptynad polem token, żebby pusty string nie przechodził walidacjiTe ważniejsze:
obecnie zwracamy
refresh_tokenwraz zaccess_tokenw jednym JSON w/auth/login. jest to spoko, ale żeby front mógł z tego skorzystać to musi ten refresh_token gdzieś zapisać w przeglądarce. najlpewniej byłby to localstorage ale że on jest podatny na XSS to po naszej stronie zamienimy żeby refresh_token był jako cookie i nie dostępny dla JS w przeglądarcemain.tsdodaćapp.use(cookieParser());żęby api widziało te cookies.env.exampleoraz do walidacji Joi wapp.module.ts- REFRESH_TOKEN_TTL_DAYSlogin()w kontrolerze trzeba ustawić żeby nie zwracał json z refresh_token, tylko ustawiał go do cookie, a access_token zwracał jak dotychczasPOST /auth/logoutktóry usuwa refresh token z bazy oraz usuwa cookie z refresh_token