{"action":"created","issue":{"url":"https://api.github.com/repos/eddyystop/feathers-service-verify-reset/issues/15","repository_url":"https://api.github.com/repos/eddyystop/feathers-service-verify-reset","labels_url":"https://api.github.com/repos/eddyystop/feathers-service-verify-reset/issues/15/labels{/name}","comments_url":"https://api.github.com/repos/eddyystop/feathers-service-verify-reset/issues/15/comments","events_url":"https://api.github.com/repos/eddyystop/feathers-service-verify-reset/issues/15/events","html_url":"https://github.com/eddyystop/feathers-service-verify-reset/issues/15","id":185625956,"number":15,"title":"support \"verification code\" mode","user":{"login":"beeplin","id":13058150,"avatar_url":"https://avatars.githubusercontent.com/u/13058150?v=3","gravatar_id":"","url":"https://api.github.com/users/beeplin","html_url":"https://github.com/beeplin","followers_url":"https://api.github.com/users/beeplin/followers","following_url":"https://api.github.com/users/beeplin/following{/other_user}","gists_url":"https://api.github.com/users/beeplin/gists{/gist_id}","starred_url":"https://api.github.com/users/beeplin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/beeplin/subscriptions","organizations_url":"https://api.github.com/users/beeplin/orgs","repos_url":"https://api.github.com/users/beeplin/repos","events_url":"https://api.github.com/users/beeplin/events{/privacy}","received_events_url":"https://api.github.com/users/beeplin/received_events","type":"User","site_admin":false},"labels":[{"id":470022521,"url":"https://api.github.com/repos/eddyystop/feathers-service-verify-reset/labels/scheduled","name":"scheduled","color":"fbca04","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":10,"created_at":"2016-10-27T10:07:14Z","updated_at":"2016-11-06T04:30:24Z","closed_at":null,"body":"Sending a **verification url** to user's email is the old and traditional way to do verify/reset. But nowadays people use mobile phones or social network systems much more frequently than emails. Some young people even don't have their own email address  -- you have to contact them via facebook, twitter, line, or wechat/qq in China. \n\nTherefore today we get a different way to do verify/reset: not sending a **url** to people's email and wait for them clicking it, but just sent a **verification code** (long or short, it depends) to any type of address the user is trying to verify, no matter it is an email, or a cellphone number SMS, or a facebook message, or a line message, etc.\n\nAfter the user received this code, they have to manually input into our app **both the account name they are trying to verify/reset, and the code they received**. Both the two info must be correct, or the verify/reset is invalidated and the code is expired. The use has to ask for another code again.\n\nThis way, when verifying/resetting, we can match not only the code, but also the user account name, and the user has only one chance to try. This helps avoiding hacking, and therefore the code doesn't have to be very long. [0-9a-zA-Z]{6} is always enough, and it is easy to input on a cellphone.\n\nI think this new **verification code** way is used more and more widely compared with the old **verification url** way, and hence suggest that this package should also support this code mode. \n\nWe don't need to break the current API to support this code mode. Just an expansion of API should be enough, say, like this:\n\nWhen the user is signing up in our app: \n\n``` js\napp.service('users').create({\n  email: 'a@b.com',\n  username: 'beeplin',\n  cellphone: '5101112222',\n  password: 'xxxxxx',\n  primaryContactMethod: 'cellphone', // 'email' by default, the target to send to url/code to. any better name?\n  verificationType: 'code' // 'url' by default. generates long slug for url, and short slug for code. any better name?\n})\n```\n\nThen the verification URL/code is sent via email or SMS. If the mode is URL, after the user clicks the link and is routed to our page, `verifySignUp` is called with the slug embedded in the URL. If the mode is code, our app directs the user to a new page and let him/her input the code he/she received, together with his/her email or cellphone (depends on the `primaryContactMethod` he/she chose just before. Then the `verifySignUp` is called with the two info:\n\n``` js\nverifyReset.verifySignUp = function (slugOrOptions, callback) { ... }\n```\n\nwhen `slugOrOptions` is a string, it is the slug, and this means the traditional verification URL mode. Do the verify as we did before, nothing new;\n\nwhen `slugOrOptions` is an object, it is a map for options, and this means the new verification code mode. The option could be like:\n\n``` js\n{\n  email: 'a@b.com',\n  slug: 'xxxxxx'\n}\n```\n\nThis means the user is trying to verify the email `a@b.com` with a received code `xxxxxx`. Do the verification and return the result/error to the user.\n\nThe key point here is that, instead of passing a slug string in, we could also pass an option object in, having a finer control of the user's verify/reset behavior, without breaking the existing API syntax.\n\nThe `sendResetPassword`, `saveResetPassword` can also be extended in this way.\n\nI'd like to know how you think about this?\n"},"comment":{"url":"https://api.github.com/repos/eddyystop/feathers-service-verify-reset/issues/comments/258659879","html_url":"https://github.com/eddyystop/feathers-service-verify-reset/issues/15#issuecomment-258659879","issue_url":"https://api.github.com/repos/eddyystop/feathers-service-verify-reset/issues/15","id":258659879,"user":{"login":"beeplin","id":13058150,"avatar_url":"https://avatars.githubusercontent.com/u/13058150?v=3","gravatar_id":"","url":"https://api.github.com/users/beeplin","html_url":"https://github.com/beeplin","followers_url":"https://api.github.com/users/beeplin/followers","following_url":"https://api.github.com/users/beeplin/following{/other_user}","gists_url":"https://api.github.com/users/beeplin/gists{/gist_id}","starred_url":"https://api.github.com/users/beeplin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/beeplin/subscriptions","organizations_url":"https://api.github.com/users/beeplin/orgs","repos_url":"https://api.github.com/users/beeplin/repos","events_url":"https://api.github.com/users/beeplin/events{/privacy}","received_events_url":"https://api.github.com/users/beeplin/received_events","type":"User","site_admin":false},"created_at":"2016-11-06T04:30:24Z","updated_at":"2016-11-06T04:30:24Z","body":"Since we are talking about Vue... these days I am looking for a neat way to connect feathers from backend and vue on the frontend. It should support socket.io real-time data push, and it would be nice to have a middle data layer to do client-side data cache (both in memory and on disk via localforage). \r\n\r\nFor the cache thing, I am now working on a repo called `feathers-cache`, which will create client-side services as a buffer layer to cache and proxy remote services to Vue or React or any other frontend engines. \r\n\r\nFor the vue-feathers syncing thing, it seems that we get three ways to do that:\r\n\r\n1. by doing something like your `feathers-reduxify-service` for vue/vuex. While not every one uses vuex. Personally I think vuex might be over-engineered too.\r\n \r\n2. by bridging vue and feathers via RxJS observables. Currently we have vue-rx and feathers-reactive out of box, and it works fine. Only that it lacks some commonly needed feathers: reactive loading/saving flags, auto reloading when query changes, etc.\r\n\r\n3. by writing a specific sync tool. Now we have [vue-syncers-feathers](https://github.com/t2t2/vue-syncers-feathers) by @t2t2, and I wrapped it a little as [vue-feathers-sync](https://github.com/beeplin/vue-feathers-sync), adding some trivial extra features. \r\n\r\nI am still trying to figure out which way will be the best. But I guess once these infrastructures (sync, cache, user verify/reset) are ready, feathers with vue would become a super powerful full-stack framework. (I know there is `canjs` for feathers but vue seems much more promising at the frontend.) "}}
{"actor":{"display_login":"beeplin"}}