#51 楼 @rei 下载了海外支付文档，里面有 Alipay testing environment WAP.docx 的文档，提供了测试环境地址账号，生成 service url 的原理是一样的，通过你的 gem 生成的 url，直接贴浏览器可以完成支付，给 a 标签跳转也可以，不过 form action method=get 方式提示“调试错误，请回到请求来源地，重新发起请求” ，错误代码 ILLEGAL_EXTERFACE，但是提供的 php demo 也是创建 form 方式 submit 有些奇怪

看了下源码，感觉主要用来生成请求 url 的，另外 GATEWAY_URL 似乎不可配置，比如想改成测试环境 url https://openapi.alipaydev.com/gateway.do请指点 @rei ，谢谢！

很棒，这是重点，"也许第一次，你花了几天才把它调试成功，但以后每次，它都将节省你大量的时间。"

http://liunian.info/%E4%BD%BF%E7%94%A8-weinre-%E8%BF%9C%E7%A8%8B%E8%B0%83%E8%AF%95%E7%A7%BB%E5%8A%A8%E7%AB%AF%E9%A1%B5%E9%9D%A2.html

用的就是 weinre，可以解

与云风一起 coding，膜拜下 :plus1:

#4 楼 @liwei78 对于不会 rsync，scp，wget 也未尝不是个办法，挫办法不一定不好，只要能快速解决问题；rsync 还要配置下，wget nginx 分分钟搞定。

“把文件复制到本地，然后在上传到新服务器中”直接上传新服务器不行么，为啥要先到本地。

关于附件，可以先打包一份当前的数据，然后上传到新服务器，解压，然后通过 rsync 同步下即可，不一定是好方法，实际操作过，仅供参考。

弱弱地问下，回到顶部按钮似乎没有了，故意的么，还是忘记了？

用户名密码，登录后给 token 为啥不好

使用场景：海外公司运营微信公众号，想要使用支付功能是不是也可以考虑这种方案？

#1 楼 @rd084c 我的使用场景是数据抓取，后来我改进了抓取逻辑，可能对你来说没啥帮助。

#4 楼 @jimrokliu 哇还真有人这么干那，后来打算直接原生得了。

谢谢回复，有思路了。

万事开头难，时不时会看到楼主分享的文章，是一位很认真的开发者，很棒，值得学习…… :plus1:

:plus1:

杭州有时真堵的狗一样的，有车都不想开。

什么都玩，只是略懂，ruby / php / java / object c，还是 ruby 好玩

#3 楼 @xiaoronglv 恩，是这样的，确实可以理解的。内容运营是一个长期的过程。

#1 楼 @cjmt 内容类阅读，个人觉得，差异主要还是在内容的质量，方向，定位上。

@vincent 基本都解释了，其实本质上和 web 上的 cookie 类似，就是换成 token 了。

1.最基础的版本可以看成是一个永不过期的 cookie，客户端存储存储，利用这个来实现验证，相当于保持登录状态，当然安全性比较差一点；

2.继续高级一点就是给 token 增加过期时间提高安全性；

3.再高级一点可以添加一个 refresh_token 用于刷新 access_token，就是用 refresh_token 换 access_token，可以参考微信的方法：https://open.weixin.qq.com/cgi-bin/showdocument?action=dir_list&t=resource/res_list&verify=1&lang=zh_CNaccess_token（移动开发》微信登录），具体的一些细节可以根据实际情况来改进，首次登录的时候用用户名密码换取 和 refresh_token，以后不需要用户名密码，通过 refresh_token 去刷新 access_token 即可，重新登录同理，外加一个请求作用域 scope 基本是比较安全了，根据自身情况做调整；

4.“这种会话保存机制除了用在用户登录验证之外，在移动端还可以用来做点啥呢？”作为资源请求的凭证，比如查看文章，需要用户登录才能查看，游客状态无法查看，那么就需要带上 access_token，再请求资源的时候来判别当前用户是否有权访问资源；

5.header 头或者普通参数看你自己选择，header 头看起来高端一些，你可以自定义一个 header 头属性，客户端存储这个 token，每次需要验证权限的请求一起发送；

有些理解可能有偏差，仅供参考

@quakewang 挺棒的，学习了，相比敏感词库这一类方案应该更靠谱些，主要是在相似度算法的实现上。 discuz / phpwind 的处理方案是，敏感词库，但是也不是很好使，discuz 的方案优于 phpwind。

简书确实在一点点变好，遇到这些问题也未尝是坏事，说明关注度在提高。 @larryzhao

#4 楼 @yzdel2000 这和你手机偷了，然后告诉警察叔叔让他帮你找回类似，比较困难，取证困难，全国这么多论坛，社区，如果都这么干，警察叔叔也忙不过来，举报的过程中还需要取证，调查。

应该没有根本性的方案，主要还是人工 + 机器配合改善，找一个平衡点，审核，针对什么对象，什么内容进行审核，什么时候引入审核机制……

@mogodb 朋友，同事，网络，觉得需要慢慢培养吧，不是一下子就能搞成的，关键是要有意识。

@cloudqq 你的例子应该蛮多人开始都会遇到这样的问题，迫于生计，有时候做选择的时候可能也很无奈。我觉得应该是方法或者形式上需要去改变一下，做一些新尝试，比如找个小伙伴，遇到问题也可以商量，可以把自己一部分的工作分出来。可能自己是有能力适合每一个位置，但一天就 24 小时，时间就像海绵里的水，挤到最后也是要挤完的，全部自己搞，当然可以，但时间久了，会非常疲惫。我尝试过做兼职，每天 6 点起床，晚上 12 点睡觉，感觉持续时间久了，比如几个月，身体就开始又反应了。

所以我觉得是不是该找些小伙伴组建一个高效的团队去提升单位时间的产出，或者说是提升劳动力带给客户的价值。当然做任何改变都不是难么容易的，Good luck，但愿你写第三篇时候能够有所突破。

一直也很向往 remote，看了楼主的文章，颇有感触，@kgen 分析得挺有道理的。目前来说，因为只有一个人，什么都得你自己干，所以陷入了疲惫的死循环中去。当然也有收获的一部分，自由度更高些了，由此看来单兵作战还是比较吃力的，所以组建一个分工不同的 remote 团队是不是会更合适一些。

#3 楼 @est 谢谢，关于细节的第二点是不是类似我说的那样？

#1 楼 @est 所有客户端用同一个 channel，那如果识别具体是属于某个用户的，通过推送消息里面给 user_id 标识？

作者挺有才的，碰到这样的代码直接就跪了，长痛不如短痛，直接重写吧。

非常不错啊，感觉讲了一个非常精彩的故事。我曾经也碰到过类似的事情，因为时间关系，并没有像楼主那样去刨根问底，根源大概也是找到了，但是没有很好的解决。最终的方案因为是使用了 ucloud，主机数据重新迁移了下，然后 ip 动态绑定解决的。那一次对方应该是通过 tomcat 漏洞进来的，因为偷懒，tomcat 默认配置，端口没有修改，站点管理也没有关闭，可能是这么进来的。然后在/etc/init.d/下会植入一个进程，杀掉了还会重新启动。

有些命令行工具学习了。