Back in the day Facebook used to let you define URLs that were something like http://facebook.com/send_a_message/user/55/pre_fill/Hi there. When you clicked that link Facebook would open up its Messenger with a "Hi there" message ready to be sent to user 55.
But then Facebook decided that "pre-filling" was bad, and outlawed it across all their APIs. Now there are a bunch of different ways to initiate a Messenger chat session, but they all amount to "start a chat with user 55", not "start a chat with user 55 using some information".
The thing is, I'd like to somehow pass information along with the link. For instance, I might want to have three different links on three different pages, and I want my chatbot to be able to respond differently based on which page the user came from. Since I can't "pre-fill" a message (eg. "Hello, I just came from page A"), I'm wondering if there is any other way to pass auxiliary information.
TLDR
I'm wondering if there's any way I can possibly provide a user with a link that, when they click it, starts up a chat session with my chatbot user, and somehow passes information to it. Using an intermediate proxy (ie. having the link go to my server, and then have my server start the chat somehow) would work, but only if I can associate the information with the user (ie. it doesn't help to know "page A" if I can't associate that with the user once they start chatting).
After researching further it would appear that the answer to my question is no: there is currently no way to pass-along supplemental information.
But here's the good news: when I filed a bug about this (which it turns out I should have filed as a feature request, sorry Facebook) I got a response saying something to the effect of "we couldn't tell you that we are currently developing this, even if we were", which I'm going to optimistically choose to interpret as a sign hope means that this functionality may be coming in the future.
Related
I'm currently working on a project that detects when someone is listening to a song on Spotify and sends a message to that person based upon that song being in a playlist.
I couldn't see a spotipy function to get this data, even though I can see it on the spotify application itself, any pointers?
Accessing friends' activity feed is something that many people have been requesting for a long time, however Spotify does not seem to have any plan to open it up unfortunately.
Currently, the only existing workaround I am aware of is to scrape the internal API used by the client, as is done here: https://github.com/valeriangalliat/spotify-buddylist
Another option for your project would be to use last.fm APIs if the user is on it and you know the handle -- which is less than ideal of course.
I'm designing a custom team tab using React that calls third party API, I need after executing the API successfully, user gets notified . What is the best way to achieve this? I used Bot in my project, but not sure how can I call it from my custom tab class. I'm aware of the existence of proactive messaging, is it the only way to do it? If it is, a pointer on how to implement it to a custom tab would be appreciated.
If you're wanting to message the user 1-1 (like in the personal app), then proactive messaging is definitely what you need (inside a Team, there are other options), and considering you have the bot already in place that's perfect. The only thing you might be missing are the details required to send the actual proactive message (the best time to get them is when the bot is first installed by the user). In particular, you need ConversationId and ServiceUrl.
With regards the concept of Proactive Messaging, basically once the bot is installed, and you have the required values, you can -send- the message from any backend code at all. That can include, for example, custom tab's backend api. You need to identify the user, which you can do using the Teams Context (it's not the safest way but it's the easiest), and then look up the values in your own backend store (e.g. database or whatever) to get the ConversationId and ServiceUrl, then just message the user in your backend.
I'm creating my first application that requires me to update the app based on user input. I've been searching for the best way to send input to me. For example, I have a button that when the user presses I would like to send me the information they've added to a text field. Being new to this, I thought this could be done by simply sending the information to a specified email, but from what I've researched I will need some sort of database. Looking through the Apple Developer Documentation I don't even know which topic I should be looking at to figure this out, any help or direction would be very helpful!
You need to setup a server (using an API) to receive the information.
Usually you will use a webservice to receive the info from the app, although there are other ways to do that.
Sending an email through iOs would require the user to accept the email that is being sent, so doesn't look like a good idea.
Take a look at some options available to create webservices (django rest framework or flask), Google's Firebase also can be handy in this situation, since is only integrating it with your app and storing the data you want to store, with easy integration for Authentication and user tracking.
Does anyone know if it's possible to return a different message etc to the chat user if it's the very first time they are interacting with the bot?
For instance, if a user says "hello" (or anything) for the very first time, the bot might respond with, "Hello there!"
If a user says hello some time later, the bot might respond with "Hello, again!"
Looking through the developer docs I'm struggling to find an answer: https://developers.facebook.com/docs/messenger-platform
For context, I'm also using the https://api.ai service.
One way to accomplish this is to set up a "get started" button:
https://developers.facebook.com/docs/messenger-platform/messenger-profile/get-started-button
This might also be helpful:
https://developers.facebook.com/docs/messenger-platform/messenger-profile/greeting-text
(But I haven't used it myself, so I'm not sure what it does.)
Also, as already mentioned, you can store user data in your own database, and send a greeting message if you can't find the user there already.
This would currently not be possible with API.ai out of the box, you'd have to build a custom webhook that would save the user id to database and check it on new session.
As a (very) hacky workaround you could try outputting a context after the first hello and each and every other intent you use inputs and outputs that context, essentially remembering the user has talked to the bot via a 'permanent' context.
I want to write a program that analyzes your fantasy baseball team and notifies you of recommended actions, possibly multiple times per day. The problem is, you aren't playing fantasy baseball on my site, you're playing on yahoo, or cbs, or espn, etc.
On the majority of these sites, fantasy teams and leagues are not public, so you must be logged in and a member of the league to see the teams in the league.
All that I need is the plain html for the team page on each of those sites to be sent to my server, where I can then parse and analyze the file and send user notifications.
The problem is that I need username/password combinations to easily get this data to my server when I need it, and I think there will be a lot of people who wouldn't want to entrust their yahoo/espn/cbs password to me.
I have come up with several possible ways to solve this problem:
The most obvious way is to ask for their credentials for the site on which their team is hosted. Then I could just programmatically log in and request the data I need. I'm guessing a number of people would be comfortable giving me their credentials, and a number of them not so much.
Write a desktop client, which the user then downloads. The client would require their credentials, but it could then basically do exactly the same thing that the server based version would do, log in, request the page, and send the page back to my server. The difference being that their password would never need to leave their desktop. Their computer would need to be on, and this program running for this method to work.
Write browser add-ons that navigate to the page I need, use the cookie that is saved from a previous login to login to the site, and send the page back to my server. This doesn't require my software to ever ask for their password, but if the cookie expires I am hosed, and I don't know much about browser add-ons besides.
I'm sure there are other options, but these are what I've come up with so far.
I have two questions:
1. What are the other possibilities for this type of task?
2. Am I over-estimating people's reluctance to give me their yahoo (for example) password? Is option (1) above the obvious choice?
It was suggested in the comments that I try yahoo pipes, and that looked like a promising suggestion so I explored it a bit. Having looked now at this, I don't think that is an option. So, it looks like I'll be going with option 1.
This is a problem I grappled with a couple of years ago when I wanted to do the same thing. Our site is http://benchcoach.com and the options we were considering were the following:
Original we considered getting the user's credentials and login. We would then log in and scrape their league and team info. The problem there is that after reading several of the various terms of service, this would definitely be violating the terms of service. On top of this, Yahoo! was definitely one of the sites we were considering and their users have email (where we could get access to sensitive data), and Yahoo! wallet. In addition, it would be pretty trivial for Yahoo/ESPN/CBS to block our programmatic logins by IP Address.
The solution we settled on (not 100% happy but it does seem to work) was asking our users to install a bookmarklet (like delicious, digg or reddit) which would post the current html page to our servers, where we could parse the data and load our database. If they were still logged into their Yahoo/ESPN/CBS account, we would direct them directly to the pages, otherwise, those sites would prompt for authentication. Clicking the bookmarklet once more, would post the page to our servers.
The pros of this approach was that we never collected anyone's credentials so any concern of security would have been alleviated. Secondly, it would make it impossible for Yahoo/ESPN/CBS to block access to our service since we would never be connecting directly to their servers but rather the user's browser would be posting the contents of their browser to our server.
The problems with this is that it takes 2 clicks to post a page to our site. For head to head leagues, we needed 3-4 pages so it would take our user 6-8 clicks to sync their league to our servers. We're still looking at options for this.
One important note is that I ran into the product manager of the Yahoo Fantasy Football site at a conference a year ago. We talked about how we were getting the Yahoo data, and he confirmed that getting credentials would violate their TOS and they may stop us. While I don't think they would have, it would have made it hard to invest time and energy to develop this only to have them block our site and pissing of users by closing their accounts.
A potentially more complicated answer could possibly be done with (for example) yahoo pipes.
Hypothetically, you create a pipe which prompts the user for their credentials and provides them with a url which contains their scraped data. They enter this URL in their site, and never have to provide their credentials directly. Even better, for the security-conscious, it would be possible to examine what the pipe was actually doing before entering any information.
The downside would be increased complexity (as well as you'd have to write and maintain the pipe). Having said that, you could provide a link directly to the published pipe from your site, to make things as easy as possible.
Option 1 is the obvious choice. People who trust your site will provide the details. There is no other way you can login to other site while screen scraping.