In Ryan's Railscast on Facebook authorization, he adds some Facebook SDK javascript at the end to "degrade facebook client side authorization with server side authorization." However, I do not see the use of it. If we already set up the authorization from the server side using omniauth, why do we have to add the client-side authorization again? What difference does it make?
The referenced javascript code is (From the linked Railscast):
jQuery ->
$('body').prepend('<div id="fb-root"></div>')
$.ajax
url: "#{window.location.protocol}//connect.facebook.net/en_US/all.js"
dataType: 'script'
cache: true
window.fbAsyncInit = ->
FB.init(appId: '<%= ENV["FACEBOOK_APP_ID"] %>', cookie: true)
$('#sign_in').click (e) ->
e.preventDefault()
FB.login (response) ->
window.location = '/auth/facebook/callback' if response.authResponse
$('#sign_out').click (e) ->
FB.getLoginStatus (response) ->
FB.logout() if response.authResponse
true
UPDATE:
One of the reasons we need to integrate FB.login authorization with the server-side authorization might be that the Omniauth server-side authorization does NOT work if it's accessed within the Facebook iFrame. If the user accesses the application for the first time, the application must ask for permissions; however, oAuth permission dialog cannot be loaded within the iFrame to prevent clickjacking. Calling FB.login can avoid such problem, because it will show the permission box as a popup(Omniauth popup option will not work).
So now I have a genuine reason to integrate client-side authorization, but the code from Railscasts does not work with my current settings. I've chosen to do it the following way.
Right now, I have the following script in my application.html.erb:
<script>
// Additional JS functions here
window.fbAsyncInit = function() {
FB.init({
appId : <%= ENV['FACEBOOK_KEY'] %>, // App ID
status : true, // check login status
cookie : true, // enable cookies to allow the server to access the session
xfbml : true // parse XFBML
});
};
// Load the SDK Asynchronously
(function(d){
var js, id = 'facebook-jssdk', ref = d.getElementsByTagName('script')[0];
if (d.getElementById(id)) {return;}
js = d.createElement('script'); js.id = id; js.async = true;
js.src = "//connect.facebook.net/en_US/all.js";
ref.parentNode.insertBefore(js, ref);
}(document));
</script>
And in my view, I have the following link invoking the Facebook log in action:
<%= link_to 'log in with facebook', '/auth/facebook', id: 'fb_log_in_link' %>
I add the following script to the view page where I have the login link.
function login() {
FB.login(function(response) {
if (response.authResponse) {
window.location = '/auth/facebook/callback'
}
});
}
Also, I need to change the link to call the function instead of directing to /auth/facebook/
<%= link_to_function 'log in with facebook', 'login()' %>
Done! The server-side and client-side authorization are fully integrated. Since I was still confused after watching Ryan's Railscast, I want to add a little bit of explanation for those who might be also confused.
The way this works:
Facebook SDK is initailized when the while the page is loaded.
The user clicks the "log in with Facebook" link.
FB.login function is called by the link, and the user goes through all the permissions process (e.g. permission dialog showing up asking for the user's permissions).
Then, the user is directed to /auth/facebook/callback. From routes.rb we have the line match 'auth/:provider/callback', to: 'sessions#create'. Therefore, now the server will either create a new user or simply create a session if the user has already registered before.
Done! The user is logged in.
Merging server-side and client-side authorization has two major advantages:
1. If the user is logged into the application either inside Facebook(via appcenter) he will be logged into the application outside Facebook as well. Vice versa, if the user logs in outside Facebook, he will be logged in automatically if he accesses it within Facebook after.
2. Logging in with /auth/facebook does not work if the user logs in within Facebook iFrame. To prevent clickjacking Facebook prohibits prompting users to auth permissions dialog within Facebook iFrame. The only way to avoid this is to open the dialog in a separate popup, and logging in with FB.login solves the problem.
the short answer is - you don't.
you can choose between client side login (via javascript SDK) and server side login using omniauth.
the disadventage of server-side login is overloading the server for a call you can do from the client.
the advantage is that usually the token is longer (3 months token and not 1-2 hours like client side).
i suggest combine the two. use the client side for initial login, once you do that have an async call from the server side for extended token (only if you have to).
It just says,
Facebook provides a JavaScript SDK that we can use to authenticate a user on the client-side so that it doesn’t look to them like they’ve left our application then returned.
It means that this is for the client side understanding that when user returned from the application, it doesn't look like that they have indeed left it.
Related
I have the Webchat (from the Microsoft Bot Framework) running embedded in another application that uses a browser under the hood.
When trying to add Authentication to the bot, I realized that the OAuthCard's Sign-in button doesn't work because is trying to open a blank window (about:blank) that is used to redirect the user to the login page of the identity provider. In the embedded context, the OS doesn't know how to handle the about:blank call. See the image below.
I'm following this example, that it is actually working on the browser:
Add authentication to a bot
Bot authentication example
I want to know if there is a way to change the behavior of the "Sign In" button of the OAuthCard to just open the sign-in URI directly without using the about:blank and redirect technique.
I was able to make it work after finding out that was possible to change the button type of the OAuthCard from "signin" to "openUrl" before the Webchat does the rendering.
There seems to exist a similar issue with Microsoft Teams. Here where I found the clue:
https://github.com/microsoft/botframework-sdk/issues/4768
According to the Webchat reference, it is possible to intersect and change the activities:
https://github.com/microsoft/BotFramework-WebChat/blob/master/docs/API.md#web-chat-api-reference
Here is the solution, that is more like a hack. I hope this would be configurable in the future:
// Change the button type in the OAuthCard to the type of OpenUrl
const store = window.WebChat.createStore( {}, ( { dispatch } ) => next => action => {
if (action.type == "DIRECT_LINE/QUEUE_INCOMING_ACTIVITY" &&
action.payload.activity.hasOwnProperty("attachments") &&
action.payload.activity.attachments[0].contentType === "application/vnd.microsoft.card.oauth") {
action.payload.activity.attachments[0].content.buttons[0].type = "openUrl";
}
return next( action );
});
// Pass the store to the webchat
window.WebChat.renderWebChat({
...,
store
});
I was able to connect with to Intuit using the Minimul/QboApi gem and get the "Connect to Quickbooks" button working with oauth2 based on the example provided on Github. However neither the gem nor the samples show how to implement single sign on with Intuit. In the example provided by Minimul, the Connect To Quickbooks button is produced by intuit's javascript found at https://appcenter.intuit.com/Content/IA/intuit.ipp.anywhere-1.3.5.js
and a setup script and the tag . The tag appears to have been deprecated. Or at least, it doesn't appear to do anything other than produce the button with the right text and logo on it.
But bottom line, I have been unable to find any documentation on the ipp.anywhere.js package, and not even sure if i's meant to used with oauth2 since it's not mentioned anywhere. I believe that the connect to intuit button does the right things, but the guidelines seem pretty strict about what that the button needs to say the right thing and have th eright logo or they will reject it in the store. They also seem to suggest that users are much more likely to try something if an SSO with Intuit workflow is enabled. Any help appreciated.
After some further work, I figured out a solution that can create a 'log in with Inuit button' , although it's a bit of a javascript hack. First, I determined that the only thing I really needed to change was the button image. In other respects the code behind ` works fine for either a "login with intuit" or "connect to intuit work flow" . The only problem is the button image.
Here is the code (adapted from Minimul/QboApi) to get access and oauth2 refresh tokens via a "Connect to Quickbooks" button.
Setup in the controller code in login or sessions controller:
def new
#app_center = QboApi::APP_CENTER_BASE # "https://appcenter.intuit.com"
state= SecureRandom.uuid.to_s
intuit_id = ENV["CLIENT_ID"]
intuit_secret = ENV["CLIENT_SECRET"]
client = Rack::OAuth2::Client.new(
identifier: intuit_id,
secret: intuit_secret,
redirect_uri: ENV["OAUTH_REDIRECT_URL"],
uthorization_endpoint:"https://appcenter.intuit.com/connect/oauth2",
token_endpoint: "https://oauth.platform.intuit.com/oauth2/v1/tokens/bearer",
response_type: "code"
)
#make sure to include at least "openid profile email"
#in the scope to you can retrieve user info.
#uri = client.authorization_uri(scope: 'com.intuit.quickbooks.accounting openid profile email phone address', state: state)
end
Here is the code required to generate the button on the view. (The view needs to load jquery as well in order for the script to work.)
<script type="text/javascript" src="<%= #app_center %>/Content/IA/intuit.ipp.anywhere-1.3.5.js">
</script>
<script>
intuit.ipp.anywhere.setup({
grantUrl: "<%== #uri %>",
datasources: {
quickbooks: true,
payments: false
}
});
</script>
<div>
<ipp:connecttointuit></ipp:connecttointuit>
This code produces the following html on the page delivered to the client:
<ipp:connecttointuit>
Connect with QuickBooks
</ipp:connecttointuit>
This code produces a button with the Connect with QuickBooks image, and an event handler inside intuit.ipp.anywhere-1.3.5.js attaches itself to the click event.
The problem is that the button is styled by the class=intuitPlatformConnectButton attribute inside the generated <a> tag, so if you want a "login with intuit button instead of a connect with intuit button the class on the anchor needs to be changed to class='intuitPlatformLoginButtonHorizontal' but still needs to attach to the event handler defined for <ipp:connecttointuit>. The best solution that doesn't require mucking with intuit.ipp.anywhere is to create the connect button and hide it, and then create another tag styled with class=intuitPlatformLoginButtonHorizontal whose click event calls click on the hidden connect button. I use AngularJs on my login page, so I handle the click with ng-click, but it could be done simply with jquery alone.
new.html.erb:
<div>
</div>
<div>
<ipp:connecttointuit id="connectToIntuit" ng-hide="true">< </ipp:connecttointuit>
</div>
and the controller code:
$scope.intuit_login = function() {
let el = angular.element("#connectToIntuit:first-child")
el[0].firstChild.click();
}
This will result in a redirect upon authentication to the supplied redirect url, where you can use openid to get the user credentials.
We use IdentityServer3 (IdSvr3) for authorization/authentication. We want to offer the ability for our end user (or resource owner: RO) to log in (log through) to a second trusted website (site B) without login in to site B also, after they have already logged in to an initial website (site A). Site B administers a different set of resources for the RO. It is important that the RO is not redirected to the IdSvr3 login/consent screen. A possible approach I found so far is: inside site A an access token is created by calling RequestResourceOwnerPasswordAsync (passing username and password plus scope = "openid ..."). This access token is send to site B with which the RO can be authenticated. Site B retrieves the user info by calling the connect/userinfo endpoint. I want to know if this is a correct approach/flow. We assume that the RO will always enter site A first, not site B.
Thanks in advance for taking your time to think with me about this.
what you can do here is to send a authorize request to identity server for Site B Scope and request id_token or reference token. Make sure while sending the authorize request to idsrv you are using prompt=none, this way you will get the access_token without showing a consent to the user again if the user is already logged-in to site A.
Below example is doing the same from a JS file. In Site A you can refer to this script file and execute the script using IIFE.
function getIdentityServerURL() {
var url = global.appSettings.identityServerURL
+ "/connect/authorize?client_id=siteB&response_type=id_token token&redirect_uri="
+ global.appSettings.siteBUrl + "/Main/SsoCallback&scope=siteBscope openid email roles&prompt=none&nonce="
+ genNonce();
return encodeURI(url);
}
The code above will redirect you to SsoCallback page where you can create a virtual iframe and post the token back to site B after reducing the result from authorize request. Refer to code below.
<script type="text/javascript">
var identityresult = window.location.hash.split('&').reduce(function (result, item) {
var parts = item.split('=');
result[parts[0]] = parts[1];
return result;
}, {});
window.parent.postMessage(identityresult, '*');
your script can listen to postmessage event. Hope this helps.
I am having trouble clearing the last login when using social providers.
Currently using Lock with the following options:
var options = {
rememberLastLogin: false,
auth: {
sso: false,
redirect: false
}
};
var lock = new Auth0Lock('clientID', 'account.auth0.com', options);
The issue is that when executing the next steps it always logins with the same account:
Call lock.show
Select social login provider (Google)
Attempt login with account A [non authorized account]
Lock shows "You are not allowed to access this application." [expected result]
Click Google button again and it still tries to log into the same account A (Lock does not offer a way to try different login from same social provider)
Close Lock and reopen it
Click Google button and it still uses same login account A (no option to enter new account)
What can I do to be able to select a different account?
When you use a social login provider the automatic sign-in is handled by the provider in question. Disabling the sso option and rememberLastLogin will mean Auth0 will not try to login you automatically or provide any information about who login for the last time.
When you login with Google the first time, Google created a session and next requests will automatically use that session by default.
However, Google supports an option that will allow you to choose the behavior you want, in this case it seems you want for the user to be able to select another account, which can be accomplished by passing the following option prompt=select_account (see other options here) in the Google login request.
You can achieve this in Auth0 Lock by providing this option in the auth.params object. Updated example below:
var options = {
rememberLastLogin: false,
auth: {
sso: false,
redirect: false,
params: { prompt: 'select_account' }
}
};
var lock = new Auth0Lock('clientId', '[tenant].auth0.com', options);
Or if you use Auth0.WebAuth then you need to pass param to authorization call:
auth0Instance.web.authorize({
prompt: 'select_account'
})
I'm using Rails 3.0.9.
Trying to login to my (localhost) site through Facebook.
My init params on the login page:
FB.init({
appId : '<%= FB_APP_ID %>',
status : true,
cookie : true,
xfbml : true
});
The login button works, I get the Facebook login popup and I can successfully log in to Facebook.
Then the following event is reached:
FB.Event.subscribe('auth.sessionChange', function(response) {
if (response.session) {location.href= ...}
And I'm being redirected to the wanted location.
But - can't get any cookies of "fbs_" or "fbsr_" like the Oauth is looking for at: get_user_info_from_cookie(cookies)
My cookies = {}, nothing there.
In a few occasions, I recall I did have some facebook cookies there, I can't reconstruct such case, but anyway, it didn't include the "fbs_" ones, only others.
Also, after logging in, when I go back to Facebook tab on the browser and refresh, it does show me my Facebook page, but after a second, it shows a popup says "you need to log in". In my app though, it still knows to keep directing me to the wanted href, like needed when a user is logged in.
I would really love to hear if you have anything that can help me... :-)
Thanks,
Moozly.
Just got the scenario with some Facebook cookies again (still not by the wanted names). Got the following names: "datr", "locale", "locale", "reg_fb_gate", "lu".
But even to these I can't get to with the Rails cookies param - cookies["dart"] returns null.
cookies param only shows the cookies with the host of localhost (which contains data when I'm logging in (with Clearance) - the regular login procedure to site.
Just wanted to update to say that I had solved my problem:
I had added to the init the param: oauth : true:
FB.init({
appId : '<%= FB_APP_ID %>',
status : true,
cookie : true,
xfbml : true,
oauth : true
});
Apparently, there is a bug with adding the parameters added in
js.src, so I removed them(!) and problem was solved:
(function(d, s, id) {
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) {return;}
js = d.createElement(s); js.id = id;
js.src = "//connect.facebook.net/en_US/all.js" //removed: #xfbml=1&appId=<%= FB_APP_ID %>";
fjs.parentNode.insertBefore(js, fjs);
}
(document, 'script', 'facebook-jssdk'));
That solved the cookies problem for me!
if you want to use localhost for facebook development, add "127.0.0.1 localhost.local" record to your /etc/hosts file, change domain in application settings in developers.facebook.com and point browser to this url - it works flawlessly