如何看待前端在用户登录使用 url 地址传参的行为

没看懂，不是 post 吗？

@shintendo 嗯 post 拼接请求地址是 ?username=test&pwd=123 这样的提交的

一般 nginx 等服务器日志里会写 url， 所以密码这样敏感的信息不该放 url 里。

其实无所谓的啊,无非是更加容易被攻击而已

我想了想，如果是 XHR、fetch、Ajax 提交，拼在 URL 上还是在 body 里好像没啥区别，只是不能太长。但是拼接过程中要记得做 URL encode 吧。

@jugelizi 那他 post body 里面放什么? 就算有 https, server log/browser history 里面都会有记录

以为来到知乎了。。。
API 谁定的呢？
感觉流程一般都是：后端提供 API 文档，简单评审，前端根据这个 mock，最后联调

@shanigan 空的啊
数据在 url 里已经全有了
之前 form 时代会在浏览器历史记录里所以有密码泄露风险
现在呢

遇到这种网站能不能用就不用…

找个明白人定一下 API 规则

正不正常：不正常
能不能用：能用
推荐不推荐：不推荐
有什么好的建议：定下前后端数据对接的规则。

密码加时间戳盐做哈希再传，不然你放 url 还是 post body 都不安全

先请求一个公钥，客户端用这个公钥给用户数据编码，然后随便什么 get post 请求把数据发给服务端都可以了。
只要没加密，放在 request body 和 request header 和 url 都是不安全的

@zqx 那要 HTTPS 干嘛

URL 传参会被日志和 CDN 记录，容易泄漏。后端的一些框架直接读 request[param] 是不区分 get/post 的，这部分得谨慎处理。

@Mutoo 这里的泄漏不一定是对外泄漏，也有可能是对内泄漏。之差推特就犯过这类错误。

@hyperbin HTTPS 只能保证传输过程中(端到端)的加密吧？到了目标客户端以后，比如企业级的访问网关还是会记录请求信息，再经过各种服务过滤和转发，最后到达业务服务器，这时候数据已经泄露给内部其他系统很多次了

URL 携带账号密码，并且 post 提交的话，是可以在后台接收到数据的。
但是，前台把账号密码放到 URL 传递是不对的做法，是不是他前端代码有问题？排查下就好了。

能用，但不推荐。
这样传参的数据格式应该是 application/x-www-form-urlencoded。
前后端分离在接口交互中，数据格式应该有通用性，一般约定用 application/json 比较好，formData 感觉都用得不多。

很不妥

GET 的参数日志会记录，日志无法脱敏。

前后分离所有 post 不应该都用 post json 的方式吗？怎么还走 post 表单那套

所以想说明的是后端的 API 根本是 POST 和 GET 都能用的么....

@zqx 客户端都不可信了，你上什么都没用

post 和 get (url 挂参) 方式 本质是一样的,只不过一个要工具看,一个直接看请求地址,正确的做法是前端加密,

这明显不妥，不说什么加密至少你最基础的 post json 方式提交得弄撒。