求助：如何记录可读的操作行为日志

will7v — Wed, 18 May 2016 16:03:28 +0800

求助大家个问题：

对于 Project（项目）这个 model，与之相关联的有很多其他 model，比如，文档 Documents( project has_many documents)，意向 Interests(projects HABTM interests) 等

需求：

要记录下所有的操作行为日志，以后要获取查看，要记录的日志应该包括两部分线索和 可读文本，可读文本是要后面输出的，所以想在保存日志的时候拼好存起来，到时直接输出可读文本，线索留底。

举个场景：

修改关联的对象，如 interests，线索类似是"interests: { amount: 20, rating: 5, ... }"，输出的文本是"who 在 when 修改了 what（项目）的意向 aaa 的属性，新的值为 xxx"
做了某个动作，动作可以包括修改或创建多个对象，线索类似 { followers: 1, 2, 3, sector: 2, leader: 4 } , 输出的文本是"who 在 when 推进了项目，新的领导是 xxx4，新的协同者是 xxx1,xxx2,xxx3, 区域改为中国"

想到的解决方案：

类似 event-sourcing 的方法，删除和修改（哪怕是一个字段的修改）只做增量，用 before_create 回调记录的日志 log，对应到某条记录：

参考：

Event Sourcing Taking D out of CRUD

遇到问题：

碰到场景 2，本来想的效果是一条记录，现在会因为修改多个对象要记录多条
某些对象有 is_removed 属性，就算记录了 version，前面的 version 是 is_removed: true，后面修改了的话，前面的还是会被查出来，除非删除的时候还要动原来的记录，这与全部增量的原则不符
表可能会很大，如果要往另一个历史表迁就还要考虑其他问题，而且每个表都要对应出一个历史表

手动硬写，命令式记录日志，先用 changed_attributes 检查被修改的字段，针对每个要记录的动作手动 merge 其他线索，再 before_save 用动作对应的文本模版写文本

参考：

Dirty

一点也不优雅，把代码搞的很难看，有时还会碰到问题（比如 grape declared(params)，碰到这个效果

# controller
Project.transaction do
  project.remark = declared(params).remark
  project.logdown(503, @current_user, {})
  project.save
end
# model
def logdown(event_id, current_user, clue = {})
  clues = self.changed_attributes.merge(clue) # 这里拿到的self.changed_attributes 是{ "remark"=>"#<Hashie::Mash funding_id=1 remark=\"hello\">"} 
  logs.create!(user_id: current_user.id, event_id: event_id, clues_cached: cues)
end

要针对每个动作写一个方法来拼线索和文本

求各位高手指点一个优雅点的方法，或者其他好的思路

前后端分离，App 和 Web 端关于用户验证接口的一些疑惑

will7v — Fri, 22 Apr 2016 11:46:40 +0800

目前我们是前后端分离，关于用户鉴权部分的接口，web 和 app 想共用一套

web 端原来的方案：

token 用 jwt 包一层，只是用了加密的功能，没有 jwt 的过期，关于 token 有效性和失效时间的管理是用存表判断来管理。前端把下发的 jwt 存在 cookie 里，每次服务端读取 cookie 里的 token 鉴权。
尽量用了 RESTful 的规范，幂等的只读接口是用 GET，可能有副作用的用 POST。

现在 app 端开始做对接，app 同事认为 POST 比 GET 更安全（实际抓包的话都是暴露的），GET 请求的话他把 jwt 放在 url 的参数里，认为这样不安全，请问

前后端分离时各位是怎么设计用户验证这块接口的，有什么更好的方案吗？
app 端除了把 token 放在 url 或者 request 的 header 里，还有什么更好的方案吗？

will7v (超级威)

求助：如何记录可读的操作行为日志

前后端分离，App 和 Web 端关于用户验证接口的一些疑惑