Since a few days I develop a chatbot for Whatsapp using Dialogflow, Twilio and Heroku to host my NodeJS server. I only use free services.
What I want to do is to return a gif to a user. For example, the user sends a keyword and the chatbot returns a random gif from that word. In reading the documentation I found, I can't find the appropriate part of the JSON where I must insert the url of the gif to send.
I would like to know how to do it or maybe it is not possible with the services I use ?
PS : Sorry for my English
It's always better to tell what all things you have tried before posting the question so it makes answering the question better and precise.
Anyway you can do that by using Fulfillment. Just enable the Fulfillment in the Intent in which you want to send the image. Then go to Fulfillment on the left-menu and enable Inline Editor (you will need to add a billing account). Write the code for sending the image there.
Related
I'm using the url as below to request the Google Maps API, and getting Developer purpose only in output. https://www.google.com/jsapi?sensor=true&libraries=places&key=**********&client=*******
Can anyone help me what is wrong with the request format. Should I use url like this: https://maps.googleapis.com/maps/api/js?sensor=true&libraries=places&key=***********&client=*********
Tried both the urls in the request but getting development purpose only watermark on maps.
Map in the web application without any watermark.
The problem here is you are both using the "key" parameter for API key and "client" parameter for client ID. You should only choose one type of authentication. Using both will lead to an error, just like what you are experiencing right now.
This is the correct way to load Javascript API key:
You can learn more here.
If you have a Premium Plan license and wish to use your client instead:
This Detailed guide for Premium Plan customers will be a big help to you.
Also, you don't need to the "sensor" parameter anymore.
Hope my answer helps!
I've got an android and iphone app that both get the required data from a webserver. The data is sent via json to the client. Using this setup other people might simply retrieve the url the app is calling and this way could make use of the data that I gather with my scripts on the server. To make it short: I don't want that :)
My idea is to make the json unreadable for example by encrypting it. This would make it a little harder to retrieve the information since this way some who would like to use my service would had to decompile the app an lookup any decryption stuff I had implemented.
Therefore two questions:
Do there exist some libraries that already offer such a functionality (Server side is Java)?
Does anyone of you have any other suggestions how I could protect my api from unwanted guests?
Thanks in advance :)
I think the options available would be...
to lock down the API to Authorized/Authenticated users.
Using BSON to obfuscate the data.
You could always use oAuth to allow the users to authenticate based on an account they already have: Facebook, Twitter, Google etc.
Looking at: http://developers.box.com/get-started/#authenticating on step #2 I'm trying to use curl to enter the credentials (user/email/password) to get the auth_token. I'd rather do it this way instead of directing the user to their browser because I'm making a script for syncing.
Anyone have an idea how I can do this? can I just do a POST with curl? I'm using v2 of the API.
You must send the user through the web page, unfortunately. However, since you are writing a script, you should also be aware that auth_tokens under the current system, so you can manually retrieve one and include it in your script.
Just one thing to note. If you don't use the standard authentication flow that goes through the Box web ui, then Box's large customers that have all their users sign-on with SSO (Active Directory and similar) logins, won't be your customers.
So, basically, if you want your app to be picked up by enterprise-level customers, then follow the building guidelines that Box provides.
I am looking at creating a good google chrome extension for tumblr.
Now tumblr uses Oauth as it's authentication method.
So my question becomes.
Do I:
Distribute a single key with the application and hope people are nice enough to not use it for illegitimate purposes.
Put in the options the ability for a user to enter their own key, hence asking each user to register an application.
Create an intermediary on my server that makes the actual request.
Something else?
I also had to consider this for my Template extension when using OAuth to communicate with the goo.gl URL shortener service on the user's behalf.
After reading Chrome's OAuth tutorial I managed to implement this simply using the following;
ChromeExOAuth.initBackgroundPage({
access_url: 'https://www.google.com/accounts/OAuthGetAccessToken',
app_name: chrome.i18n.getMessage('app_name'),
authorize_url: 'https://www.google.com/accounts/OAuthAuthorizeToken',
consumer_key: 'anonymous',
consumer_secret: 'anonymous',
request_url: 'https://www.google.com/accounts/OAuthGetRequestToken',
scope: 'https://www.googleapis.com/auth/urlshortener'
});
This is surrounded by quite a bit of logic due to the complexity of the extension but this results in the user simply being shown a page (on a new tab) the first time they attempt to shorten a URL using my goo.gl implementation. Here the user can decide to allow/deny the authentication. Since this is only done once (unless the user later removes it from their list of authorized applications) I thought this was fine and my users seem to agree.
I did also provide an option to toggle OAuth on/off but I'm guessing this will always be required for the tumblr API. On that note I must admit I'm not familiar with that particular API so I'm afraid I can't help you further.
I am an android application developer (trying to be one) and I want to learn how to communicate with web sites from my applications. However, I don't know where to start. Can you point me in the right direction?
PS : I believe "web communcation standarts" is wrong term but i don't know how to call them.
I'd suggest that you learn by doing. Pick an idea - let's say you want to upload a picture from your Android phone to facebook.
Now go and research how to do that. Facebook exposes what they call the "Graph API" for all fb resources, including users, statuses, and photos, among other things. The Graph API is a REST API - in other words each item on the backend is modelled as a "resource" which is accessible from a URL. (Learn more about REST on wikipedia). Send a GET HTTP message to the given URL and you can get information on the resource. Send a POST to the container of that resource, and you can add another of whatever it is. In this model, to add a photo, you POST to the album URL. Read on FB for how to do that. They call it "publishing".
But reading that doc page you learn that in order to POST you need an authorization token.
Your app needs publish_stream permissions. How do you get that? Keep reading in the FB doc and you'll see a link to the Authentication and authorization guide. That tells you about how to use OAuth 2.0 in Facebook apps.
Your app will send its first feeble message out, and get an error response. Why? You'll want to examine the message. so you google and figure out that you can use an http debugging proxy to help you, something like Fiddler2 for Windows, or Charles for other systems. So you download that, set the proxy on your Android device, and now you can view outgoing HTTP messages and their responses on your PC.
Keep plugging along, learning what you need to accomplish the task in front of you: in this example, posting a photo from an android device to Facebook.
After you reach that goal, you will have learned quite a bit of practical knowledge for this domain of problem. Then you can try a new goal, and work on that.
After a few iterations of this, you will have learned how to learn, which is even better than learning REST or OAuth. If you know how to learn, the sky's the limnit.
Learn about HTTP first. There is far more to HTTP than there first appears. It is a building block for everything on the web.
You will not go wrong by getting very familiar with this http://www.w3.org/Protocols/rfc2616/rfc2616.html