V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  yamedie  ›  全部回复第 40 页 / 共 52 页
回复总数  1021
1 ... 36  37  38  39  40  41  42  43  44  45 ... 52  
2018-08-20 17:27:31 +08:00
回复了 yearking 创建的主题 Python 如何把 js 中的数据传到 Python 中
python 写一个 rest 接口供 js 调用就好了
2018-08-20 17:17:23 +08:00
回复了 Hanggi 创建的主题 JavaScript js 源码保护问题
nw.js 有解决方案, 我前年用过, 编译成二进制.bin 文件, 客户端也用 nw 在内存中解密吧, 官方文档说是解密有 35%的性能损耗(耗时更长一些) 关键词: nwjc
2018-08-20 11:45:37 +08:00
回复了 yamedie 创建的主题 分享创造 写了一个聊天室,给任意网站加入尬聊功能
@onionnews 哦,之前在 zimuzu.io 看到的聊天室就类似这个样子,后来不见了.原来有不少这种商业化的服务..
2018-08-20 11:31:52 +08:00
回复了 yamedie 创建的主题 分享创造 写了一个聊天室,给任意网站加入尬聊功能
@caijunyi
只需要在你的网站的 html 里写这样一行
<script src="https://topurl$$$.cn/chat.js"></script>
请把上面的$$$删掉(不然我发不出回复..)

一般在自己的网站引入不被信任的第三方 script 是很危险的行为...所以您自己掂量哈
(我首先承诺不作恶, 聊天服务超出服务器负载能力的情况下有关停的可能)
2018-08-19 16:16:04 +08:00
回复了 yamedie 创建的主题 分享创造 写了一个聊天室,给任意网站加入尬聊功能
从昨晚发帖到今天陆续更新了以下特性..

> @其他用户
> 随机产生非紸流網詺, 而不再是游客 xxx
> 加入断线重连和换网名的功能
> 进入聊天室时拉取最近的历史记录
> 移动端适配(虽然适配得还是不太好, 可以在这里试试效果 http://bookmark.city/ )
> 当聊天室只有一个人时触发彩蛋
2018-08-19 10:05:08 +08:00
回复了 yamedie 创建的主题 分享创造 写了一个聊天室,给任意网站加入尬聊功能
@artandlol 除非是一些交换资源(发车)的场景,会有人愿意聊天😅
2018-08-19 00:31:08 +08:00
回复了 yamedie 创建的主题 分享创造 写了一个聊天室,给任意网站加入尬聊功能
@batnss 在改名字, 重启了一下服务..
2018-08-18 23:35:03 +08:00
回复了 yamedie 创建的主题 分享创造 写了一个聊天室,给任意网站加入尬聊功能
@LongLights ^_^

@SukkaW 不要上 CSP, 一起造作呀 ^_^
2018-08-16 18:02:29 +08:00
回复了 adidala 创建的主题 分享创造 分享个人小站,查询电商历史价格,京东、天猫、淘宝等
@adidala 哈哈原来如此,那你也是 666,大大降低了查询操作的复杂度
2018-08-16 17:25:38 +08:00
回复了 adidala 创建的主题 分享创造 分享个人小站,查询电商历史价格,京东、天猫、淘宝等
@yamedie 我知道了.. 可能是爬友商的
2018-08-16 17:20:36 +08:00
回复了 adidala 创建的主题 分享创造 分享个人小站,查询电商历史价格,京东、天猫、淘宝等
牛!! 想知道海量的商品价格是怎么获取的? 一个个爬?
2018-08-15 14:21:42 +08:00
回复了 xitu 创建的主题 推广 [北京][9.16] 掘金开发者大会 · 微信小程序专场赠票啦~
行, 我败了, 我是前端小白, 我认同 83 楼的结论.
@binux 不是冒充 token, 而是没有进行 token 与入参的比对和鉴权(判断 token 的主人和入参的 userId 是不是同一个人), 这个问题我跟后端提过多次, 现在新接手的人愿意去改掉了.

我为了规避这个问题不捅娄子, 我还想方设法在 spa 里不暴露 userId, 至少让它在浏览器里不被篡改, 现在想想是很多余的, 这些越权的漏洞应该后端来解决, 无奈之前的 java 太懒不想改, 后台 leader 也不想管.
@xycool 不瞒你说我司真的是前端算 signature 的, 但同时所有请求也用了 OAuth 的 token, 两种鉴权方式一起用.
但我们的 java 没做到自己信息只有自己能查, 只要 token 和签名正确了, 也能冒充其他用户身份,只要篡改一下用户 id 就行了,所以我觉得我们的 java 不行,没做到 74 楼说的用户只能访问自己数据(可能接口安全他们只差一步而已).
所以我觉得,只要哪天微信 webapp 的浏览器限制被人破解了,我们这个破系统分分钟完蛋,因为后端虽然鉴权了,但根本没法防止用户在客户端篡改伪造身份.
@chinvo 我来解释为什么用 dev 版不好? 因为前端代码没经过任何混淆就暴露在外, model 层数据整理的明明白白供你调试, 比那些 jQuery 开发的项目还容易让人搞懂业务逻辑. 假设前端调 ajax 还经过了前后台共同约定的 seed 做了参数加密签名(sha1 那些非对称加密), 你的签名加密方式也暴露的明明白白, 别人掌握了伪造接口签名, 就能用个 postman 轻松修理你们后端
我搞不懂你们槽点在哪里, 我说过前端验证[取代后端]了吗? 我一直在强调做 2 次验证好吗?

腾讯云学生机 360 元那次 bug 营销, 你们这些毕业多年凡是买了的, 哪个不是把 select 框 value 改掉再提交的?
@gouflv 好的,我知道. 在公司除了前端还有部分产品设计工作, 我业余也在做全栈项目
"永远不要相信用户的输入" 大家把这里的不信用户等同于不信前端, 没关系, 没人否定后端的数据校验必不可少, 这是数据达到数据库的最后一道关口.
说前端校验是为了用户体验, 与安全无关的, 可以了解一下这本书 https://book.douban.com/subject/10546925/ 从第 2 到第 6 张全部是在讲客户端安全,客户端发起的攻击除了表单篡改, 还有跨站攻击,csrf 攻击.
@phpcxy 恕我也直言,前端才不管后端做不做数据校验,反正页面正常 ajax 传给后端的参数合理合法就行,出了事锅该是谁的就是谁的.
@bestkayle 可以这么说,也不止如此而已,打个不太合适的比方(可能会惹怒很多后端大佬): 民工都知道筛细沙要从粗到细过很多次筛子,为啥这里的高级码农不知道.

一直尝试在 web 安全的角度讨论前端该不该做一次表单验证,
但各位后端大佬给我的感觉是: 给你脸了?后端能做所有表单验证为什么轮到前端做?
如果真这么完美可能世界上就没那么多黑天鹅事件了, 墨菲定律恐怕也是胡说八道.
好了我不再回复了,各位后端大佬继续嗨吧打扰了
1 ... 36  37  38  39  40  41  42  43  44  45 ... 52  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2357 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 29ms · UTC 15:54 · PVG 23:54 · LAX 08:54 · JFK 11:54
Developed with CodeLauncher
♥ Do have faith in what you're doing.