本文探讨如何在前端JavaScript中根据当前登录用户ID过滤并显示特定数据，例如只显示用户创建的职位列表。我们将提供具体的代码实现，并深入分析前端过滤存在的安全与性能隐患，最终强调后端数据过滤作为更专业、更安全的最佳实践。
1. 前端数据过滤需求与现有问题
在web应用开发中，常见需求之一是根据当前登录用户显示其专属数据。例如，一个职位发布平台可能需要用户只能看到自己发布的职位列表，而不是所有用户发布的职位。
在提供的代码示例中，通过 $.getJSON 从API获取了所有职位列表数据，然后使用 $.each 遍历这些数据，动态生成HTML表格行并添加到页面中。问题在于，这种方法默认会显示所有数据，而没有根据当前用户的身份进行筛选。
核心需求是：在将每个职位信息渲染到HTML表格之前，判断该职位的 createdByUserID 字段是否与当前登录用户的ID匹配。如果不匹配，则跳过该条数据的渲染。
2. 前端过滤的实现方法
为了实现这一目标，我们需要在 $.each 循环内部，tblRow 变量构建之前，加入一个条件判断。
实现步骤：
立即学习“前端免费学习笔记（深入）”；
获取当前登录用户ID：假设当前登录用户的ID可以通过特定的HTML元素获取，例如
。我们可以使用jQuery来获取这个ID。
var currentUserID = $('[data-ms-member="id"]').text(); // 从HTML元素中获取用户ID// 确保 currentUserID 是一个有效的字符串或数字，根据实际情况可能需要类型转换
插入过滤逻辑：在 $.each 循环内部，tblRow 变量声明之前，添加一个 if 语句来比较当前用户ID和数据项中的创建者ID。
$(function() { var records = []; // 获取当前登录用户ID var currentUserID = $('[data-ms-member="id"]').text(); $.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 }) { // 确保 currentUserID 和 f.createdByUserID 具有相同的类型进行比较 if (currentUserID && currentUserID != f.createdByUserID) { return true; // 跳过当前循环迭代，处理下一条数据 } var tblRow = "" + "" + "" + "" + "" + "" + "@@##@@" + "
" + "Posted: " + f.dateCreated + " | Status: " + f.status + "
" + "About this role:
" + "" + f.roleDescription + "
" + "About " + f.company + ":
" + "" + f.companyDescription + "
" + "
" + "Apply " + "
" + "" + "" + "" + "" + " " + " " $(tblRow).appendTo("#userdata tbody"); }); });});
代码解释：
var currentUserID = $(‘[data-ms-member=”id”]’).text();：这行代码通过jQuery选择器获取页面上 data-ms-member=”id” 属性的元素内容，作为当前登录用户的ID。请确保此ID在页面加载时是可用的。if (currentUserID && currentUserID != f.createdByUserID) { return true; }：这是核心的过滤逻辑。currentUserID 确保我们成功获取到了用户ID。currentUserID != f.createdByUserID：比较当前用户ID与数据记录中的 createdByUserID。return true;：在 $.each 循环中，return true; 的作用是跳过当前迭代，继续处理下一条数据，而不是停止整个循环。这样，不匹配当前用户ID的记录就不会被用来构建 tblRow。
3. 前端过滤的局限性与风险
尽管上述前端过滤方法能够实现功能，但在实际生产环境中，它存在严重的安全和性能问题，因此不推荐作为长期或核心解决方案。
3.1 安全风险
数据暴露： 前端过滤意味着所有数据（包括那些不应该向当前用户显示的数据）都已从服务器下载到用户的浏览器。恶意用户可以通过浏览器的开发者工具（如网络请求、JavaScript调试器）轻易地查看这些原始、未过滤的数据。这可能导致敏感信息泄露，即使前端没有渲染出来，数据也已经暴露在客户端。易于绕过： 客户端的过滤逻辑很容易被篡改或禁用。经验丰富的用户可以修改本地JavaScript代码或通过直接操作API请求来绕过前端的任何限制，从而访问到所有数据。
3.2 性能问题
不必要的数据传输： 即使最终只显示少数几条数据，前端也必须从服务器下载整个数据集。如果数据库中包含大量数据，这将导致巨大的网络传输开销，浪费带宽。客户端处理负担： 浏览器需要解析并遍历所有下载的数据，然后进行过滤。对于大型数据集，这会增加客户端的计算负担，可能导致页面加载缓慢、响应迟钝，影响用户体验。
4. 最佳实践：后端数据过滤
为了解决前端过滤带来的安全和性能问题，最佳实践是在后端（服务器端）进行数据过滤。
4.1 后端过滤原理
当用户请求数据时，后端服务器负责：
验证用户身份： 确认请求用户的合法性。获取用户ID： 从会话（Session）、令牌（Token）或其他安全机制中获取当前登录用户的ID。数据库查询过滤： 在向数据库发起查询时，直接在查询条件中加入用户ID的限制，例如 SELECT * FROM JobListings WHERE createdByUserID = :currentUserID。返回过滤后的数据： 仅将那些与当前用户ID匹配的数据从数据库中取出，并通过API接口返回给前端。
4.2 实现思路
修改API接口： 而不是请求 view=AllListings，可以设计一个API端点，例如 /api/user/joblistings，该端点在接收到请求时，会根据当前登录用户的身份自动过滤数据。传递用户ID（可选，但通常在后端处理）： 如果API需要明确的用户ID，可以在请求中携带（例如作为URL参数 ?createdByUserID=… 或请求头）。但更安全的方式是后端从用户会话中自动获取。
4.3 技术栈建议
使用后端语言和框架来实现数据过滤，例如：
Node.js (Express.js)PHP (Laravel, Symfony)Python (Django, Flask)Java (Spring Boot)Go (Gin, Echo)
这些后端技术提供了成熟的身份验证、授权和数据库交互机制，能够安全高效地处理数据过滤逻辑。
5. 总结
在前端根据用户ID过滤数据虽然可以快速实现功能，但它带来了严重的安全隐患（数据暴露、易被绕过）和性能问题（不必要的数据传输、客户端处理负担）。作为专业的开发实践，我们强烈建议将数据过滤逻辑放在后端服务器实现。后端过滤能够确保只有授权的数据才会被传输到客户端，从而保障数据安全，并优化应用性能。
以上就是实现前端数据按用户ID过滤：方法、局限与最佳实践的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1576179.html
微信扫一扫 
支付宝扫一扫 
