I came from a similar state in this question.
My objective is to reply to interested customers via whatsapp messages. I'll use a very special setup, so I'll be using the API.
Reasons:
With not to pay anyone other than container hosts
Solution with custom API
Customer doesn't like any extra costs
Just like user noboundaries, I see the numbers, but I cant get the certificate
User Navjot Singh has explained I need to create a "business api account"
I tried just that, put out all my contacts and stuff, in this site.
They did respond yes, but only with pointless instructions, since I wish not to contract any messaging providers. I had taken a look at it, but they charge a very expensive price beyond the $0.005 whatsapp will charge. Also, the solution I'm creating requires messages to be sent programatically, and the partners don't seem to provide the correct solution.
So, I wish to skip into using the api. I followed the appropriate guides:
Getting started
Phone Number
I already got some things done:
two phone numbers (one of them for testing) with whatsapp business;
company has been verified, with domain
have business management account
local environment with docker
I can access the local environment and I have set an user account and the admin acount. I can log into those via the API, since postman can ignore certificates, but in order to proceed I really feel like I need that certificate.
So to sim up I guess I need help creating the whatsapp business account for my customer. Any advice?
Also i'd appreciate any other helpful insight or feedback. I really feel lost and I don't see a place where I can talk to people trying to do the same thing, or doing this is much of a madness after all?
thanks for getting to read until here, and I apologize for my non natural, almost broken English.
Hi I wanted to start big in stackOverflow but I fell flat.
About the subject at hand, westerday I dwelt deep into the rabbit hole.
For most companies, you actually are forced to work with a provider, such as twllio or messagebird. They act as intermediary between the facebook business and the whatsapp business api.
Some of they offer messaging separated from whatsapp api setup I still need to take a look into it, but for those who are trying to set up whatsapp business api on their one, it seems as of november 2020 it's not possible.
please check out:
respond.io's guide
blog post from take.net PT-BR (google translate didn't like me trying to translate this to English)
In Mandrill, if you create a new API key and do not limit its API calls, whoever you give that key to can use it to log into the web interface with full access - billing information, account information, the works.
After playing around, it looks like you can disable the web interface login functionality by ticking "Only Allow This Key To Use Certain API Calls" and then selecting at least one API call. Doesn't matter which one.
So I can give full access to the account, or completely disable their ability to log in. Is there any way to customize this further? I would like to be able to limit users to the outbound/inbound UI, or at least prevent them from having the ability to charge many thousands of dollars to the attached credit card. For clarification, my use case is to distribute API keys to contractors or vendors so that all email gets sent through a single account.
I have found very little official Mandrill documentation on this. The only thing that seemed relevant is that if you have a Mailchimp account, you can instead send users there and use the "View Mandrill Reports" functionality. I don't have Mailchimp (nor do I need it), so this seems like an unnecessary hacky workaround.
Different levels of access, other than limiting API calls for API keys isn't currently possible as described in the Mandrill KB here. If someone has access to the web interface, they have access to the account as a whole. This may, of course, change in the future, and would be documented on the blog and in the KB.
I believe you could also restrict access to the web interface by setting up two-factor authentication?
I'm able to setup sugarcrm to my local machine. Also I've a bit of knowledge of studio. Now I've got a requirement like login to sugarcrm using google account. If user want to login to sugar he/she'll have to use his/her google credential. If the credential is correct and the email id matches with the email id for a user in user module, the he'll be able to login to sugar.
I'm pretty new to sugar so please provide help. Please write if the problem description is not clear to you.
Thanks
It sounds like your goal is to enable Google Authentication within SugarCRM, which would mean a rewrite of the entire login page and process. I think that's beyond the scope of a SO post, but I think you'd start here: https://code.google.com/p/google-authenticator/
SugarCRM does come equipped with the Zend Library, including a lot of classes for working with Google APIs, so that's a plus.
A simpler answer, if it meets requirements, is to set the Users' user_names to their google email addresses, either #gmail.com or #googleappdomain.com, whatever. The draw back here is that the accounts aren't actually linked with Google, so passwords won't stay in sync.
I have built a Custom B2B app for one of our clients. My question is how to automate the distribution of the redemption codes.
I have already looked at some of the MDM providers. Their solutions are too expensive and all we really need is a way to distribute the app from a webserver, not manage a bunch of mobile devices.
As you probably already know, when a client buys a Custom B2B app through the Apple VPP program, they get a spreadsheet with valid redemption codes for the number of licenses they have built. This spreadsheet has 2 columns: 1) redemption code 2) URL to redeem the code
I want to provide my client with a URL where they can send their users to download the app. They just don't have the expertise/infrastructure to distribute the app themselves. And emailing clients is not going to work.
I'm not a web guy, but it seems to me that we could write a webpage that would look at the spreadsheet for the next available activation code and then redirect the user to the associated URL. I'm not concerned with the number of licenses they distribute since I have another way of auditing the real number of users (Flurry). So I want this to be as painless as possible.
In fact, I have multiple clients and want to provide them each with their own URL for their clients. It seems like this shouldn't be too difficult to code.
The problem is, I'm not the guy to write that code. Any ideas on how best to do this?
Assuming that you don't want to show the user a website you should be able to do this with an online service like parse.com and the features it offers.
From a user POV you would supply them with a link which directed them to parse.com with a path and parameters indicating the action to be taken (get app) and what account is associated. This would redirect the users browser to the appropriate destination.
The main issue (and this applies to any solution) is knowing if the user actually followed through and used the code. i.e. should it be removed from the DB so it isn't offered to another user in future. Then you would update the DB each time you get a new spreadsheet.
Anyway, this could be achieved with a little javascript in parse.com, specifically, by using cloud code which can interrogate and modify the DB and then redirect the user.
Obviously if you need user authentication of some kind or other restrictions then you would need to start adding some web interface on top of this in order to collect the details.
We want to streamline the user registration and login process. The goal is to reduce the time and effort for users to register and login to our site.
At the same time, we don't want to overwhelm users with choices. We don't like how some web sites present registration/login options via multiple channels (e.g., Facebook, Twitter).
What are the pros/cons of each of these systems? Which do you use, and what are your main gripes?
Offer all of them, don't take the time to ask "why?".
It's always worth it to get users on board.
The biggest (IMO) pro is that you are no longer storing passwords in your db. Leveraging one of those other site's authentication service relieves you of this. It doesn't relieve you of having a secure design. I'm also not sure that your average end user really cares. If your service is highly aligned with one of those services, maybe. However, if you are not targetting those end-users, then probably not.
Rob Conery did a recent write up of his experience with OpenId. This might be a good read:
http://blog.wekeroad.com/thoughts/open-id-is-a-party-that-happened
Hope this helps.
Bob
Well, yes, it does all depend on your user audience.
In any case, I would say that Facebook Connect is probably your best bet due to the sheer number of people using Facebook. Still, as far as I've noticed, it's not really "professional" websites that use Facebook Connect, mostly forums and unofficial (but popular) news blogs.
Many "professional" websites (catering to... well, professionals) will use a normal Register/Login rather than Twitter, Facebook, or OpenID. Still, a professional website would likely need a more professional solution, so I would suggest OpenID, which also supports websites such as Yahoo! Mail and developer communities (such as Stack Overflow!). You can see the full list of sites here.
In all honesty, I don't really think that using a Twitter login would be very efficient. Think of it this way: for one, I've noticed (but I could be wrong) that Twitter is mainly used by the small hobbyist or the people who use it to give updates on things they're doing or making (and sometimes just the people who want to be in on the times). So unless your website is aimed at these type of people, it wouldn't really be useful. On top of that, I don't know of many people who particularly like it, partially because of its over-popularity. Still, it could be the same way with Facebook, but this is all subjective, so if you really want to pick Twitter, go for it.
Anyway, that's my take on things. I don't personally use these systems on websites I've built, but I know how they work.
For one, when you log in using any of these for the first time, they take the user to a new page or open a popup window asking them to confirm if they want to connect their [Whatever] account to your [Website Name]. After that, it's a bit easier to use just because they don't have to keep repeating the process unless they disallow your website on their service.
With OpenID, you have to log in to your OpenID-enabled webpage using http://myusername.myopenid.com/ or myusername.myopenid.com. If they don't choose to remember their password, this can become a bit tedious to type in every time.
With Facebook Connect, it usually automatically connects all of their information to the website, including full name and profile picture (meaning that if they have a profile picture of that snazzy tattoo on their inner thigh, other users will be able to see that).
Finally, as far as I can see, Twitter doesn't do much other than connect whatever name you had on your profile page (if it's "John Doe" or "Weiner Schnitzel", it'll show on your website) and your profile picture, just like Facebook.
To finish up, those are pretty much all the pros and cons that I can tell about the services. Good luck!
What is your target group?
If you want that many normal people uses your application than use Facebook.
If there are many coder / blogger / internet junkies than use Twitter.
If you have a lot of open source guys than OpenID will do the job.
If i'm is not wrong, previously there is a website providing kinda service about providing login platform to allow user connect to your site. Of course it is not free and i was abandon it because of high annual fees and mind change after research being done.
While you using their service to growing your business or website, you can save their time it's true. but honestly, will they really care on how long time taken to connect their facebook with your website either register as a new member in your website. While you can give confidence to you client, they do. they willing to spent few minute to fill up simple information to make an account for them self if they felt they worth to spent the minute to get service from your website.
Totally agreed to what rcravens said, if they connect through third party website, means you are gonna giving you user information to that website. For example, to archive FACEBOOK CONNECT you will need to create an application for them to trust them you only can get authority to access. while they accept and login to your site, it is good for FREE advertise because while they connect, can use their account as medium to post your information to public. BUT mostly site will sell their information gather or share them in any way to some organization who need them for decision.
My point is, how many people using your site and mostly who is using, what characteristic of your site user and so on... everything is no more under your control !!!
Perhaps, you may use it but what if their service shut down few hour for maintainance...
I'd recommend using something like RPXNow (https://rpxnow.com/) or Gigya (http://www.gigya.com/) as an intermediary to the various authentication providers. Facebook and Twitter are notorious for always changing their APIs. It is a pain to keep up with them. These services give you a simple abstraction layer, so that you don't need to change anything on your end when the providers change their APIs.
i like facebook but..
facebook is block in some country.
open id is not famous.
twitter is famous and simple.
so use twitter is the best :)
Use OpenID as it is a standard that is also integrated into many Mail Accounts, like Google or Yahoo. You never know how long Facebook will stay around and therefore it's better to have something people just don't throw away (there Mail address). If you make a nice selection screen (e.g. stackoverflow), the people don't even know that they're using OpenID. If you just want to get authorized Comments, picture uploads for twitter or fb, a game connected with social features don't use it.
Facebook Connect is very usable for one time comments or stuff like this. If you want to store your own data about the user (e.g. blog service, saas), not dependend on "social networks" don't use it.
Twitter Login makes only sense if you connect your service with Twitter, otherwise forget about it.
I would use a hidden OpenID approach.
Facebook is great for keeping tabs on family and friends. Beyond that I, personally, wouldn't use it in support of any other app. It's just not bullet-proof enough from a security/malware standpoint. There is too great a chance someone could have issues of that sort with Facebook and attribute it to your site, whether reasonably so or not.
I like OpenID. Not thrilled with the notion of hitching my wagon to any of the social networking sites/services at all.
Is this a technical or commercial question?
The answer to my mind is it depends what you want to do with the data.
If you just want to provide a service to a broad list of people then the answer has to be to gun for openness, not proprietary - particularly since the open standard is supported elsewhere, Gmail, Yahoo et al.
However, if you want to demographically profile that database at some point to offer targeted services, then you need to understand the questions you're likely to require answered and whether a third party method is going to enable that or not.