I have a 'Send to Messenger' button on my app. It use to work just fine earlier. But now it does not work on Safari on Mac & iOS.
It works on Chrome perfectly, but when clicked from Safari, Facebook is not sending event on my Webhook.
Screenshot below: On Safari I also get a specific page after user clicks on authentication " Tap to go back to URL".
Image where users click on send to messenger button
User is asked to Authenticate
Tap to go back to URL screenshot - Likely Culprit
Button Status shown approved, but in reality its not
The error message given to you is stating the issue:
The frame requesting access has a protocol of "https", the frame being accessed has a protocol of "http". Protocols must match.
When you use the Send To Messenger plugin there are some requirements for your own domain. See the documentation here. One if these is that you must whitelist your domain. It states:
Use a fully qualified domain name, such as https://www.messenger.com/. IP addresses and localhost are not supported for whitelisting.
You are serving your application using HTTP from http://alpha.lvh.me:3000 but you must serve it using HTTPS. It's also not clear from their requirements if you can use a port number or not but I think you'd be better looking at ngrok or localtunnel for local development.
[Edit] I think it's probably an issue with the content security policy (CSP) on Safari. Some reading about it here.
Related
I am trying to build an OSX application using swift and storyboard. I am implementing Google OAuth for the app. Following the google guide https://developers.google.com/identity/protocols/oauth2/native-app#sample-authorization-urls, I am opening a browser with the a loopback authorisation url (i.e. after signing in, it loopbacks to localhost where the url contains authorisation code and other meta data.
To give a better overview of how the authentication workflow works:
User selects authorise button in app
Browser opens up with an url like:
https://accounts.google.com/o/oauth2/v2/auth?
scope=email%20profile&
response_type=code&
state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
redirect_uri=http%3A//127.0.0.1%3A9004&
client_id=client_id
The google account chooser and permissions consent screen renders and prompts user to give permission..
Once user gives permission, the page redirects to localhost with the authorisation code or the error (when not permitted). The redirect url looks like:
http://127.0.0.1:9004/?code=auth_code&
scope=email%20profile%20openid%20https://www.googleapis.com/auth/userinfo.profile%20https://www.googleapis.com/auth/userinfo.email&
authuser=0&
prompt=consent
So now I want the parameter code in my app. Google document says I have to create an HTTP listener in order to get the parameters. So I want to setup an HTTP listener at that port (9004) and get the params. What HTTP library can I use to solve this problem?
I haven't tried to involve myself with any oauth library for osx and I want to implement myself but if there is a library which solves this problem with limited boilerplate suggest them.
Thanks.
I would recommend the AppAuth framework for macOS and iOS. It takes care of all of this for you, and includes an option to set up an HTTP server on the loopback interface.
Instagram API requires redirect uris to have an SSL certificate (HTTPS connection).
I use Instagram API for my mobile app, and OAuth response should first invoke procedure in the app.
I am able to create a server to catch this call locally (on 127.0.0.1), but for the certificate, I can only create a self-signed one. The problem is that the browsers don't trust it and initially warn the user about the potential hazards, which is unacceptable for the user experience.
I saw a few similar questions on Stackoverflow, but unfortunately, I couldn't understand if they solve my issue.
How to avoid this warning?
Basically, even if they warns about https you can use api's. I had the same issue but I just tried to run the application on https port instead of http on localhost and it worked. So, Answer is you just need to run your application on https.
I have a solution for my specific case; I use Flutter for the mobile application. But overall you can find something similar for other cases as well.
Initially, I was launching the Instagram authorization window with url_launcher package. Basically, for iOS it launches the url in-app, but in a Safari Web View. In this way I am unable to control the flow in this web view. So, what I wanted to do is to catch a request to 127.0.0.1 when authorization is completed by running a local server in the app. It does work but throws a warning about security hazard due to a self-signed certificate, since Instagram requires https being used and 127.0.0.1 cannot have a trusted certificate.
Instead, now I launch the Instagram authorization window in-app with custom WebView using webview_flutter. It provides more flexibility, but most importantly I can track navigation. So now, Instagram redirects my user to the non-existing page on my website, which has a trusted certificate (but it doesn't really matter), but the aforementioned WebView can detect this redirect, parse the URL to retrieve the wanted code and prevent actual redirection by closing this web view. So, eventually, I get the wanted code in the app, so I can send it to my backend with extra user id reference.
So, basically, the workflow looks like this:
User clicks a button in the app to connect Instagram account;
The app launches a custom web view and opens Instagram authorization page;
After authorization, Instagram redirects the user to a dummy URL with the wanted code as a query parameter;
The custom web view detects this redirection;
Retrieves the code from the URL;
Closes web view (returns to the main app screen).
I want to add the ability to 'login with Facebook' to my site. But I am confused when I register my site in Facebook Apps. What should I input into App Domains?
the app domain is your domain name.
Before you enter your domain, first click on Add Platform, select website, enter your site URL and mobile site url. Save the settings.
Thereafter, you can enter the domain name in the App domains field.
See more at my blog: http://www.ogbongeblog.com/2014/03/unable-to-add-app-domains-to-new.html
If you don't specify the platform for the app you won't able to add app domain correctly.
Here is an example -- validate that its a type a website platform.
To add to the answers above, the App Domain is required for security reasons. For example, your app has been sending the browser to "www.example.com/PAGE_NAME_HERE", but suddenly a third party application (or something else) sends the user to "www.supposedlymaliciouswebsite.com/PAGE_HERE", then a 191 error is thrown saying that this wasn't part of the app domains you listed in your Facebook application settings.
In this example:
http://www.example.com:80/somepage?parameter1="hello"¶meter2="world"
the bold part is the Domainname. 80 is rarely included. I post it since many people may wonder if 3000 or some other port is part of the domain if their not staging their app for production yet. Normally you don't specify it since 80 is the default, but if you just want to specify localhost just do it without the port number, it works just as fine. The adress, though, should be http://localhost:3000 (if you have it on that port).
it stands for your website where your app is running on.
like you have made an app www.xyz.pqr
then you will type this www.xyz.pqr in App domain
the site where your app is running on should be secure and valid
It's simply the domain that your "facebook" application (wich means application visible on facebook but hosted on the website www.xyz.com) will be hosted. So you can put App Domain = www.xyz.com
I think it is the domain that you run your app.
For example, your canvas URL is facebook.yourdomain.com, you should give App domain as .yourdomain.com
I have an application where I have to get a message from server. The server sends the message in an SMS. Since iPhone applications cannot receive SMS programatically I have registered a Custom URL scheme and prefixing my message with the custom URL value say for ex: mymsg://.
This works fine most of the time. Whenever the SMS is received by the phone and I click reply button, it takes me to the reply state and the original message will appear like a link which I can click which takes me to the application. For some reason, sometimes this message is not clickable. That is, when I click on the message it does not launch the application or simply the message is not clickable. Then if i restart the phone, the link is clickable again and i can click on the link which launches my application. Does anyone know what could be the reason?
-chinnadurai
I've encountered this issue before but I'm not sure it's the same one you're having. What I discovered is that whether or not a custom URL scheme is clickable in Messages.app is determined when the message arrives, not when the user sees the URL.
What this means is that if you send the user your custom scheme URL before they've downloaded the app, that link will never be clickable, even if they go on to download the app at a later time. I've verified this behavior on iOS 7.1 only (haven't checked other versions).
For my case, I can't guarantee that the user has already downloaded the app when I send the message, so my solution was to use a standard http:// url that redirects to the custom myapp:// URL on the server with a 302 redirect. Hope this helps!
I'm working on an iPhone app that ideally uses OAuth to communicate with Twitter. I know a lot of people are doing the OAuth workflow inside of their apps using a UIWebView, but I don't agree with that and am going with the Pownce approach.
The problem is, Twitter has this whole scheme for working with desktop apps, using a pin number. When I register my app with Twitter, they have a web form asking me if I'm a desktop or web client. If I choose desktop client, when I try to have the user authorize, I can set the oauth_callback parameter but Twitter will ignore it after authorization and show a pin number. If, on twitter's form, I specify that I'm a web client, it requires me to enter a URL to redirect to after authorization. And, since I'm using an iPhone app-specific url scheme, their web form fails on validation as it only seems to accepts URLs conforming to the HTTP protocol.
So, it seems like I'm stuck - I can't say "desktop" because I don't want to bother with a pin, and I can't say "web" or I can't use an iPhone app URL. Any solution to this?
From your question:
I know a lot of people are doing the OAuth workflow inside of their apps using a UIWebView, but I don't agree with that and am going with the Pownce approach.
The Pownce article suggests that quitting your application and opening Mobile Safari to perform the authentication step is problematic, and that they started receiving bad reviews from users for doing it that way. They also experienced a failure rate of around 40%.
Pownce's solution is to use a UIWebView within your application instead, so I have a feeling you may have misinterpreted their recommendations. That being said, they do label this as a "naive" solution and go on to suggest a bunch of theoretical "ideal" solutions.
Another point you might not realise is that desktop applications (using the "out of band" / pin number method) and web applications need to open the Twitter site in either an embedded or external browser.
So you've got two choices on the iPhone:
Open up twitter.com in a UIWebView, specifying no oauth_callback parameter or oauth_callback=oob to start the pin-based out-of-band flow. The user then needs to copy the pin using the iPhone's copy-paste functionality, manually close the UIWebView, and paste the pin into your application. The pin can then be used converted to an access token.
Do it how everyone else is doing it (UIWebView + custom-uri://foo.bar in the callback parameter).
For obvious reasons, the first option is pretty crap and really only useful on platforms where Twitter is unable to redirect to a custom URI.
A simple solution may be to create an HTTP page that always sends a 301 redirect to your custom URL scheme and then provide that HTTP URL to the twitter web API.
Aside from that, Nathan's answer is very complete.
Here's how I do it: tell Twitter you're a web app, and make up any old HTTP:// URL to satisfy Twitter during registration of your oauth client.
Then in your app, pass the URL you want to in the callback parameter. Twitter (in my experience) uses the one you give it.
You could use an intermediate website for the authentication. Your app creates a unique id (hardware based?) and stores it. It then records it has sent the user for authentication and sends the unique id to your website. It then redirects the user to your website. Your website then sends the user to Twitter using oAuth. The user returns to your website and you mark the unique id as authenticated and store the authentication information. The user restarts the app on the iPhone, it reads it has sent the user for authentication and contacts your website with the unique id - and reads in the authentication information.
Long winded and needs another website, but it should work.