 Welcome everyone to the session using mobile SMS OTPs for authentication on mobile apps using APM and Filiu SDK by Puneet. We are very glad that Puneet could join us today. So without any further delay, over to you Puneet. Thank you. So hi everyone. This is a bit different format for me but I think I'm going to like it. So thanks a lot for joining. I believe my topic is a pretty trivial and very obvious use case. What we're going to look at in the session is how we can use or how we can leverage Filiu SDK to automate and authenticate users using online numbers. The session is not really complicated and it's very straightforward for anyone to start using it. I will be using Quotset.js as an example to demo but I believe it's pretty much easy for anyone to start using it with whatever framework they are using in their current setups. About myself, I have been in the QA and the automation world for about nine, nine and a half years now. I'm based out of India and I have been associated with several open source projects earlier initially with Joomla. I have also been associated with Percona and I have also been a core contributor and maintainer for Quotset.js. So if you want to reach out to me, that's my Twitter handle. So if you look at the problem statement, I think what we want to achieve at the end of this demo is we want to see how we can use Twilio or any other service or similar service and use an online phone number and be able to use the Twilio SDK to read or send an SMS to these numbers and authenticate our users and automate the entire authentication flow. So why do we need it? A lot of people might have this question that it's not really a very, like it's not very difficult thing to do. We can mock users but in our case, the problem is we have integrations in our platform. So we have several third party integrations on our app starting with even the authentication integration tool that we use is Auth0. So for us, it was very important to make sure that the integration that we have with Auth0 works as expected and we started using mocks but then we realized that there were a lot of issues in terms of the roles and the integration with Auth0 was probably not really being checked well in the mock setups that we had. The second use case for us was we have our app being used in multiple countries and we integrate local SMS vendors API and for example, in Africa, we use Africa stocking in Thailand, we use API tell in India. We use Twilio so depending on different countries where we launch the application, we have different types of integration with different SMS providers. And for us, it's important to make sure that the integration of these SMS providers or these SMS services is working for us and we are able to deliver promotions or the authentication emails to our users at the end of the day. So that was another motivation for us. Being able to run test, obviously it was important for us. We wanted to start running our test on cloud services and having an integration like this was really helpful for us because then we could also use ACD and start authenticating and using API test with the same flow. So it's not just about being able to use it with APM and Intu and Mobile test. You can also use the same flow with your API test also if you use OTB based authentication for users. So what are the known limitations? Probably one thing that I would like to highlight is there are legal foundations and not every country lets you buy an online number without all the legalities. So whenever you sign up on such platforms you will have to go through the legal process. In case, for example, if I talk about India, there is a legal process. You can still get an online number for India but you have to go through some legal documentation. So it's not really straightforward as other countries but you still have a possibility to do that. You also have a possibility to start forwarding SMSs to these numbers. So once you buy an online number you can start forwarding your SMSs to these online numbers and start reading them through the inbound API that we have provided us. Talking about alternatives. So basically, of course, since we have been using Twilio I can only talk about the Twilio SDK and I can only demo the Twilio SDK to you right now. But there are still alternatives out there in the market. There are a lot of them. I could just point out a couple of examples which I've looked them and I've just gone through their APIs briefly. For example, Clivo is actually a cheaper alternative than Twilio. So they don't really charge you for inbound SMSs. Melosaur is just starting up. They are in the SMS beta phase of SMS-based testing. So probably you can also look for an alternative so there's no need for Twilio if you don't really like the options of Twilio. So before I go through the reference let me just quickly try to go through the flow of how you can set up an account with Twilio and how you can start using this. I'm going to get on the browser. Basically, the flow is pretty simple. All you have to do is log in into your Twilio account. You can sign up with your personal email or your company email, whatever you feel like. Once you set up and go with the default options you get on the Twilio project console homepage where you get the account SID and not token. Right now you see on my account I have a phone number because I already prepared a phone number and I already bought an online phone number with my personal account for this session. But probably it's very easy for you to do that. You can go into the phone number section and there you find an option to buy a number. So this is basically the one that we want to use and you can see that they also have an option to provide like you can get an India phone number also or you can get a phone number for any country depending on the legalities that you fulfill. In our case, I'm just going to show you how it works for let's take United States as an example. So when I search for United States it gives me a list of numbers and in here I don't really want the voice, MMS or sex capabilities. I only need SMS capabilities and I only want this so that I can read the inbound SMSs through the Twilio SDK. So I'm just going to search for it. It returns me a list of numbers along with the cost. So every number that you buy it costs you around $1 per month. And any inbound SMSs that you basically any SMS that you trigger on this number would also be like a very minimal charge of probably 0.05 cents. I don't really recall that exactly but it's not really free but it's not expensive as well. And moreover, if you want to try it out initially Twilio gives you initial credit of $15 in your account. So it's like a base credit of $15 that you get to try out their APIs and try out the services. So it's a good starting point for anyone who is looking for a first stop. Now going back to the references I would just like to go through the Twilio documentation that we have. In my example that you're seeing right now I will be showing it in Quotesub.js but depending on the use case that you have you can find it like it supports multiple languages. You can even use it with Pearl. So it's completely flexible for you. In our case, what we have done is we were using Quotesub.js as our automation framework for end to end testing on mobile. So we thought of writing in Helper on top of it and started using it and it's not just being used in one of the single applications being used across in multiple teams. Basically what we need is account SID and a token which I already showed you that you get from the console. Once you provide these two information you can start looking for invoices that are being hit on your number. So let me go back to the reference once. This is the Helper that we wrote for Quotesub.js. You can start using it as an example if you want to. Pretty straightforward, you just have to install it using NPM. There are configuration parameters which is basically account ID and a token that you have to provide as environment variables. Once you have done that, all you have to do is call this read SMS function which is basically being used with the actor object and you can pass a timestamp and the number that you basically are using as your test number. So right now I am just going to show you how it works for us. Basically what we have done is we have a login method and inside the login method what we do is we take the timestamp. So before triggering an OTP on the mobile application we capture the timestamp and then we use the OTP read SMS actor function that you have created, passing the timestamp, passing the number and then basically get the OTP from top of it. So that was just a very quick overview of how the Helper is supposed to work. What I will want to do now is quickly show you people the demo of how it works on ground. So my example, as you can see, we support multiple countries right now and I'm just going to use the online number that I have purchased as an example but you can go ahead and buy any number form for you and start using it in your application. So once it gets the OTP from the API, the SDK it will key in that and be able to log in into the application. So that was basically what I had in terms of demo. I would like to know if there's any questions around it from the audience. Right now there are no questions from the audience, Puneet and I would encourage audience to please ask questions in Q&A. There's a comment which says, is Twilio paid? Yes, it's a paid service. It's not really a free service but you can definitely use the $15 credit that they provide you probably as a starting point and then see if it suits your purpose then it's worth paying that amount I believe. It's not too expensive. Okay. There's next question. We should pass this timestamp in which format? As you can see in my code I am actually providing it in UPC format. So I think that's what we should be doing it. It's in UPC timestamp. Okay. Can we forward the next question? Can we forward the SMS received to any email ID via Twilio? Can we forward the SMS received? Can we forward the SMS received to any email ID via Twilio? I don't really think that's the use case or possibility here right now because it probably you can forward that SMS using the Twilio forward. There is a possibility to do that but I'm not really sure about this part. So probably you have to look through the Twilio SDK. So there is a possibility to forward SMSes definitely but I don't know if they can forward it to an email. Probably what you can do is you can do it yourself. You can just get the SMS and forward or write a small helper around it to try and forward it to your own email or whatever you want to use in the use case. Thank you. Next is can we do same with owning number instead of purchase a new number? So very interesting. That is what I was trying to explain in terms of limitation. What you can do is if you have one single number that you have and it's your own personal number or you already made like you are using some phone numbers for your project or company, you can set up SMS forwarding and you can use only one Twilio number and forward all these numbers to this Twilio online number that you have and start reading it but it will be a cost because you will have to set up a SMS forwarding with your network provider but that's a possibility to do. You can forward whatever SMS you're getting on your phone numbers and forward it to your Twilio online number. Thanks, Puneet. Next question. Is there a possibility to integrate either of these tools with emulator or simulator and automate via APM? Yes, basically we extensively use it on our local emulators also. And this entire setup, I am doing it on my real device right now but I generally run it on emulator also. That's a possibility for sure. You can use it on emulator. You can use it on real device. You can use it with any cloud service that provides emulator or real device. Okay, next questions. You mentioned you are using code set for mobile. Mobile means mobile underscore site or we can use it got native apps automation as well. So we can use it for native apps automation as well. The app that I showed you people is a native app in React and basically it works with anything. So you can use code set JS for mobile application testing using APM integration that they have using the APM helper or code set JS or you can use it on mobile web sites also using playwright or whatever other integrations you want to use or you can use it with even web application which relies on OTP based authentication. Thank you. Next questions. Any open source software available? From my research Pratap, I was not really able to, I was not really able to find any open source tool that provides you an API based setup to read SMSes. Although you have softwares that you can use to get that done but probably not any service that is open source and free to use for such setup. Maybe I could have missed something. So I'm not really sure about it. You have to research about it more. Thank you. Any issues while running the tests parallel? Yes, very good question, Avinash. There is a possibility that you can run up into an issue when you run tests in parallel where you have to pass in the right timestamp and probably it can receive more than two SMSes during that time. So there are different ways in which you can handle it. I am not using limit parameter which is also one of the parameters that the Twilio API has, the Twilio SDK has. Probably the best use case for you would be to start using with different numbers because that will avoid a lot of conflict and help you filter out SMSes like be 100% sure that it's not going to conflict. So that's the best way to handle that one. Okay, next question. For your case, that is you collaborate with local SMS vendors. How do you test? Do you purchase numbers for all those countries? Yeah, that is the plan. So we try to purchase numbers for all those countries and try to make sure that the local vendors that we have integrated and the local services that we have integrated with our app, they're able to deliver SMSes to these numbers. But sometimes it's possible that even with all the legal documentation, you might not be able to get an SMS-based capabilities for an online number. So in that case, we have to make a compromise and try to forward it to another online number that we have and make sure that the service that we are using with that country and that integration actually works. So that's a compromise and a limitation here. Okay, next question. We actually, our testing is done in lower environment. Instead of our, sorry, instead of all these steps, we can ask developers to use standard of like 0, 0, 0, 0, right? So that is what I was trying to mention earlier. That's who earlier I mentioned the same thing when I started my session that a lot of people might think, why do we need it? Why can't we just use mock OTPs or just use hard-coded OTPs? But given the experience that we have had with these integrations that we have in place, we have a different tool for authenticating users. We have a completely different tool for sending SDK implemented for sending SMSes. For us, it was important to be able to make sure that our integration with these services also works. So we can probably go with this approach in a lower environment like maybe QA or stage, but we don't really want to go with this approach in pre-prod environment because we want our pre-prod to be almost similar to production environment. And that's where it becomes very important for us to make sure that the SMSes integration and the delivery of promotion messages and all those are working well for the users. Thank you, Puneet. And last question, is there any other open source SDK to read OTP from the mobile apps? I think that's already answered unless you've read it on something or... No, I think I already tried to answer it. There's no like the helper that I've prepared is actually open source, but if you want to use it with 2U SDK, but there's no other alternative in terms of services that are available to like let you do this free of cost, like be able to read or generate online numbers free of cost. Nice. That's all the questions. And thank you, Puneet. And thanks everyone here. Thank you very much.