@philnash
Developer relations engineer at DataStax
馃 Developer relations engineer at DataStax | 馃帳 speaker | 馃摑 writer | 馃尛 sausage dog owner | he/him
Nothing here yet.
Hey Elsa , I'm not actually talking about using the WhatsApp application here (the original or the GB version). In this blog post we build an bot that talks to people over WhatsApp using the Twilio API for WhatsApp. Instead of using the WhatsApp app to send messages, we use the API and a WhatsApp business account.
馃槄 I voted for "Bugs? 馃え" but that's because I am a developer evangelist and am not responsible for anything that has a release schedule or anything like that. In my open source work I try to fix bugs as and when they appear, but there's no specific day for that and sometimes I don't have the time either.
Hi everyone! My name is Phil and I am a developer evangelist at Twilio based in Melbourne, Australia though I'm originally from the UK. I mainly work with JavaScript (Node.js or web) and Ruby and love to build things, learn from them and teach anything I find along the way that I think might be useful. I blog on my own site philna.sh (check out that URL 馃槈) and on the Twilio blog but you'll find that posts from both have started to appear on my Hashnode Devblog so you can follow them there. Most of my code I write goes straight to GitHub , which is where you can see example apps and open source projects that I've released. As a developer evangelist I have the fortune to spend time supporting my local developer communities, speaking at meetups and conferences and helping out on Stack Overflow . If you're ever at developer events in Australia I hope to meet you at some point! I look forward to following and learning from this community as well as sharing my own blog posts. Hello! 馃憢
Yashu Mittal What do you mean by application secret? An application wide secret, your "secretKey" from the initial post. My expectations for using user password or timestamp to generate token was to get a unique secret key for every user. But what's the benefit here? or even, if you insist, a generated secret per user You mean to say, generate a unique ID just like a userID and store it inside the database and then use it later for decode the userToken. If you absolutely need to have a unique way of signing JWTs per user, then I would generate a unique random key per user that had nothing to do with their password but was stored against their user record. However, I would still question why you're doing this with a JWT if you still expect to look up the user in the database every time? Why not use a regular session cookie? Or, why not use an application level secret so that you don't have to hit the database to verify the JWT?
Yashu Mittal More things have occurred to me since writing this. A secret key in an application should be a long, random key. Rails, for example, generates a 64 byte random string by default. Guessing a key like this is practically impossible, however guessing a user password is relatively easy, especially since so many users re-use passwords and so many sites have been compromised and leaked these passwords. I don't think you can use a timestamp for this. OTPs require a shared secret in order to generate and validate the OTP. The only thing this would add would be time sensitivity and make the boundaries of OTP periods awkward. The more I think about it, the more likely you are to be able to keep a long, random secret safe yourself than rely on users to keep their passwords secret. So I would prefer to stick with an application secret (or even, if you insist, a generated secret per user). But you didn't tell me what your expected benefit of using the user password was, aside from increased security, which I refute.