Node.js+Express 401状态中间件失效及替代方案疑问

问题描述 #

我使用NodeJS v18.16.1和Express v4.18.2搭建服务，配置了一个中间件，期望在返回401状态时自动重定向至登录页，并将错误信息放入查询参数。中间件代码如下：

const redirectUnauthorized = (request, response, next) => {
    if (response.statusCode === 401) {
        const errorMessage = request.body;
        let url = '/login';
        if (errorMessage) {
            url += `?error=${request.body}`;
        }
        return response.redirect(url)
    } else {
        next();
    }
};
app.use(redirectUnauthorized);

const controllerAuth = require(path.join(__dirname, 'api', 'auth.js'))
app.post('/api/auth/login', controllerAuth.login);

登录接口逻辑位于/api/auth.js：

const login = (request, response) => {
    if (request.method !== 'POST') {
        return response.status(405).send('Method not allowed');
    }

    const formData = request.body;
    if (!formData) {
        return response.status(400).send('No body was sent');
    }
    formData.ReturnUrl = formData.ReturnUrl || 'users'

    if (formData.Username === 'admin' && formData.Password === 'admin') {
        return response.redirect(`./${formData.ReturnUrl}`);
    } else {
        return response.status(401).send('Invalid username and/or password.');
    }
};

实际测试时，登录验证失败返回401状态后，并未触发中间件的重定向，仅返回错误文本。后来我改为返回带跳转脚本的HTML，虽然实现了跳转，但感觉这种方式不太合理：

if (formData.Username === 'admin' && formData.Password === 'admin') {
    return response.redirect(`/${formData.ReturnUrl}`);
}
return response.status(401).send('<script>window.location.href = "/login?error=Invalid username and/or password"</script>');

想确认这是否为正确的实现方案？

原因分析 #

1. 中间件执行时机错误：你将redirectUnauthorized挂载在路由之前，但路由处理函数中调用response.status(401).send()时，已直接发送完整响应（包括响应头和响应体），后续中间件无法再修改响应内容，自然无法触发重定向。
2. 请求体拼接错误：即便中间件能生效，request.body是对象类型，直接拼入URL查询参数会变成[object Object]，无法传递正确的错误信息。
3. 脚本跳转的弊端：这种方式绕过了HTTP状态码的语义，若登录接口被AJAX请求调用，前端会收到HTML脚本而非预期的JSON错误信息，导致逻辑混乱，不符合REST接口设计规范。

正确实现方案 #

方案一：使用错误处理中间件（推荐，适合多接口场景） #

Express提供了专门的4参数错误处理中间件，可统一捕获并处理错误：

首先修改登录路由，抛出带状态码的错误对象：

const login = (request, response, next) => {
    if (request.method !== 'POST') {
        const err = new Error('Method not allowed');
        err.statusCode = 405;
        return next(err);
    }

    const formData = request.body;
    if (!formData) {
        const err = new Error('No body was sent');
        err.statusCode = 400;
        return next(err);
    }
    formData.ReturnUrl = formData.ReturnUrl || 'users'

    if (formData.Username === 'admin' && formData.Password === 'admin') {
        return response.redirect(`/${formData.ReturnUrl}`);
    } else {
        const err = new Error('Invalid username and/or password.');
        err.statusCode = 401;
        return next(err);
    }
};

然后在所有路由之后添加错误处理中间件：

app.use((err, req, res, next) => {
    const statusCode = err.statusCode || 500;
    const errorMessage = encodeURIComponent(err.message); // 编码特殊字符避免URL解析问题

    if (statusCode === 401) {
        return res.redirect(`/login?error=${errorMessage}`);
    }

    // 其他状态码的通用处理
    res.status(statusCode).send(err.message);
});

方案二：路由内直接处理重定向（适合单一页面表单场景） #

若该登录接口仅用于页面表单提交，无需支持AJAX请求，可直接在验证失败时返回重定向：

const login = (request, response) => {
    // ... 保留前面的校验逻辑

    if (formData.Username === 'admin' && formData.Password === 'admin') {
        return response.redirect(`/${formData.ReturnUrl}`);
    } else {
        const errorMessage = encodeURIComponent('Invalid username and/or password.');
        return res.redirect(`/login?error=${errorMessage}`);
    }
};

这种方式更直接，无需额外中间件，但多接口需要处理401时，可维护性不如方案一。

方案三：区分页面请求与API请求 #

若服务同时支持页面渲染和API接口，建议通过请求头判断请求类型，分别处理：

const login = (request, response) => {
    // ... 保留前面的校验逻辑

    if (formData.Username === 'admin' && formData.Password === 'admin') {
        return response.redirect(`/${formData.ReturnUrl}`);
    } else {
        const errorMessage = 'Invalid username and/or password.';
        // 判断是否为页面请求
        if (req.accepts('html')) {
            const encodedMsg = encodeURIComponent(errorMessage);
            return res.redirect(`/login?error=${encodedMsg}`);
        }
        // API请求返回JSON错误信息，由前端自行处理跳转
        return res.status(401).json({ error: errorMessage });
    }
};

总结 #

你之前采用的脚本跳转方式并非合理的实现方案，推荐使用错误处理中间件或直接重定向的方式，既符合HTTP规范，也能保证代码的可维护性和兼容性。

内容的提问来源于stack exchange，提问作者David