All,
Here is the scenario;
Our website uses APPID-1 for auth and extended permissions (MainSite)
Our Page Tab App uses APPID-1 for auth & extended permission
(TabApp-1), and this adds the auth_token to our DB on MainSite
However we want to add another tab that uses APPID-1 for auth_token acquisition, is this possible?
Proposed scenario;
MainSite - APPID-1 acquire auth_token
TabApp-1 - APPID-1 acquire auth_token
TabApp-2 - APPID-1 acquire auth_token
I should note that non of our TabApps actually need the auth_token, its our MainSite backend app that uses the auth_token to perform actions for the user. However we want to make it easier for our users to use the site, and many come via our Fan Page.
So can we have TabApp-2 pop the Auth Dialog for APPID-1 with is not TabApp-2's APPID?
Specs:
Ruby on Rails 3.1 and using Graph API & Javascript Fb API
I guess you would have to initiate the JS SDK in TabApp-2 with APPID-1. Server-side you would receive a signed_request with TabApp-2 credentials but you can just it that if you work only with the JS API.
I guess you could validate the assumption with a prototype in less than 30 minutes. Have you done that yet? If so, what were the results?
You don't need different apps for this (but i think you're aware of that) the same app can be installed onto multiple pages, and you can show different content on each page by checking the page parameter in the signed_request which is POSTed to your server when the page tab is loaded by a user.
As far as authorisation goes, you may have issues when getting the user to log in directly from a page tab (issues = it may not be allowed to redirect the user back to the tab after login because the full URL to the tab (http://www.facebook.com/pages/somepage/12345?sk=app_{app id here}) isn't 'owned' by your app)
If that happens you can send them to your main site after login with an additional parameter that you use to detect that the user started login on a page tab, and redirect them back to it
Seems you will have to make a few apps, then just use php-sdk to authenticate, since the auth will be server side it will not matter what iframe or page tab it appears in, it will be able to auth to a single app.
Related
I am writing a Reddit client that uses OAuth to authenticate the user. One of the features I would like to implement is the ability to use multiple accounts simultaneously. This requires the user to authorize my client on each account they want to use. The problem I'm running into is that if the user is already logged into Reddit in their browser, when I pop a browser to perform the auth, it will have them authenticate my client against their currently logged in user.
Is there a way to force the user to re-enter their credentials? I would rather not have to put some kind of disclaimer on my Add Account screen that says "Please log out of Reddit in any open browser windows".
I tried opening the Reddit login page in a WebView so the request is sandboxed, and while that worked, it gives the user access to the entire login page (including all the links that navigate to elsewhere on the site). I don't mind that experience when I'm popping an external browser, but in an embedded WebView I really just want to present a username and password box along with the OAuth validation prompt.
Note: I do kind of prefer the embedded experience because it doesn't interfere with the users existing browser cookies, I just don't like how cluttered the login page is this way and I'm not sure how to prevent the user from navigating away from login. Also, for completeness, this is a UWP app, though this problem is largely technology independent.
The problem I'm running into is that if the user is already logged into Reddit in their browser, when I pop a browser to perform the auth, it will have them authenticate my client against their currently logged in user.
It may be caused by the authorization server. If so, we can not do anything in our client app.
But if it is not the server issue, in UWP, there is a WebAuthenticationBroker class witch can help you to authorize your app to access the user info from Resource server by getting a token. You can try to use the class to implement OAuth authorization. You don't need to use the in a WebView so that you can authorize your app with multiple users if you can manage all the user with the token properly in your code logic.
See the Web authentication broker topic and the sample to learn more details.
I want to use the Instagram API to show my own content on my own website. I can see in their documentation that content owners can display up to 20 pieces of media on their site while the app is in Sandbox mode.
I've created an app on my account and I am trying to use their Client Side Implicit Authentication to generate an access_token.
I hit this URL and login to my account:
https://www.instagram.com/oauth/authorize/?client_id=MYCLIENTID&redirect_uri=www.mysite.com&response_type=token
When I submit the login form, I am brought to an Instagram 404 page that says:
Sorry, this page isn't available. The link you followed may be broken, or the page may have been removed. Go back to Instagram.
What am I missing? Do I even need an access_token? Before they changed their API last November I was able to use just the client_id in my requests. I suppose that's not possible anymore?
I think you need to include http://.../ for your redirect_uri. So it would be: https://www.instagram.com/oauth/authorize/?client_id=MYCLIENTID&redirect_uri=http://www.example.com/&response_type=token
But of course that means you will also need to add http://www.example.com/ as the Valid redirect URIs in "Manage Clients" on Instagram.
I'm building a native application. The app has an embedded webview (UIWebView) pointing to a social website. To be able to use the website inside the app, user has to log in by the webview (username/password) and then he can continue use the site with saved cookies. Normally, the cookies expire after two days. After that, the user has to re-login by the webview.
Now suppose I know username and password of the user and I would like to make the user login automatically with this account when the cookie expires. How can I do that?
I tried to simulate the Login action when I click on Login button on web page, but not successful.By using "Inspect Element" of Chrome, I can see Chrome makes a "Post" request to an URL with some parameters. However, the request doesn't get successful (I use REST client for testing).
Finally I found out the solution. I didn't build requests anymore. I used javascript to set text fields and make "click" action on the webview. Done.
I'm making the back end for an iOS app in Rails. Users need to be able to log into the app using an app-specific username/password or via Twitter, but I'm not quite sure how to set things up for logging in via Twitter.
If I use OmniAuth, then it seems like the flow goes like this:
The iOS app directs users, in Safari, to the /auth/twitter page OmniAuth sets up for me
The /auth/twitter page sends the user to Twitter for OAuth authentication
Twitter returns the user to /auth/twitter/callback, and OmniAuth gives me an auth hash full of info
????
iOS app now has the credentials it needs to identify the user making requests when it calls my APIs
Authentication complete, app use proceeds as normal
It's step 4, getting the credentials back to the iOS app, that I don't know how to set up. All my APIs the iOS app calls are stateless; if they require an authenticated user, then user credentials are included in the API call. I don't know that much about writing iOS apps, and pretty much nothing about how apps interact with Safari.
What is a safe way of getting the user credentials back to the app? One that can't be snooped? If I have the callback page put information in cookies, or in the session, will that be accessible to the app but not anyone watching the traffic?
Alternately, if the app attaches some identifier for itself to the initial call to /auth/twitter, will Twitter & OmniAuth preserve that identifier so that it gets included in the /auth/twitter/callback, so that the app can then ask my back end for the credentials for an authentication that just finished associated with that identifier?
Alternately, if the app attaches some identifier for itself to the initial call to /auth/twitter, will Twitter & OmniAuth preserve that identifier so that it gets included in the /auth/twitter/callback, so that the app can then ask my back end for the credentials for an authentication that just finished associated with that identifier?
Did you try? Cause that's usually how your step4 goes. You keep a token or something about the user so when you get the callback you can lookup for that user again. No session or cookies, just plain db.
I am embedding a Facebook app https://example.com into the Facebook app canvas so that it is available at https://apps.facebook.com/EXAMPLE . My application sends notification emails that contain links like https://example.com/messages/123 and that should open the page embedded into the Facebook canvas. How do I achieve this? My current thoughts:
User opens https://example.com/messages/123
Application checks for signed_request parameter
Application redirects user to https://apps.facebook.com/EXAMPLE/?requested_page=/messages/123
Application checks for requested_page parameter and redirects to this page
User sees https://example.com/messages/123 URL and is embedded into canvas
Is there a better pattern out there to get this working?
My final working solution (with Ruby on Rails)
User opens https://example.com/messages/123
Application checks on client-side if app is embedded in canvas:
if(window == top){
top.location = "https://apps.facebook.com/#{Settings.facebook.app_id}#{request.fullpath}";
}
User is redirected to https://apps.facebook.com/EXAMPLE/messages/123
Application middleware converts POST into GET if signed_request is present (code and idea borrowed from https://github.com/dekart/facebooker2/blob/master/lib/facebooker2/rack/post_canvas.rb)
Application parses signed_request with fb_graph gem
FbGraph::Auth.new(app_id, app_secret, :signed_request => params[:signed_request])
I'd just update the link to point to http://apps.facebook/example/messages/123 off the start.
When you check for authentication just set the redirect after authorization/login to the same page.
Redirecting a user around multiple pages for no reason is just not a good practice.