Доступ к защищенному маршруту

Question

Я только начал использовать JWT . Я делаю логин и отправляю токен в виде JSON-ответа клиенту . При успешном входе в систему я сохраняю это в sessionStorage и затем использую этот токен для доступа к защищенному маршруту через заголовки другого ajax-вызова (GET) , который в случае успеха перенаправит на эту страницу.

Я начал с защиты напрямую маршрута Я также перенаправил , и у меня было нет / verify-user route , но с перенаправление заголовки не отправлено Я нашел это решение только для проверки маркер. Однако я не знаю, если это хороший способ.

Что вы думаете?

Мой логин на клиенте :

   // Login POST 
    $('#frm-login').submit(function (e) {
        event.preventDefault()
        $('button').text('Please wait ...').prop('disabled')
        $.ajax({
            url: "/login-user",
            type: "POST",
            data: $('#frm-login').serialize(),
            dataType: "json"
        }).always(function (response) {
            $('button').text('Logging in').prop('disabled')
            console.log("Login", response)
            if (response.status == "error") {
                $('button').removeClass('lime').addClass('red').text('Log in failed. Try again.');
                return
            }
            localStorage.setItem('token', response.token);
            console.log(localStorage.token)
            $.ajax({
                type: "GET",
                url: "/verify-user",
                headers: {
                    'Authorization': 'Bearer ' + localStorage.token
                }
            }).always(function (response) {
                console.log("Access", response)
                if (response.status == "error") {
                    $('button').removeClass('lime').addClass('red').text('Log in failed. Try again.');
                    return
                }
                if (response.status == 301) {
                    $(location).attr('pathname', '/LIMELine/chatroom/');
                    //$('img#profile-img').attr('src', response.responseText.authData.user.avatar)
                    console.log(response)
                }
            });
        })
    })

Мой логин на сервере :

/********************* LOGIN *********************/

app.post('/login-user', (req, res) => {
    user.loginUser(req.body, (err, jResult) => {
        if (err) {
            return res.send(jResult)
        }
        let token = jwt.sign({
            user: jResult,
        }, "supersecret")
        console.log(token);
        return res.json({
            token: token
        })
        //add other headers here...
    })
})

/********************* VERIFY USER *********************/

app.get('/verify-user', verifyToken, (req, res) => {

    jwt.verify(req.token, "supersecret", (err, authData) => {
        if (err) {
            return res.status(403).json({
                message: "No token found"
            });
        }
        return res.status(301).json({
            authData
        });
    })
})

защищенный маршрут , который должен видеть пользователь при входе в систему

// *********************   MAIN PAGE *********************************************

app.get('/LimeLINE/chatroom' (req, res) => {
            try {
            // CODE FOR CONTENT OF THE PAGE
            return res.json({
                authData
            });
        }
    })
})

Answer 1

Если вы выполняете перенаправление на всю страницу (не через ajax, а автоматически через браузер, например, при щелчке по тегу привязки без привязки), браузер не будет автоматически отправлять HTTP-заголовок Authorization.

Вы можете либо начать отправку токена JWT с помощью файла cookie (который является менее стандартным и привязывает клиента к тому, чтобы быть браузером, но это произойдет автоматически на всех вызовах на полную страницу и вызовы AJAX), либо обрабатывать перенаправление самостоятельно через ajax.вызов.Другое «гибридное» решение состояло бы в том, чтобы включить как Authorization заголовок, так и cookie в качестве допустимых методов авторизации.

IMO все зависит от того, должен ли ваш сервер принимать не браузерный клиент в настоящее время или в ближайшем будущем.