Rails101二刷 8.3的update部分

把edit定义到没大问题的感觉

就继续尝试update的定义, 如下截图的方法可以避开报错, 不过...

把update这样定义巨厉害...改其中一个post文章的edit界面内容, 全部整个user post过的文章全部一起改了,连不是group owner的group里的post内容都改成一致, 卧槽, 效果太牛了哈哈哈哈哈


一整排都一样太彪悍了哈哈哈

真的觉得从edit的定义开始就有问题了哈哈哈哈 继续试吧. 

我现在真的很想知道去哪里查正确的params们啊哈哈哈哈



Second Try

一通改都不满意, 然后把edit的内容改成如下截图的

这样说不定定位能准一些, 别全部的post一起改动. 尝试一下. 接着把update的定义改动成这样


结果还是全体一起变, 妈呀, 太好笑了哈哈哈哈

再尝试一次! 认真观察一下之前的CRUD里update的部分, 改成如下


终于成了哈哈哈哈哈哈!!! 

不是@post = Post.update(post_params)

而是@post.update(post_params)

整个就能对单独的post改内容了!!! 太high了哈哈哈哈哈 居然把问题解决了哈哈哈哈哈哈哈


彩蛋

接着玩一下, 看看是什么精准定位到了独自的post~~

第一个改动

先玩一下edit的def部分, 改回去


看看效果

嗯, 不会报错. 但无论挑选哪个post改动, 只能改动之前已经改动的那个post. 

比如, 之前改了第九条的内容. 我现在就算点击第一个post的内容, 到edit页面也不会显示第一条post的内容, 而是第九条的内容. 改动内容submit后, 回到posts的页面也只显示改动了第九条的内容. 第一条内容纹丝不动完全不受影响. 真是神奇哦哈哈哈哈, 这就是params[:group_id]的神奇了吧?!!


第二个改动

把edit改成正确的, 接着试着改一下update的内容

删掉 @post = Post.find(params[:id])这条看看效果


效果是报错, 跳过这步后, 直接找不着北了, 感觉也是post都没给个方向


第三个改动

把@post = Post.find(params[:id])

改成@post = Post.find(post_params) 

看看效果


看来这样是找不到post的id的, 毕竟post_params是我自己定义的调出post具体内容用的代码, 并不是内建的一个id数据, 而是一个复合型内容, 并不是post的id呢~


第四个改动

删掉@post.group = @group这行代码

居然完全没有影响, 我去, 原来这行不需要的咩?!!!肯定有啥作用吧?!!! 还是说在edit已经定位完成, 所以这行删掉没有影响?! 肯定有啥作用吧?! 在create里面存在一定有用吧? 说不定要等我更厉害了才知道它的作用吧...OK,继续试


第五个改动

删掉@post.group = @group这行代码 的基础上, 继续删除 @post.user = current_user

就是两行代码都一起删掉, 感觉去掉两个限定条件的感觉, 看看效果

完全没有影响...


最后总结


最后, 变成这样了...这样的update的def版本, 也是能正常运作的...

create里面给那么限定条件, 这里可以偷工减料什么原理?!!! 希望能早点搞明白!!!

不过anyway, 恭喜自己找到最简约版的写法?! 


P.S. 

我猜, 估计可能是因为before_action限定了只能是注册用户才能改动...哦, 不是...估计是因为我设定了只显示current_user自己的post页面, 才导致从view上面的button们点击这条途径无法对此user的post动手脚. 找到了post_id的话, 非此user也能从后门进来改动post的内容.哦哦哦, 如果是这样的话, 如果我尝试走后门的方法, 估计能用另外一个用户登录的情况下, 在缺失那两个限制条件的情况下直接改动其他user的post!!!


尝试我的猜想

卧槽...我在用户A登录的情况下复制了edit的页面

http://localhost:3000/groups/9/posts/1/edit

然后登出, 用用户B登录, 然后复制这个网址, 真的可以改动用户A的post内容!!! 而且post改动完成后, 还是回到用户B的accout_posts的页面(显示用户B的全部posts的页面),查看用户A的post, 内容真的被改动了!

简直了! 我猜想是对的!!! 


First Try

试试看, 如果只加回去@post.user = current_user会如何


居然还是能改内容, 而且显示在用户B的post页面里面了, 之前用户B的post只有两条. 没有加

@post.user = current_user

这条的时候, 能走后门改动, 而且改动后的post还不会显示在用户B的posts页面里面...妈啊~有趣!!!变成判断是current_user改动的就是显示在这里, 好奇此条是否显示在用户A的页面?


妈呀, 用户A的页面上这两条被用户B走后门改动掉的post都消失了, 不显示在这里了!!!


Second Try

在user这条代码保留的情况下, 继续加回去@post.group = @group 看看效果


用户B的页面还是能继续显示耶...妈呀...看看用户A的情况


改动的那条, edit后又跑去用户B那里了哈哈哈哈!!


虽然没有搞清楚@post.group = @group的作用,  但我知道要多加一条限制, 就是只有current user能做改动? 不对, 不是current_user, 而是创建人本人才可以改动...这是before_action要写多一个限制? 或者是要设置一个什么条件, 要建一个表单, 链接user跟post的表单,对应关系也写进code才能保证走后门的事件不会发生...这个嘛...三刷的时候再尝试吧...现在超级困. 先这样哈哈哈哈

不让走后门事件发生, 可以参考Rails101教程的5.5, 会有解法哦



新的发现


尝试了一下, 发现文章会从之前的创建者转移到 后来"走后门"改动文章的账户下, 是因为这条代码

update之中我写了一条

@post.user = current_user

就是把post的创建人从"之前的"改变成后来"走后门改动"的人的...这条代码删掉后(前面加 # disable掉后), 创建人就不会变动了, 我觉得估计这代码在update中可以保持无效状态. 

你可能感兴趣的:(Rails101二刷 8.3的update部分)