All I'm looking to do is invoke a chat with a predefined message. The following URL does exactly what I'm looking for but it does not appear I can pass in a predefined message. Is there?
https://m.me.com/<USER_ID>
Is there a different URL or API that I can use to invoke a FB message?
Elaborating on the comments to this effect, Facebook's developer guidelines under the sub-heading 2. Give people control explicitly disallow pre-filling of content:
Don’t prefill any content in captions, comments, messages or the user message parameter of posts unless (a) it is a single hashtag in a post shared through our Share Dialog (but not via our APIs), (b) it was created by the person using your app, or (c) it was created by a business whose employees use your app to administer the business’s presence on Facebook.
In the case that you do satisfy one of the above conditions, I believe the solution may be to use a m.me link, although I am not at all certain how to go about crafting the USER_DEFINED_PAYLOAD in a useful manner. This question may provide more useful information for the specifics of implementation, but the consensus in answers is that even in the 3 cases where it is allowed to pre-fill, such a model is explicitly discouraged by Facebook. (This likely explains why they do not appear to document how to do this, and few if any good answers exist online).
Related
I have read a few questions on here about e-mail clients prefetching URLs in e-mails. An answer to this seems to be to add a new confirmation page, where the user has to click a button to confirm the desired action.
But, this answer states the following:
As of Feb 2017 Outlook (https://outlook.live.com/) scans emails
arriving in your inbox and it sends all found URLs to Bing, to be
indexed by Bing crawler.
This effectively makes all one-time use links like
login/pass-reset/etc useless.
(Users of my service were complaining that one-time login links don't
work for some of them and it appeared that BingPreview/1.0b is hitting
the URL before the user even opens the inbox)
Drupal seems to be experiencing the same problem:
https://www.drupal.org/node/2828034
My major concern is with this statement:
As of Feb 2017 Outlook (https://outlook.live.com/) scans emails
arriving in your inbox and it sends all found URLs to Bing, to be
indexed by Bing crawler.
If this is the case, any URL in an e-mail meant to confirm an action, e.g. confirming a login, subscription, or unsubscription, can end up searchable in a search engine, if that's whats meant by indexed in the quote above. In this case, it's Bing. Not even a dedicated confirmation page where the user confirms the desired action truly mitigates this.
Scenario #1
If I email the user a login link with a one-time token in the URL, that URL will end up in Bing. This token will have a short lifetime, lets say 5 minutes, so I doubt anyone will manage to search on Bing and find the URL before the user clicks it or it expires.
Scenario #2
The user gets an e-mail with a link to confirm a subscription. This link is perhaps valid for 24 hours. This might(?) be long enough for someone else to stumble over the link on a search engine and accidentally (or on purpose) confirm the subscription on behalf of the user.
Scenario #2 is not uncommon, it's even best practice to use double opt-in as far as I am aware.
Scenario #3
Unsubscribe URLs in the bottom of newsletters. Maybe valid for forever? You don't want this publicly searchable in an search engine.
Assume all the one-time confirmation links land on a confirmation page where the user confirms the desired action.
Is it truly the issue that URLs in e-mails are indexed by search engines, at least Bing? And will they actually end up publicly searchable? If not, what is meant by indexed in the quote above?
I'll add for the sake of completion that I don't think I've had much of a problem with this in my own use of the web, so my gut feeling is that this is unlikely the case.
Is it truly the issue that URLs in e-mails are indexed by search engines, at least Bing?
I can't definitely say if they are being indexed or not, only Bing could answer this question, but they are surely being visited, at least with a simple GET request. I just tested this sending myself a link to a page on my website that logs the requests that are made against it, and indeed I'm seeing a GET coming from 207.46.13.181 (reverse DNS says msnbot-207-46-13-181.search.msn.com), which suggests that an automated program from search.msn.com is crawling the link. This leads me to believe that yes, they are trying to index the link's content somehow, but it's only my opinion really.
And will they actually end up publicly searchable? If not, what is meant by "indexed" in the quote above?
Well, again, impossible to say unless you work for Bing. In any case, "indexing" means exactly what you think it does: parsing the content of a page to potentially include it in search results.
The real question here is: does this somehow represent a security problem or will it compromise my website's functionality?
It surely has the potential to: if your confirmation/reset/subscription/whatever process only relies on a single GET request with the appropriate GET parameter, then you should definitely revisit the strategy, as it obviously allows anyone to perform the action (even maliciously for example enumerating possible IDs for your GET parameters).
If the link you are trying to send contains sensible information or can be used to alter important data for an user of your website, then you should at least put it behind a login page only giving access to the interested user. This way, anyone who wants to access it (including search engines) will be redirected to a login page if not already logged in.
If the link you are trying to send is just some kind of harmless confirmation link (e.g. subscribe/unsubscribe from a newsletter), then at least use a form inside the web page to do the actual confirmation through a POST request (possibly also using a CSRF token), otherwise you will unequivocally end up with false positives.
I am currently building a site for a University study that aims to encourage a select few young people (peer supporters) to share messages around health and wellbeing in a private Facebook group.
I have used the Feed/Share dialog to share relevant links/images, however there are a few bits of content that are just pure text. I am aware that Facebook allows to post a status to a group using the Graph API, however you are not allowed to pre-fill what a user is going to say.
Would it be possible to have the ability to generate the content in a text box allowing the users to edit it as they wish before posting to the group or is this still prohibited?
...allowing the users to edit it as they wish...
No, that is not allowed, it´s prefilling. You would only be allowed to present an EMPTY textbox, where users can write the message. The message always must be 100% user generated.
Just signed up a third party email marketing provider, when I provide the template they give me a small tag to place which they subsitute with a user specific unsubscribe link.
My concern is that the link is single click, there is no subsequent confirmation, etc.. and whilst I am all for easy removal, I worry that any combination of malware scanners, AV engines, spam scanners will follow the link and thus unsubscribe many legitmate users.
Is this the norm to have a single HTTP GET request unsubscribe a user?
How are other developers handling this issue?
Note: The provider in question is critsend
Interesting question. It’s not the norm. But it’s common with cautious email service providers. For example, MailChimp also has a 1-click unsubscribe for his freemium users. I’m not a big fan of that, too. (I’d prefer a prefilled form field, where the user confirms his wish to unsubscribe by clicking "submit".) However, I didn’t witness any problems using 1-click-unsub until now.
FYI, here’s a discussion addressing a similar topic (false positive double opt-in confirmations). You might also want to check out this article and this discussion (forum registration required).
The norm is once clicked, it goes to a form which you click a button to confirm removal. That's strange there are even single clicks avaliable
Any side effect changing HTTP GET request is non-conforming as far as HTTP is concerned. In particular, see this from RFC 2616, section 9.1.1:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
It would be more standard to put the actual unsubscribe behind a form submission to cause a POST.
I know Campaign Monitor has built in procedures to catch non-user unsubscribes. Not sure about critsend.
Jeff Lindsay, who coined the term 'webhook', said that the difference between webhook and http callback is that webhooks are user-defined. I think I understand what he meant, but I was thinking about it and I asked myself, can webhooks be effectively used by regular users (I mean: non-developers)?
Usually people don't have a clue how the internet works, they don't know what http is, terms like URL, callback, or request-response don't say anything to them. I've heard that many people do not know the difference between a web browser and a web site, they think that internet really starts at google.com and they type in all urls in the google search box... I mean, what's the use of webhooks when you're not a developer?
Do you think services like AlertGrid make sense? It's a webhook consumer that you can configure to dispatch alerts (SMS, phone, email) either when the callback is NOT received in x amount of time, or when the received data meets user-defined condition, plus it does some data visualization. We wanted it to make webhooks usable for non-developers. But still it requires an initial integration by someone who at least knows how to configure the source to send the webhook events. In many cases it only takes pasting an url to a textbox, but it seems to be beyond the skills of a typical user.
So, are the webhook doomed to be used by software developers only, or is there a chance that millions of Facebook or Twitter users will start making use of them somehow?
I think that something implemented using Webhooks can be made very user friendly.
Suppose Stack Exchange allowed users to define a webhook that would be notified whenever you earned a badge. You could supply a custom URL, or there could be simple buttons to click that would set it up for your Facebook or Twitter account. It could be as simple as the Facebook Like button.
YES I think this is a great idea. It's actually something I designed in my head a couple months ago and didn't think the product existed.
Webhooks are extremely powerful and having a 'service bus' aggregate/manage/dispatch these callbacks is extremely compelling to me.
I think that we are a long way from the general public consuming webhooks in any sort of meaningful way but I don't see why not. I remember when RSS was a 'developer' only technology.
Thanks for the link. I'll be digging in more this weekend.
I hope this is allowed but I have a number of questions regarding Facebook Connect, I'm quite unsure on how I should approach implementing it.
I am working on a live music type service and currently have user registration, etc. If I were to implement Facebook Connect alongside this, would I still be able to email the Facebook Connect users as if they were on my database?
Also, would it instead be possible to let users who have Facebook "link" their accounts once registered so I am able to give them the benefits of sharing via Facebook and inviting friends while still having an actual registered user on my system.
I have tried to read up answers to the above questions but what I've found is quite ambiguous.
Thanks, look forward to your views.
Facebook's documentation process is very poor, so don't feel bad about having a hard time getting started. Their wiki-style approach to documentation without any real official documents tends to leave the "process flow" tough to grasp, and requires piecing together parts of a bunch of randomly scattered docs.
Facebook has an obligation to protect privacy, so they never make a user's actual email address available to application developers, through Connect or normal applications. They do have a proxied email system in place that you can use, however, you must get explicit permission from a user in order to email them. There's a decent document on proxied email here. You can get permission by prompting for it; there's several methods for doing so linked in that document.
In regards to linking Facebook and local accounts, this would definitely be the way to go. Once a Connect user logs in, you want to store that fact for that user so you can provide the Facebook-specific functionality. I would simply create a normal user account in the database for every new Connect user that came by, with it's own local id, so that you don't have to do special handling of two different types of user accounts all over the site. That being said, the account would obviously have to be marked as a Facebook user's account (I use an externalId column in my users table), and any part of the site that relied on information you might otherwise have locally would have to handle the Facebook aspect properly (such as using proxied email instead of normal email).
For existing users, you could arrange an "account link" by having a process whereby they log into FB Connect after they've logged into the site already, and you could detect that and simply add their FB id to your users table. After that, they could log in through Connect in the future, or through your normal process. I've never done this, but it should be possible.
If you write the account handling code generically enough, your site will be able to function well no matter what kind of user you throw at it.