根据用户ID过滤显示数据库记录的前端实现与安全考量

本文探讨了如何在前端JavaScript中根据当前登录用户的ID过滤并显示数据库记录，以实现个性化的数据展示。通过在数据遍历时添加条件判断，可以仅渲染与用户ID匹配的条目。然而，文章也着重强调了前端过滤存在的严重安全漏洞和性能问题，并强烈建议采用后端服务进行数据过滤，以确保数据安全性和系统效率。

前言

在现代web应用中，经常需要根据用户的身份来展示个性化的数据。例如，一个招聘网站可能只允许用户查看自己发布的职位列表。本文将介绍一种在前端javascript中实现这一功能的方法，并深入探讨其潜在的安全风险和性能问题，最终推荐更健壮的后端解决方案。

前端实现：根据用户ID过滤数据

假设我们有一个HTML表格，用于展示从数据库获取的职位列表。初始代码通过AJAX请求获取所有职位数据，并遍历这些数据来构建表格行。我们的目标是只显示那些 createdByUserID 字段与当前登录用户ID匹配的职位。

获取当前用户ID

在前端，通常可以通过某种方式获取当前登录用户的ID。例如，一个常见的模式是将用户ID嵌入到页面元素的数据属性中，或者通过JavaScript全局变量提供。在示例中，假定用户ID可以通过

这样的方式获取，或者在JavaScript中预先设置。

// 假设这是获取当前登录用户ID的方式// 实际应用中，你需要根据你的认证系统来获取这个值var currentUserID = /* 从HTML元素、全局变量或API获取当前用户ID */;// 例如，如果用户ID在某个div的data属性中// var currentUserID = $('[data-ms-member="id"]').text();

整合过滤逻辑

原始代码通过 $.getJSON 获取数据后，使用 $.each 遍历 data.records。我们可以在构建表格行之前，添加一个条件判断来过滤不属于当前用户的数据。

$(function() {    // 假设这是获取当前登录用户ID的方式    // 实际应用中，你需要根据你的认证系统来获取这个值    // 例如，如果用户ID在某个div的data属性中    var currentUserID = $('[data-ms-member="id"]').text(); // 获取当前登录用户的ID    $.getJSON('https://db-ommitted-for-privacy?tableName=JobListings&fields=company,logo,img,companyDescription,role,roleDescription,location,link,createdByUserID,dateAdded&view=AllListings', function(data) {        $.each(data.records, function parseJSON(i, { fields: f }) {            // 在这里添加过滤逻辑            // 如果职位的创建者ID与当前用户ID不匹配，则跳过当前记录            if (currentUserID != f.createdByUserID) {                return true; // 使用 return true; 相当于 continue，跳过当前循环迭代            }            // 只有当条件匹配时，才执行以下代码来构建并添加表格行            var tblRow = "" +                "" +                    "" +                        "" +                            "" +                            "" +                                "@@##@@" +                                "
" +                                "Posted: " + f.dateCreated + "   |   Status: " + f.status + "
" +                                "About this role:
" +                                "" + f.roleDescription + "
立即学习“前端免费学习笔记（深入）”；
" +                                "About " + f.company + ":
" +                                "" + f.companyDescription + "
" + "
" +                                "Apply   " +                                "
" + "
" +                            "
" +                        "
" +                    "

" + "" + ""; $(tblRow).appendTo("#userdata tbody"); }); });});

在 $.each 循环内部，我们通过 if (currentUserID != f.createdByUserID) { return true; } 语句实现了过滤。如果当前记录的 createdByUserID 与 currentUserID 不匹配，return true; 将会跳过当前迭代，继续处理下一条记录，从而确保只有匹配的记录才会被渲染到页面上。

重要的安全与性能考量

尽管上述前端过滤方法可以实现功能，但在实际生产环境中，强烈不推荐采用这种方式处理敏感数据。这主要基于以下两个关键原因：

1. 安全风险：数据泄露

前端过滤的根本问题在于，它需要从服务器获取所有数据，然后才在客户端进行筛选。这意味着即使在页面上只显示了用户自己的数据，但通过浏览器的开发者工具（如网络请求监控），任何用户都可以看到从数据库中获取的全部原始数据，包括不属于他们的数据。

例如，如果一个恶意用户查看网络请求，他们可以看到包含所有用户创建的职位列表的JSON响应。这会暴露敏感信息，并可能被滥用，造成严重的数据泄露风险。

2. 性能问题：不必要的带宽与处理

当数据库中的记录数量很少时，前端过滤可能不会造成明显的性能问题。但随着数据量的增长，每次加载页面都需要：

从服务器传输大量不必要的数据到客户端（消耗带宽）。客户端浏览器需要解析和处理所有这些数据，即使其中大部分数据最终会被过滤掉（消耗客户端CPU和内存）。

这会导致页面加载速度变慢，用户体验下降，尤其是在移动设备或网络条件不佳的环境下。

推荐方案：后端服务过滤

为了解决上述安全和性能问题，最佳实践是在后端服务（如使用PHP、Node.js、Python、Java等）进行数据过滤。

工作原理：

前端请求： 当用户登录并请求查看自己的数据时，前端会向后端发送一个请求，并在请求中包含当前用户的ID（通常通过会话、JWT或其他认证机制在服务器端自动识别，或作为请求参数发送）。后端处理： 后端服务接收到请求后，会利用这个用户ID作为查询条件，直接从数据库中检索只属于该用户的数据。后端响应： 后端只将过滤后的、与当前用户相关的数据发送回前端。

优点：

安全性高： 敏感数据永远不会离开后端，只有经过授权和过滤的数据才会发送到客户端。恶意用户无法通过前端工具获取未经授权的数据。性能更优： 减少了网络传输的数据量，前端也无需处理大量无关数据，显著提升了页面加载速度和应用响应性。职责分离： 数据访问和过滤逻辑集中在后端，更易于管理、维护和扩展。

总结

尽管前端过滤提供了一种快速实现特定功能的方式，但其固有的安全漏洞和性能限制使其不适用于处理敏感或大量数据。在构建生产级别的Web应用时，始终应优先考虑在后端服务进行数据过滤，以确保数据安全、系统高效和用户体验良好。