Nodejs NodeClub两次输入的密码没必要到服务器校验吧
Nodejs NodeClub两次输入的密码没必要到服务器校验吧
在服务器端进行两次输入的密码校验没必要吧,这个功能是防止用户不小心输错的,服务器有必要校验么,数据根本不需要传到服务器来。
代码:controllers/sign.js
if(pass != re_pass){
res.render('sign/signup', {error:'两次密码输入不一致。',name:name,email:email});
return;
}
帖子内容:
标题:
Nodejs NodeClub两次输入的密码有必要到服务器校验吗?
内容:
在用户注册或修改密码时,通常需要用户两次输入密码以确保输入的一致性。这种做法主要是为了防止用户不小心输错密码,而不是为了安全目的。那么,在客户端完成两次输入的密码校验后,是否还需要将这些数据发送到服务器进行校验呢?
从用户体验的角度来看,客户端校验可以提供即时反馈,避免不必要的网络请求。然而,从安全性角度来看,客户端校验并不能完全替代服务器端校验,因为客户端校验可以通过禁用JavaScript来绕过。
因此,尽管客户端校验是一个好的用户体验设计,但服务器端校验仍然是必要的。客户端校验可以作为第一道防线,而服务器端校验则确保了数据的安全性和一致性。
下面是一个简单的示例代码,展示了如何在客户端和服务器端分别进行密码一致性校验。
客户端(HTML + JavaScript):
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Password Confirmation</title>
<script>
function validateForm() {
const password = document.getElementById("password").value;
const confirmPassword = document.getElementById("confirmPassword").value;
if (password !== confirmPassword) {
alert("两次密码输入不一致。");
return false;
}
return true;
}
</script>
</head>
<body>
<form onsubmit="return validateForm()">
<label for="name">用户名:</label>
<input type="text" id="name" name="name"><br><br>
<label for="email">邮箱:</label>
<input type="email" id="email" name="email"><br><br>
<label for="password">密码:</label>
<input type="password" id="password" name="password"><br><br>
<label for="confirmPassword">确认密码:</label>
<input type="password" id="confirmPassword" name="confirmPassword"><br><br>
<button type="submit">提交</button>
</form>
</body>
</html>
服务器端(Node.js + Express):
const express = require('express');
const app = express();
app.use(express.urlencoded({ extended: true }));
app.post('/signup', (req, res) => {
const { password, confirmPassword } = req.body;
if (password !== confirmPassword) {
return res.status(400).json({ error: '两次密码输入不一致。' });
}
// 进行其他业务逻辑处理,例如保存用户信息到数据库等
res.send('注册成功!');
});
app.listen(3000, () => console.log('Server is running on port 3000'));
通过上述示例,可以看到客户端和服务器端都进行了密码一致性校验。客户端校验提供了即时反馈,而服务器端校验确保了数据的一致性和安全性。
说的也是
万一由于某某原因,客户端的校验没能运行,而且提交上来的两个密码都不一样,应该以哪个为准?
还是干脆不用输入两遍密码?
浏览器 JS 难道有这么容易出错, 不大信
客户端再健壮,服务端都必须验证的。
我也觉得不需要
不是所有数据都要校验,得考虑这个数据对你有没有用,服务器的资源是宝贵的,别什么都收
一般都是这么个流程吧,在提交时候验证,就算是禁掉了js,也可以直接提交到服务器进行验证
纯猜测:
- 确实没有必要
- nodeclub只是玩具项目吧,懒得在客户端js写。
没必要, 这种验证交给前段就行了, 服务器只保存第一个密码, 第二个验证的忽略
…客户端数据绝对不可信啊…这个概念真的木有么…
说客户端数据不可信,这个也没错。但是也要想想到底是什么东西不可信吧? 考虑如果有一个修改密码的api,是不是也要让客户端传两个相同的密码?
所以服务器端验证密码复杂度是有必要的,但是验证两个密码是不是相同,就没必要了。
均衡存在万物之间,既要寻求简洁高效,又要寻求安全可行,说到底如果今后的密码修改为其他类型的时候,有可能只输入一次,不过目前来说,2次还是比较妥妥的,而且很多用户已经接受了这样的习惯,如果有更新更友好更安全高效的密码产生,否则不要随意便便用户习惯。
不需要。。如果js都被禁用了,论坛的很多功能都不能正常使用了。何况这的人多少都是搞技术的,不应当考虑js被禁用的情形吧?
个人觉得确实不需要
这里是在讨论“是不是没必要到服务器
校验”
在Node.js应用中,两次输入密码的校验确实可以在客户端进行初步验证,以提升用户体验。但是,为了确保数据的安全性和完整性,服务器端的校验仍然是必要的。客户端的校验可能会被绕过(例如通过开发者工具),因此服务器端的校验可以作为最后一道防线。
下面是具体的实现方法:
客户端校验
可以在前端使用JavaScript进行基本的表单校验,这样可以减少不必要的服务器请求。例如,使用HTML5的<input>
元素的内置校验属性或JavaScript的addEventListener
来处理表单提交事件。
<form id="signupForm">
<label for="password">密码:</label>
<input type="password" id="password" name="password" required>
<label for="rePassword">确认密码:</label>
<input type="password" id="rePassword" name="rePassword" required>
<button type="submit">注册</button>
</form>
<script>
document.getElementById('signupForm').addEventListener('submit', function(event) {
const password = document.getElementById('password').value;
const rePassword = document.getElementById('rePassword').value;
if(password !== rePassword) {
alert("两次密码输入不一致。");
event.preventDefault();
}
});
</script>
服务器端校验
尽管客户端已经进行了校验,但仍然需要在服务器端再次校验以确保数据的一致性。以下是Node.js中使用Express框架的一个示例。
首先,安装Express:
npm install express body-parser
然后,在你的controllers/sign.js
文件中添加以下代码:
const express = require('express');
const bodyParser = require('body-parser');
const app = express();
app.use(bodyParser.urlencoded({ extended: false }));
app.post('/signup', (req, res) => {
const { password, re_password } = req.body;
if(password !== re_password) {
return res.status(400).json({ error: '两次密码输入不一致。' });
}
// 如果两次密码一致,则继续处理注册逻辑
// 这里只是简单地返回成功响应
res.json({ success: true });
});
app.listen(3000, () => console.log('Server running on port 3000'));
通过上述方法,我们既保证了用户体验,也确保了数据的安全性和一致性。