So my app is (mostly) running. This is a corporate app, that our clients will 'install' on their own Facebook page(s), and make available for THEIR clients to run. During the connection process, I use the FB UID to determine their account on our system, connect that UID to the local account ID. I save that connection in our database, so that when the app is triggered from a Facebook account, I use that mapping to access the correct data.
First issue: I want to be able to detect that the app is being triggered from a Facebook page. I went into the App Settings page, and set up the "Page Tab" platform, with a secure URL. But when my app is added to a page tab, that URL is not invoked, but the Secure Canvas URL is invoked. Why? I assumed that was the point of having a Secure Page Tab URL for my app.
But if that doesn't work, is there a way to identify that my app was invoked from the Page Tab instead of some other way? Not as clean, but that would word as well.
I have used the Javascript API to login, and connect the App to a page. This is all working well.
This is answered in the Page Tab App documentation:
When a user selects your Page Tab, their browser will send a HTTP POST
request to your app's Secure Page Tab URL. This request will contain a
Signed Request in the signed_request parameter with fields you can use
to customise the content returned to the user.
If you're seeing the 'wrong' url triggered, make sure you're not accidentally redirecting, either upon receiving the initial POST request from the user's browser, or after using Facebook Login (e.g. if your redirect_uri when opening the dialog is accidentally sending all users to the same URL after login instead of back to where they triggered the flow from)
Related
I have an application that asks a user to login with Reddit. When they accept, it opens a new window (call it SpawnedWindow), Reddit asks them if they want to connect, and when they do, SpawnedWindow redirects to a GET endpoint on my server with the success/failure information. My server will do some computation to figure out if the auth was really successful, and if it is, it will send an "ok" (as a response to the GET request) to SpawnedWindow.
I want the original page to detect this "okay" and continue with user onboarding. How might I communicate this between the new window and the original window?
If you're familiar with "login with Google" buttons: as we know, there's a popup, and depending on the result of authentication, the main page will have dynamic behavior (based on the login being successful or not). This is essentially what I'm trying to achieve.
The API (and many APIs which have a similar authorization process) provides a redirect_uri that the user will be redirected to after authorization succeeds. You can pass a redirect_url query parameter that goes to a page on your site. This way, once authorization succeeds, the newly opened page (on your site, that Google has redirected the popup to) can communicate to the original page (on your site).
One way to do this is with a BroadcastChannel - open a channel on your original page, and wait for a message. On the new page, open the same channel and send a message, and the old page can listen for the message.
Another option would be to use Local Storage. On the original page, listen for storage change events. On the new page, change storage so as to fire the event.
How can I refresh a long lived facebook access token in the background? From the facebook documentation
Even the long-lived access token will eventually expire. At any point,
you can generate a new long-lived token by sending the person back to
the login flow used by your web app - note that the person will not
actually need to login again, they have already authorized your app,
so they will immediately redirect back to your app from the login flow
with a refreshed token - how this appears to the person will vary
based on the type of login flow that you are using, for example if you
are using the JavaScript SDK, this will take place in the background,
if you are using a server-side flow, the browser will quickly redirect
to the Login Dialog and then automatically and immediately back to
your app again.
What I'm trying to reconcile is that in order to get a new access token you need to have the user login. In order to login, you must call FB.login(). According to the documentation, a user should click a button in order to login.
As noted in the reference docs for this function, it results in a
pop-up window showing the Login dialog, and therefore should only be
invoked as a result of someone clicking an HTML button (so that the
pop-up isn't blocked by browsers).
How can you refresh a long lived access token in the background with the facebook javascript SDK?
You can only refresh a User Token if the user visits your website: Use FB.getLoginStatus for that. You do not need to use FB.login - it would only work on user interaction (click event) anyway, because browsers usually block the popup if you try to call it automatically.
Background on the Application:
Embedded system that will connect to nest-api as a client to retrieve required data. This embedded system can connect to a wifi network and provides a web interface through which user can carry out authentication.
For authentication, currently the user is directed to
https://home.nest.com/login/oauth2...
and user can carry out the authorization procedure and get an 8-char PIN.
The user is then asked to input this PIN in a text box and submit it to the embedded web server which then requests the access_token (using C platform).
There are two questions related to this issue:
1) Is there a way to carry out request for access_token also from the client browser, and only return the access_token back to the embedded system? Any Javascript code that can request access_token after user inputs the PIN and submits?
2) The second issue is related to lack of automation. The user needs to type the PIN back in the web interface. Is there a way to extract the PIN from the website automatically using some script. For example, open the /login/oauth2 page embedded within another page and run a script on the main page to keep scanning the embedded page until the PIN becomes available (i.e. the user logs in and grants permissions). As soon as it becomes available, it can be copied and returned back to device web and access_token requested automatically.
I understand that this type of automation can be achieved by web-based authentication, but from my understanding that would require a proxy server for redirect URI. The idea is to make the device self-sufficient without a need for maintaining another server.
Yes, see the control-jquery sample code for an example of how to work with OAuth tokens in JavaScript
Nest allows you to use addresses that start with http://localhost or https:// as the OAuth Redirect URI. You can either run a web server locally, or monitor the WebView for a redirect URI pattern of your choice and parse the results.
The way authentication works in our webapp is that after 2 mins of user idle time it redirect the next HTTP request to the auth server to refresh access token which is then placed in a cookie which is used to authenticate subsequent HTTP requests. So, if the user is idle longer than 2 mins and then tries to submit a form, the redirect to auth server loses form data and sends the user back to the empty form.
We have no control over the auth server and would like to come up with a mechanism that would periodically perform a background redirect to auth server without leaving the current page. One option is to use an embedded iframe, but this makes it nontrivial setting the cookie on the main page after the redirect. Is it possible or appropriate to use HTML5 web workers for that? Any other solutions?
Thanks
I'm building a widget that can be placed on a various sites, and will have users be able to log in via facebook connect to accounts on the widget's parent site. I was going to use the Facebook JS SDK to do this, but the widget will likely be placed on sites that already have the FB JS SDK initialized on them with a different app ID, and if I were to run code this way it could lead to a namespace problem.
The only current solution I have come up with is to do the server-side type authorization, and have a redirect-url that leads back to the current page in which the widget is hosted and use the state paremeter to alert backbone router that the user has logged in.
The first problem I thought of is that on the facebook docs site it says
For security, the redirect_uri must have the same base domain as that specified in the App Domain property of your app's settings, or be a URL of the form https://apps.facebook.com/YOUR_APP_NAMESPACE.
How do I bring people back to the original page that the widget it hosted on after login? Is there a better approach to this problem?
you can use Server side authentication and redirect_uri to your site that will redirect to the various site
redirect_uri = https://www.mydomain.com/?r=https%3A%2F%2Fwww.somesite.me
On you server you will look of the query param r and redirect the request to r value.
You can also do your own authentication for users (when they first sign in) and store there facebook access_token on you DB, once your widget is running (under https) and you identified the user on your authentication you can send the widget client the user's access_token and work with it.
You can even create your own Simple FB-like ajax library, for most things it will be a simple get/post/put calls with access_token as a url parameter
Hopes it helps