2016-10-07 5 views
4

Я использую feathers.js и пытаюсь ограничить доступ к странице оплаты-info.html пользователям, которые авторизованы.Перья Js Ограничение доступа к странице на стороне сервера

const app = feathers(); 

app.configure(configuration(path.join(__dirname, '..'))); 

app.use(compress()) 
    .options('*', cors()) 
    .use(cors()) 
    .use(favicon(path.join(app.get('public'), 'favicon.ico'))) 

    .use('/payment-info.html', function(req,res,next){ 
    if(req.isAuthenticated()){ 
    next(); 
    } else { 
    // 401 Not Authorized 
    next(new Error(401)); 
    } 
    }) 

    .use('/', serveStatic(app.get('public'))) 
    .use(bodyParser.json()) 
    .use(bodyParser.urlencoded({ extended: true })) 
    .configure(hooks()) 
    .configure(rest()) 
    .configure(socketio()) 
    .configure(services) 
    .configure(middleware); 

module.exports = app; 

Однако REQ .isAuthenticated() возвращает false, даже если пользователь вошел в систему. Есть ли способ ограничить доступ к странице в общедоступном каталоге только пользователям, которые вошли в систему?

ответ

5

Чтобы сделать ограничение в сценарии загрузки страницы, вам нужно сначала убедиться, что токен находится в файле cookie. Ознакомьтесь с feathers-authenticationdocumentation о том, как включить cookies. Но очень важно, чтобы вы старались не подвергать себя атакам CSRF через файл cookie.

С текущей версией плагина аутентификации перьев вам придется установить это вручную. Вам нужно прочитать маркер из печенья для рендеринга промежуточного использования:

const jwt = require('jsonwebtoken'); 
 
const cookieParser = require('cookie-parser'); 
 

 
app.use(cookieParser()); 
 
app.use('/payment-info.html', function(req, res, next) { 
 
    let token = req.cookies['feathers-jwt']; 
 
    if (token) { 
 
    // Get the JWT secret to verify the token. 
 
    let secret = app.get('auth').token.secret; 
 
    jwt.verify(token, secret, function(err, decoded) { 
 
     if (err) { 
 
     return res.status(401).send('You are not authorized to view that page.'); 
 
     } 
 
     return next(); 
 
    }); 
 
    } else { 
 
    return res.status(401).send('You are not authorized to view that page.'); 
 
    } 
 
});

Очень важно, чтобы вы никогда не позволять какие-либо услуги непосредственно использовать маркер из печенья. Хорошо, если промежуточное ПО рендеринга вытащить токен и использовать его для выполнения запросов службы, как если бы это был просто другой клиент, но вы никогда не захотите вытащить его из файла cookie и разместить его на объекте req.feathers для авторизации внутри службы. Вот как вы открываете свой API до атак CSRF.

Кроме того, если вы включили CORS, вы, скорее всего, захотите убедиться, что CORS отключены для промежуточного ПО рендеринга. Только включите CORS непосредственно перед вашими перьями.

Другим недостатком [email protected] является то, что срок действия файла cookie не совпадает с истечением срока действия токена. Вам нужно будет вручную установить окончательный вариант maxAge файла cookie, чтобы он соответствовал тому, как долго вы хотите, чтобы ваши токены были действительными, как описано в документах.

[email protected] (который в настоящее время находится в предварительном выпуске), будет содержать лучшую поддержку для рендеринга на стороне сервера, поэтому вам не придется подключать его самостоятельно. Он также позаботится о том, чтобы срок действия файла cookie истекал с помощью токена.