@Buges 我承认你说的这个问题，但我个人还是认为 https 不太容易被攻击，前端 hash 的缺点高于优点。
同时我说了我觉得前端要做可以做非对称加密

我今天用招行 app 的时候发现招行可以直接 nfc 读取身份证信息，在苹果手机上现在原来可以 nfc 了

当然 @GuuJiang 也理解错了一点他们的说法， 他们的说法是说 前端后端各做自己的哈希。
数据库存储的密码在他们的设计里是 后端:hash( 前端:hash(用户输入+前端固定 salt) + 每个用户个人 salt)。

这在后端眼里只是对于本站而言，等于脱了裤子放屁，用户密码由 123 变成了 a2cf ，但攻击者拿到的就是 a2cf ，拿到就能登录，对后端完全没区别。

@dingwen07
@g531956119
@Buges

我赞同 @GuuJiang 的观点，前端不要闲得没事自己做哈希，你们是准备把弱密码库之类的也写个 js 库自己前端做校验吗？然后弱密码策略也前端自己维护一份？比如什么密码包含生日包含连续数字包含账户名这种？

当然如果做加密我不反对，尤其是用非对称的，前端 js 里固定公钥就行，后端可以在注册和登录的时候照常反解回来，然后各种安全服务可以照常调用，弱密码相似密码也都不用前端处理，就是后端高并发的性能会差一些。

而且 https 被监听的问题我觉得不会如后端被脱裤那样容易引起大范围反应，https 要被攻击者解密我只知道让用户手动信任中间人的证书这一种情况。
除此之外我只听说过只有之前沃通还是那个 CA 的 bug 会给人发 gitpage.io 的根域名证书，然后这个 CA 就被浏览器火速拉黑了。

@dingwen07
@g531956119
@Buges
你们说的东西和人家 @GuuJiang 说的是两个概念。
人家说的是 即便监听者拿到的是前端哈希后的值，那在当前网站依然被黑了，对于本站和明文传递没区别。A 网站的用户在 A 网站的密码还是暴露了，攻击者可以随意登录。

而你们在说攻击者拦截了流量会危害到使用相同账号密码的其他网站，A 网站用户泄露的密码会导致 BC 网站同样被可以攻击者登录。

我赞同你们说的存在的问题，但这个问题和人家提的点关联性不大，即便按你们说的加 hash 了，那人家提的 A 网站被攻破了的问题你们并没有扛住了，那为什么说的好像人家说错了一样。

而且强 native -> 而是强 native

看到最后一条楼主的附言我说一句，不是楼主走偏了，而且强 native 功能依赖的如今属于小众需求了。
而互联网范围内 app 的功能大多只需要替代网页访问就好。使用不到太多的 native 功能。包括外国的 fb 、twitter 、也一样，大多数 app 都是内容展示类的，他们需要的 native 功能主要就是摄像头和定位。

比如我曾经接触的一个组，他们是给学校卖物联网教学方案的，定制开发板镶嵌一个屏，装了安卓系统，但应用实际全是 c++写的。界面都是 qt 。因为他们天天搞的熟悉的就是那些，并且还会有一些红外烟感光感之类的非手机硬件设备需要写代码调用。

@x66 见过 es - elasticsearch #滑稽

https 是传输数据全加密的，除了请求的目标 IP ，中间设备是抓不到任何内容的，path 部分 body 体都一样，除非请求发起端被黑了，信任了中间人的证书，然后被中间人劫持。
（题外话，所以不要在公司的加域电脑或者需要安装上网控制的内网上干私人的事，对于 IT 和老板你 https 了也是光屁股的）

这个后端找借口都不会 ， 我教他俩百分百对的。
"Restful 对于某些业务很难抽象，比如网上各种对注册登录的实现，要么破坏规则与其他 restful 不统一，要么强行把简单的逻辑抽象成了复杂还别扭的规则。"

"公司运维有统一请求分析控流组件，每个项目都是统一接入的，而这个组件不支持 url 里的携带变量，要求运维发开升级组件难度很大，影响范围很大并且升级后稳定性无法评估。（或者 这是采购的第三方产品，且除软件外还包含专用防火墙硬件设备，厂家无法支持升级，需要购买新设备替换）"。

就是一个标准统一就好，我个人更喜欢驼峰。
虽然阿里巴巴的标准是全大写，并且目前我们项目领导也要求这样，我也遵守了这样的规范。

DTO 和 HTTP 、URL 、SQL 、NBA 、NASA 、API 、GUI 、REST 一样都是一类专有名词缩写，针对于驼峰命名法而言，我的理解是按照驼峰结构修改，和普通单词一样，按照驼峰方式拼写。
QueryUrl 、UpdateSql 、NbaList 、FakeApi 、Rest 、UserDto 、UserVo 。

而 DTO 、VO 、DAO 这类东西和前面其他专有名词缩写有一点不一样的地方在于它在名字中是存在特定编程含义的，而其他专有名词在技术层面没有任何意义。
NbaList 、CnCity 、这类缩写对于某个新加入项目的人而言与 AList 、BObject 并无区别理解代码改造代码的时候无需了解这个缩写的含义； DTO 和 VO 你看到他们的时候你就知道这个类的用途。

所以我可以理解为什么有人认为该保持全大写，但我个人更倾向于统一用驼峰，不能因为它表达的含义不同就专门例外。

前后端分离指的主要是渲染视图和数据分离， 不一定前端非得有专门的服务器。

比如完全可以直接生成静态的 html ，用户请求之前这个页面就已经生成完成， 然后由浏览器直接渲染这个完整的 html ，再执行 js ，通过 ajax 读取到数据 A ，再把数据也渲染出来。当用户访问其他页面的时候就是访问另外一个 html ，从页头到页脚都重新读取重新渲染不管一样不一样，然后再去读取另一个数据 B 。


但这样就出现了一个最主要的问题，当是搜索引擎爬虫访问或者用户网络不好的时候，他们只能看到一个空框架没有任何数据内容。
为了解决这个问题，所以才又专门准备一个渲染服务器，也就是你说的前端服务器，html 页不再是直接生成好的空框架页面了， 而是可以先读取空框架模版再由渲染服务器去访问后端服务器获取数据，然后生成包含数据的 html 页，这时候再返回给用户。

0 、GPL 不限制收费，只要你给源码，哪怕你直接拿开源软件就改个名字去卖一个亿都不违反 GPL 协议。


先说 web 项目和网站用户的问题，GPL 诞生的年代 Web 的形态和现在差得远呢，他们确实没有考虑到这种形式。所以你的网站如果只是提供服务，那么 GPL 的代码你在修改之后也不需要给谁，因为你只是在使用，没有“发布、分发”，所以自然不需要为你分发的客户提供源代码。 网站的用户只是通过某种协议访问了你提供的服务，但他们并没有你这个服务的所有权。

---------------
比如你拿一个 GPL 开源的 wordpress 插件修改成了一个在国内很优秀的功能，你自己搭建了一个网站大堆用户都用这个插件的功能，这时候你不需要给他们源码； 然后你选择售卖这个插件盈利，那么你有义务向购买了你程序的其他网站站长提供源代码。
----------------

我以为偏技术性的论坛对于服务器防护还会比较关注。

没想到大家安全防护意识这么低的么...

如果说向安全大佬一样，所有端口都采取白名单那确实不现实，毕竟很多时候我们访问自己服务器的出口 ip 不是固定的。
但不开放常用端口，常用协议不使用默认端口和不使用弱口令好像真的挺常识的....

@xiayushengfan mongodb ，我们用的也不是很有心得，我们还是按照关系型数据库的用法或者 k-v 缓存的用法在用。

比如我们如果用 mongodb 存站内信的话，就是一个集合是所有消息，或者一个集合是一个月的消息之类的维度，每个文档包含文档的全部内容包括所有的接受用户 id ，以及已读状态， 查询的时候 直接查当前用户 id 的文档数据。

@kaiki 最后我们是发多条了，没有组的概念，这种情况下按照你说的方式确实能优化一些存储。

针对后面的问题，我们的文章表有 n 多字段，对于消息来说都是完全没用的，而且文章没有记录多少人已读的。
最后我们的站内信不是用户给用户发送的，基本都是系统通知，"你订阅的 某个资源更新了，url " 类似这种，所以我们和楼主的也不完全相似，因为我们的消息大多数是分组的，个别是全站群发，没有用户间私信。

最后说说你的需求
1 、数据肯定要落库的，虽然这个数据重要性不高丢了就丢了，但发消息偶尔会出现收不到肯定最起码业务领导会不爽。
所以如果想要性能那就用搜索引擎 es 或者其他非关系数据库如 mongoDB ，数据读取层面还可以加 redis 。

2 ，3 、阅读很少那就把阅读单独建表， 就像我们那种， 阅读表包含消息 id 、用户 id 、是否已读、已读时间、创建时间啥的。

本来当时打算有个消息发送组的概念，消息分为发给个人还是发给某个组， 然后组里面有个魔法值是群发。
结果这个功能对于我们本事不是很重要，而且人手要优先干其他的，所以这里就简化了，有给某个组群发的需求，就 foreach ，创建多条信息发送给指定的人。

我先说个我之前设计的实现，不一定好，而且当时我们的在线用户量级很小都不担心这个问题。

一张用户表，一张站内信表，一张站内信已读表。

站内信表中有 sendUserId 字段 魔法值 0 代表发送给所有人，其他值代表只发给某人。
因为我们数据量不大，所以消息是直接 join 查的，order 排序未读的展示在前。