We have need to implement local presence dialing in twilio.
Local Presence Dialing : Be Local use a local caller ID on all outbound calls. match the area code of the caller ID with the area code on the Salesforce record.
How can we achieve that requirement in twilio?
Twilio developer evangelist here.
You can try to write the logic to purchase local or international numbers to match your users numbers. I don't know what you're building in or what you've tried so far, so can't specifically help with that. (Though if you have tried something, please feel free to update your question and I'll see how I can help.)
Alternatively, you may like to take a look at Twilio Proxy. It's a newly announced feature of Twilio that handles sessions for you between callers. It can do things like local presence dialling, like Twilio Copilot can for SMS messaging.
Proxy is new, so you need to request access. Let me know if you're interested.
Related
I'm building a game, and someone has exploited the API
How may I choose a list of "allowed domains" that can fetch through my API? My previous API was used by someone to increase their in-game money.
Learn about CORS Policy and implement it on your API Backend. Most probably, if you are using any of the popular frameworks to build your backend, you will already have this setting. You may just need to enable it and add your frontend IP/URL to it.
The comment and answer referring to the usage of CORS aren't solving the problem of someone exploiting your API. Everyone can write a program to simply set the Origin header themselves.
Increase your security by securing the API with any sort of credentials, e.g. api tokens. And then build your logic in a way that it isn't possible to perform those tampering actions.
Validate on server-side that the request is valid (why would anyone be able to simply increase the money by hitting an endpoint, they should do e.g. a quest and your server validates that it was successfully done and rewards the money).
I want to know if There Is a solution to send an email on a Code Name One app using Gmail Api,
i have an exception When i m using javaxmail,
error: cannot find symbol
import java.util.Properties;
symbol: class Properties
thanks in Advance.
You can use Display.sendMessage to send an email in Codename One. However, this is an "interactive" API that will launch the users email client and he'll need to press send to perform the actual emailing.
Alternatively you can use the sendgrid cn1lib to send an email via sendgrid. I would recommend against that though. If you send an email from the device that means your credentials (password etc.) would be on the device. A better way would be to contact your backend server and ask it to send the email for you. That way a hacker can't decompile your app and find out your credentials.
I agree with Shai's response, I'd just like to add a few more thoughts.
Sending emails from a mobile application (regardless of whether it is developed with Codename One) has two major problems:
the first problem, as mentioned by Shai, concerns the credentials: putting your Gmail account inside the client app code is a very bad idea;
the second problem is specifically about Gmail, since you're not referring to a generic mail service, but to Gmail itself: Stack Overflow is not the place to make recommendations on which services to use, however I can tell you why Gmail is probably not what you want to use. The main problem is that Gmail, when used for "third-party apps" (which Gmail considers insecure), doesn't allow you to change IP addresses frequently: if it notices an IP change, it blocks the service and forces you to manually unblock it in the security settings. Obviously the problem is minor if Gmail is contacted by your server that has a static IP address, but it becomes a big problem if Gmail is contacted directly from your users' phones, each of which will have a different IP.
That said, if your app made with Codename One needs to send emails (e.g. to activate new users), I recommend:
your app can use Codename One's Rest class to make a REST call to your RESTful server backend;
in your server, you could use an alternative service to Gmail that doesn't give problems if you change the server IP address every now and then or if you use the server both locally and remotely. For what is my experience, I can tell you that on my Spring Boot server I use org.springframework.mail.javamail.JavaMailSender, which is compatible with various mail services (just for information, I use a free ZohoMail account, however there may be many other alternative and equally valid mail services that I do not know).
As for using Codename One's Rest class, I'll point you to the developer guide (https://www.codenameone.com/developer-guide.html#_rest_api) and to this blog posts: https://www.codenameone.com/blog/terse-rest-api.html and https://www.codenameone.com/blog/new-rest-calls.html
When making Rest calls with Codename One, always keep in mind that there may be no Internet connection or other connectivity issues (or server-side errors), so careful handling of possible errors is critical.
I need to allow a user of my App to email themselves when an even occurs. I am not sure how to do this.
My first idea is to create a dummy gmail account, and have my App sign-in and send from there via java code. This means hardcoding the password BUT as account not used for anything other than one way emailing - it does not seem to be a problem.
However, I understand that google is pretty proactive about security and if my App (which is global) tries to log into same account in several different countries during a 24 hour period - it will block the email.
I have seen the "delegate" functionality, but that would mean that each user needs their own gmail account which is not practical.
Is there a way to force gmail to allow the sign-ins to happen from wherever?
Or is there a better approach to this problem?
probably not a good idea to have your app to mail from a private account, if I understand you correctly. Best to use email service like http://expresspigeon.com or http://sendgrid.com and simply send a transactional email from your app account. In other words, use an ESP.
The safest would be to ask the user for all the configuration information necessary to access their email server as themself, then send the email as themself to themself. You can use JavaMail to send the message, but you'll need to ask for all the configuration information that any other email application would ask for in order to configure access to their mail server.
There may also be Android-specific ways to do this using the default email application.
I want to build an app whose core functionality is essentially the same as Pinger and other free SMS apps - that is, it needs to allow for texting without going through your phone's service provider by sending the data over the web. But I can't find any APIs or explanations as to how this is accomplished.
Pinger assigns you a phone number to use, which I assume means it must also run its own SMS gateways. But I don't know how to do either of these things (assign valid phone number and create SMS gateways), or whether I can even do them on my own and purely programatically. Does anybody know where I can find this information?
TL;DR: Essentially, I need to know how to create my own Pinger/free SMS app. My app will be different, but will employ the same underlying functionality.
SMS messages are not free to send and this is why Pinger's business model is based on advertising when you send and receive their messages, see http://www.pinger.com/content/advertise.html
In order to do this yourself you would need to work with one of the companies that offers a SMS gateway. You could use a whole bunch of different providers, take a look at this post I previously made with some of them How to send SMS programatically in a professional and reliable way?
I also add, you would need to work out a suitable business model to pay for the SMS messages you plan to send :-).
I have seen a disturbing trend where websites are starting to require verification sent to cellphones by text message (SMS). Gmail and Facebook are two of them. What I want to know are the following:
Is it a good idea to start requiring cellphones instead of emails now?
How do I do it on my own website?
Edit
Here are some of my new questions on the topic in response to the answers:
I see that most of you are saying that SMS registrations is ok. But what about the people who don't have cell phones? And why is it accepted to give out your cell phone information freely?
Do those big providers really pay per message to a gateway service? Is it not possible to set up a server with the correct SMS software, or at least buy a subscription directly instead of having a middleman?
Most SMS Gateway services have some kind of API. An HTTP interface seems to be the norm.
Just make sure you sign up for a service that allows receiving of messages because not all do. It's more work for them since they have to send some kind of data back to you.
Some services offer send receipts too which lets you see if the receiver got the SMS.
Some examples follows.
Esendex API docs
TxtLocal
In regard to question number one, I think Commander Keen's advice is sound.
It is a good idea if you want to limit the number of fake accounts. I see it used lots in local newspapers here in Norway. I guess it makes people think twice before posting useless crap on their discussion forums.
But do you really hate your users that much? Gmail and Facebook are big enough now that people will accept jumping a few hurdles to use the service, but you need something really interesting to make the user accept this inconvenience.
SMS is the reason I can't use App Engine ().
The first problem is that some people do not have cell phone. I can use Facebook almost completely without validating cell, but uses CAPTCHA to get through certain actions. Therefore, CAPTCHA is one of the good alternatives.
I personally think, cell phone stuff belongs to cell phones and should not be in the Web.
What if every forum admins and newbie PHP developers in the world used SMS validation and someone hacked (cracked) into their database? Do you trust a small forum? Is anti-fraud measure required so desperately?
If your site is very large and popular, it may be good to get SMS validation.
As a member of CS Networks Support team. I am going to give you some answers.
People use their cell phones as a medium of verification, so the service providers can be sure that registered member is not a bot or something else.
Yes it is true. Big providers pay for SMS gateway services. Yes it is possible to have an infrastructure like that, but it is recommended that you have a team of people that are in this business for a long period of time.
The one main reason for using SMS as a way of authentication is that you link the account to a mobile phone, which effectively reduces the chance of fake user accounts by a very large margin.
To implement this feature, you will need to sign an agreement with a SMS Gateway that has coverage for the countries (and operators) that your customers are located in..
Most SMS Gateways can easily be integrated in your software, and will most often provide you with access to all the mobile operators that you require.
I would not recommend using an email to sms gateway if you can use an API, as these are most often less responsive than using a proper API to send messages, where you will get a live connection with the SMS gateway itself, not an email server in front of the gateway.
Examples of SMS Gateway providers:
PSWinCom - www.pswin.com (Note: I am employed in this company.)
Clickatell - www.clickatell.com
HSL - http://www.hslsms.com/
Answer to 1st question: One reason which I can think of that led Gmail and Facebook to follow this trend is the emergence of bogus accounts. Now-a-days, there are use-n-throw email availabe for free like www.10minutemail.com which gives u an email address for 10 minutes. So the use can take such an email address and start a new account in the site.
But in the case of 'sms'-registration, I dont know of any such use-n-throw service provider. So everyone needs to give his own number for registration. This leads to registration by legitimate users.
Answer to 2nd question: This depends on which language u are using. Moreover, you may need a SMS gateway to achieve this.
Since you dont care about the language, try to look for SMS gateway for sending sms through computer or your web server. Some of the cellphone network providers provide an email service to send sms to a phone. For example, you are sending an sms to +910123456789 of 'xyz' network provider, you just need send the sms in the body of an email with the to-address as +910123456789#xyzmail.com
'xyzmail' part of the mail address will change according to the network provider. Plus this option is not found to be reliabe.
check out TeleSign.com
they offer phone verification solutions that you can implement into your website
phone verification is a way to reduce fraud and spam significantly
There's a trust issue here that goes both ways. If you're the provider of a service that can be spammed, you can trust that your users are people and that their email addresses are legitimate. This is probably irrational. Or you can force your users to trust that you'll deal with their cell number information safely. Many users will feel this is irrational.
And then there are people without cell phones (I happen to be one). Most discussions on the web aren't very important, but if you're trying to foster a discussion on anything important, limiting the discussion to people that have cell phones and know how to receive text messages will limit your discussion to the viewpoints of the rich and technologically savvy. If you're providing an important service like email, a texting requirement sets up a barrier to entry and saps the democratizing power of the web. It amounts to shunting the cost of your spam problem onto the disadvantaged. To me, that's unacceptable. Again, though, if your site is just inane pop culture or a marketing exercise, as most are, who cares, go right ahead.