Vue中的嵌套组件中数据无法实时更新的问题 我们在工作经常会有组件嵌套的情况，内部组件通过props获取传递进来的数据。不过在实际应用中发现，外部组件的数据更新后，内部组件的数据不会实时更新：子组件： 姓名： {{user.name}} 年龄： {{user.age}} export default { props: { user: Object } } 父级组件： import unit from './unit'; export default { components: { unit }, data(){ return { users: [ { name: 'wenzi', age: 27 }, { name: '蚊子', age: 26 } ] }; } } 这么个组件运行是没有问题的，能够正确渲染出一个列表。可是如果list.vue中的users发生变化时，unit.vue里的数据是不会再次更新的。这样的情况怎么解决呢？ 解决方案1： 将两个组件合并成一个组件 # 最简单、最粗糙的方式，将两个组件合并成一个组件，在一个组件内进行数据更新，就不会出现组件之间数据不同步的问题了。不过这样的的问题就是，当前组件会很大，本来我们就是为了解耦功能，才要拆分组件的，不能再次回到过去吧。 解决方案2： watch # 在unit.vue组件中，使用watch监听某个属性的变化，这样外部的数据发生变化时，watch就能监听到：watch: { 'user.age': function(val, oldVal){ this.render(); // user中的age属性发生变化时，调用render方法 } }

单页面切换路由时的倒计时和Vue倒计时组件 我的项目是用Vue写的单页面应用，然后首页上的每个商品都有一个倒计时，计算当前商品距离结束的剩余时间，而且还使用了keep-alive缓存首页中的数据，可是切换到别的路由再切换回首页时，倒计时就出现错乱了： 有多个倒计时交叉进行，出现倒计时混乱。排查后得到的原因是： 在单页面应用中，无论怎么切换hash路由，定时器都是存在的，因此在单页面中切换路由时，应当在组件的deactivated或destroyed中进行销毁；回到这个页面时，再重新启动！分享一个我项目中正在使用的倒计时： vue-countdown。页面中可以多次调用，且相互之前独立倒计时！ import iCountdown from '@/ui/i-countdown'; export default { components: { iCountdown }, }

在红包活动中如何保障账户的安全 我们经常在做一些福利活动来拉动用户的活跃度，提升APP的拉新和拉活。不过总会有些人在寻找我们活动中的漏洞，以此牟利。那么我们是如何预防这些别有用心的人的恶意攻击呢？这里我们就来聊聊是如何防范的。首先我们复原下我们活动的玩法： 用户A从客户端内分享自己的专属链接到朋友圈，或者分享到其他地方，分享链接里带有当前用户A的标识、头像、昵称等信息，他的好友B访问这个分享链接时，会读取URL中的参数，然后填充到页面中；用户B点击分享页面中的按钮时，也会将分享者A的标识带入到客户端内，则用户A邀请B成功！用户A和用户B均可获得现金奖励，现金可以进行提现。首先我们应该知道前端中的攻击都有哪些方式，然后才能针对项目特点进行防范。 1. XSS攻击 # 百科中这样写道： XSS是一种经常出现在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。其实在web前端方面，可以简单的理解为一种javascript代码注入。 就是说XSS利用的是用户对指定网站的信任，访问了被注入的恶意代码，造成XSS攻击。在我们整个活动中，用户可能会修改URL参数的地方有2个： 用户A分享出来他的专属分享链接后，在微信、QQ等地方传播时，用户A可以修改他自己的分享链接参数后，再让别人访问； 用户B点击分享链接中的按钮跳转到客户端前，修改URL中的参数，即可修改传递到端内的参数； 在这2种情况里，URL的参数主要有3种： sopenid: 用来让其他用户重新带入到客户端内，分享页里不做处理； nickname: 展示分享者的用户名，这里作为纯文本处理； avatar: 展示分享者的头像，这里对其进行字符串转义； 1.1 节点内容字符串的处理 # nickname是要直接填充到页面中的，如果没有过滤，就直接对其进行html字符填充，就会造成程序的混乱，或者被填充恶意的链接，用户可能会无意中跳转到第三方的链接中。比如恶意者在url中使用了一段这样的代码：http://news.qq.com?nickname=while(1){alert('hello world')} 那么用户打开这个链接时，就会无限弹窗；如果恶意者在url中使用了这样的代码：http://news.qq.com?nickname= 用户可能就会不小心跳转到第三方的页面；因此这里，要么把参数作为纯文本处理，要么对参数里的字符进行转义后再填充：var escapeHtml = function(str) { return str.replace(//g,'>'); } 1.2 节点属性的处理 # 我们也会获取URL参数里的avatar作为用户的头像，若用户使用了这样的代码：http://news.qq.com?avatar=1"%20onerror="alert(%hello world%27) 那么填充到页面后，就会变成这样： chrome会自动防御这种XSS攻击，不过如果在没有自动防御的浏览器上，还是会被弹窗警告，因此这样可以对引号进行转移：var escapeHtmlProperty = function (str) { if(!str) return ''; return str.replace(/"/g,'&quto;').replace(/'/g,''').replace(/ /g,' '); } 2. CSRF攻击 # 跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。CSRF攻击，我们前端能做的工作很少，需要后端进行防御工作。 refer限制： 所有非白名单中的refer请求，全部拒绝； token验证： 客户端发起的请求中带有token，接口验证token的合法性，若token不合法，则认为请求是伪造的； 客户端时间的校验： 若客户端的本地时间与北京标准时间相差较多时，拒绝； 当然后端接口还有更多的防御工作，我们这里也是简单的举几个例子。 3. https协议 # 在服务器支持https协议时，我们最好把页面按照https的方式开发，要么显式的使用https://或者使用//来让浏览器自己选择。https协议提供了三个强大的功能来对抗上述的劫持行为： 内容加密。浏览器到腾讯服务器的内容都是以加密形式传输，中间者无法直接查看原始内容。 身份认证。保证用户访问的是腾讯服务，即使被 DNS 劫持到了第三方站点，也会提醒用户没有访问百度服务，有可能被劫持 数据完整性。防止内容被第三方冒充或者篡改。 不过在使用https的过程中，踩了个坑。我在页面中把接口的链接都写成//这种隐式的协议，可是在使用客户端的方法请求接口时发现，客户端的方法不会自动根据页面的协议补全请求接口的协议，需要开发者手动补全协议：// 通过 window.location.protocol 获取当前页面的协议 let url = window.location.protocol + '//api.qq.com'; 3. 验证码 # 验证码的作用不必多说，就是为了区分人/机，确定接下来的行为确实是真实用户发起的，而不是机器模拟产生的。为了防止提现接口被恶意爆刷，我们在用户在提现前，也添加了验证码的功能，验证用户的合法性，确定请求确实是用户主动发起的提现行为。 4. 账户验证 # 在客户端中的登录过程，是拉起微信登录或QQ登录，然后登录微信账号或QQ账号，用户全部的操作都需要验证微信账号和QQ账号的合法性和危险登录，若判定当前账号是危险账号，则阻止其进一步的操作。 5. 客户端的验证 # 客户端的验证，是为了保证请求一定是从客户端发起的，而不是从外部某个地方发起的请求。这块在第2部分里也有说明，就是token的验证，客户端发起的任何请求都是带有token的，然后接口验证token的合法性！写的这么多措施和方法，大部分也是常见的攻击和防御，但是我们依然不能掉以轻心，稍微有点疏忽，就会给用户和我们活动方造成不可挽回 的损失。

博客，就是一个折腾 前几天，即使工作很忙，也从鲁迅的海绵里挤出了点水，来给自己的博客小小的改造了一番。样式上没什么大的改动，主要的改动是集中在以下几点： 1. 评论系统前端部分的改造 # 目前是去掉了每篇文章里的分页设置，毕竟，文章也没什么人评论，还要费劲设置个分页，没什么必要，也就给去掉了。同时，对评论功能进行了组件化的开发，方便以后的开发和维护，按照功能拆分出了几个单独的组件： 发布组件、列表组件、按钮组件、Toast 提示组件、弹窗组件等等。以前没有拆分开的时候，这些功能全部都耦合在一起，有需要改动的时候，特别不方便；现在假如还有什么改动时，就方便多了。再一个就是样式上的调整，把发表的时间和回复按钮放在了左侧。虽然评论列表里的右侧显得稍微有点空，不过按照大众习惯靠左侧浏览的习惯，就把发表的时间与回复按钮与用户的昵称放在了一起。 2. 去掉了 jQuery 类库 # 在改造的过程中才发现，在每个页面里都引用的 jQuery 库，原来只是在文章页的侧边导航里用到了，其他的地方都没有用到。如果这么小的一个功能，还要每次都要加载 jQuery，那确实是太不值当了。因此这里就彻底用原生的 ES6 重写了侧边导航，顺带还搭建一个基于 webpack 的脚手架，关于这个脚手架的搭建和使用，我会后面的文章里详细描述（虽然已经有很多人搭建过了）。 3. demo 页面 # 博客最开始是用 jekyll 生成的静态博客，那时候的 demo 页面都是直接写静态页面，然后git push就能直接发表了。后来博客改造成基于 php 的动态博客后，托管在服务器上，如果要上传文件的话，是需要使用 ftp 的，那么直接上传 demo 页面就不方便了。于是就在管理员后台添加了一个直接上传 markdown 代码和 html 代码的管理页面，这样就实现了左侧代码、右侧功能的 demo 页面。可以点击后面的链接查看下效果，不过样式确实有点辣眼睛： 测试 demo。 4. 文章页里图片大小的限制 # 之前插入在文章页里的图片，是只限制了图片的最大宽度不能超过文章页的宽度，高度并没有限制，那么如果有图片很高的话，就会占据很大的版面，图片很宽的话，就会压缩图片，导致无法看清图片上面的内容，于是这里就添加了一个点击图片放大的功能。这里用到了一个小小的知识点： cursor。在 CSS3 里，cursor 的值为zoom-in时，鼠标就会变成+号，表示放大的意思；cursor 的值为zoom-out时，鼠标就会变成-号，表示缩小的意思，然后我们再添加上相关的事件即可；不用再像以前那样还得先生成两张放大和缩小的.cur图片了。比如目前网页版微博，考虑到浏览器的兼容性，依然还用的 cur 图片。点击图片查看下效果：总结： 自从有这个博客后，真正有价值的文章没发表多少，净瞎折腾这个博客了[手动捂脸哭]。

Vue: 单页面应用如何保持登录状态 在单页面应用中，若刷新页面后，登录态是保存不了的。比如我在首页获取到了登录信息，然后存储到vuex中，进入到某个路由中，若当前路由刷新后，vuex中的数据就会被清空，以此也会导致当前路由中依赖登录态的接口都会失效。那么，若当前路由需要刷新，或者当前路由存在第三方的跳转链接时，该怎么办呢？目前是有两种思路，可以供大家参考一下： 1. router与vuex的结合 # 如果您的登录态是通过vuex管理的话，那么一般是首页获取到登录信息，然后存储到vuex中，然后其他路由直接使用即可。但是这样存在的问题，就是刷新页面后，vuex的数据就会消失。这里我们需要借助router中的一个方法。在router中有一个beforeEach方法，这个方法在路由发生变化时就会触发，当然，在当前路由刷新时也会触发，那么就可以在这里监听登录状态的变化。首先是在router/index.js中明确哪些路由是需要登录后才能访问的，哪些是可以直接访问的，下面的代码中可以看到我的奖励页面是需要登录才能访问的，而且奖励中有可能会存在第三方的跳转链接：// router/index.js Vue.use(Router); export default new Router({ routes: [ { path: '/', // shouye name: 'home', components: { Home } }, { path: '/myprize', // 我的奖励 name: 'myprize', components: { MyPrize }, meta: { requiresAuth: true } } ] }) 那么我们在router/auth.js这样判断：// router/auth.js import router from './index.js'; // 获取到路由列表 import store from '../store'; // 获取vuex中的store router.beforeEach((to, from, next)=>{ if(to.meta.requiresAuth){ // 若当前页面需要登录 if(store.state.user.nickname){ // 若vuex中存在用户的昵称，则说明当前有登录态 next(); } else { // 通过检测接口检验用户的登录态， // 然后将获取到的信息再次存储到vuex中 User.getUserInfo(result=> { if(result.nickname){ store.commit('setUserInfo', result); next(); } else { // 去登录 } }) } } else { next(); } }) 若vuex中不存在用户的数据，则说明当前页面肯定是刷新后的，或者从别的页面回退回来导致刷新的。那只能从接口中判断登录态了，若检测到存在登录态，则将用户信息重新存储到vuex中，方便下次的使用；若接口里依然没有登录态，则说明用户真的没有登录，只能让用户去登录了。 2. sessionStorage # 我看有的同学说可以用seesionStorage存储登录信息，不过既然已经使用sessionStorage来存储信息后，感觉也就没必要再通过vuex转换一遍了，不过两者结合起来倒是也可以。而且现在sessionStorage在移动端的兼容性也非常好，基本不用考虑是否可以用的问题。// store import Vuex from 'vuex'; Vue.use(Vuex); const store = new Vuex.Store({ state: { user: JSON.parse( sessionStorage.getItem('user') || '{}' ) } actions: { setUserInfo(state, userinfo){ state.user = Object.assign({}, state.user, userinfo); if(userinfo.nickname){ sessesionStorage.setItem('user', JSON.stringify(user)); } } } }) 这里也只是个简单的样例代码，具体中可以要判断的东西也会更多。 3. 总结 # 在客户端内放置的单页面应用，虽然能让用户操作的比PC上更少，但刷新页面和跳转到第三方链接的情况，还是存在的，因此这个登录问题还是要解决的。目前我正在使用的就是第一种方案，不过我的项目是在客户端里的，可以通过客户端暴露的jsapi来检测登录态。