Using the guide from Twilio Docs, I am adding Service Rate Limits to my Verify Service. However, I do not know how to specify to rate limit based on phone number. How do you do this?
Related
To send sms/text via email to a verizon number you can email PHONENUMBER#vtext.com. To send it to att number you can email PHONENUMBER#txt.att.net . This requires knowing which mobile operator the phone number belongs. Is there any way to send sms/text to a number without knowing the operator the number belongs to.
If there is some such third party services, how do they implement this service. Do they email all the operators and hope that it reaches through atleast one of those emails OR do they use any sms gateway?
Twilio developer evangelist here.
Using the Twilio SMS API you can send messages to numbers all around the world. This is not using the often undocumented and potentially flaky phone number email scheme. Instead Twilio has deals and connections to carriers and other partners that we use to route messages around the world to the destination hand sets. We call this the Super Network and you can read more about it here.
I've created custom Alexa skill (using AWS lambda function), which should do the following things:
Send a message to slack channel.
Dial-in hardcoded phone number.
Now, I'm looking for the solution to make a call using this custom skill.
Is it possible to do?
P.S. A4B (Alexa for business) provide the possibility to setup conference provider, which require SIP number which I don't have. I only have phone number.
Thank you in advance!
Unfortunately, this is not possible for now. Alexa is not able to dial in the phone number from custom skill.
You can dial hardcoded phone numbers using Twilio API.
I am working with the card.io Android PhoneGap SDK but have had trouble with getting any other data except credit card number. I also want to get the name and expiry date. Is there a way to do that in the latest card.io sdk?
In CardIOPGPlugin.js (https://github.com/mudasserajaz12/card.io-phonegap-plugin/blob/b5cb05d502b84e5b4d1bd029ebc7ec81e3134345/www/card.io.js), it is written in the comments that:
//Your response array contain these fields
// redacted_card_number, card_number, expiry_month,expiry_year, cvv, zip
Is there anything which i am missing? please guide me, thanking you in anticipation.
Dave from card.io here.
card.io is designed to automatically scan the card number. We are currently working on also scanning the expiration date.
Besides using automatic scanning, the user can also choose to tap the "Enter Manually" button, in which case card number, expiration date, CVV, and ZIP are all available. This is the route through which the various other fields in the response array will be filled in.
Recently I came across an old project for Nokia Asha with app tracking in it.
For every screen accessed by the user a Http request would be made to report to the analytics service and one of the parameters sent was the IMEI in the mobile device.
As far as I know, retrieving information like the IMEI on Windows Phone and iPhone is not permitted but on Android it's still an available function but requires the permission to read the state and identity of the phone which I've been told scare some users.
From what I'm seeing, using this kind of information is being discouraged in which case what alternatives are being more encouraged to implement to identify a device when it comes to analytics services or similar?
You can use a random ID to identify each client.
Odds: With a 64-bit random ID (using, say, nextLong()), the odds of accidental collision are exceedingly small. You'd need 4 billion clients to get the probability of the first accidental collision up to 1/2. This is plenty good enough for analytics.
Implementation: The server can use Java's SecureRandom to generate the ID and put it in a cookie on the HTTP reply if the HTTP request doesn't already have one. Either way, the analytics would associate that request with that cookie.
If the client is a native app rather than a web app, it will need to store the cookie and attach it to future HTTP requests.
Alternatives: If users need to log in to your app, then you can associate usage with their login ID. Otherwise, generate a token.
There are many reasons to not ask the user for their cellphone number including privacy, reliability, and annoying people. Many potential users will drop out rather than enter their cellphone number, while others will enter something like all ones. A random ID will be more unique.
If you need to do account validation via SMS, then you'll have to ask for a phone number. In that case you'll need a privacy policy, a data retention policy and plan, encrypted storage, you'll have to explain it to users, and cope with a substantial fraction of dropouts.
Even if you don't retain the phone numbers, you could construct a one-way secure hash from it to use for the client ID, but phone numbers get recycled so over the long term, random IDs will be more unique than verified phone numbers.
i have jQuery mobile site,
Is it possible to restrict accessed to my site by signing by unique phone number ?
foe example, i have list with 5 phone numbers - Only these phones will be able to enter the site.
is it possible ? if yes, how to do it ?
thanks
You cannot directly access clients phone number via javascript. But you can use other authentication methods which involve clients' phone numbers like SMS password sending through SMS gateway services.
Anyone can enter any phone-number; as data from the client it should not be trusted. Even if this information was available innately to JavaScript or the server - it is not, spammers/advertisers would love it it were! - it would be unwise to rely on it for "security" as phone numbers are not [usually] secrets.
However, one could use the 2nd factor ("has something") of a two-factor authentication: when a user says "hey, I have this phone number", send them an SMS with a nonce (one-time password). If the user enters that nonce, then they [currently] have the phone on-hand, or someone else has it..
..which is why 1st factor ("knows something") is still relevant.