In FBML applications, you could prompt for extended permissions like so:
Facebook.showPermissionDialog('publish_stream', callback);
This rendered a lightbox (much like FB.ui({method: 'foo', display: 'iframe'}); does).
From what I'm seeing in the docs, the only ways to prompt for more extended permissions now are to either cause a window to pop up with FB.login(), or to redirect the user to the oauth dialog full screen. We don't want to rely on the former because popup windows are unreliable, and the latter makes no sense in our user interaction flow. A lightbox is the only way that makes sense.
If the oauth dialog could be displayed as an iframe, this code would theoretically work:
FB.ui({method: 'oauth',
display: 'iframe',
access_token: 'foo',
scope: 'publish_stream'
}, callback);
But the oauth dialog only supports being displayed as "page" and "mobile".
Is there any way I have overlooked?
Think about it: It's of course not possible to use the auth dialog in an iframe, because it's a security matter.
Displaying it in a popup or redirecting to it gives the user the ability to check the sites address is actually facebook.com.
If you where to use the auth dialog in a lightbox as an iframe or similar, there would be no way for me as the user to see if the data it put into the login form (which would get displayed if I'm not logged in to Facebook at that moment) is actually sent to Facebook, or if you had just set up your own form that'll send the data to your server, because you are trying to phish for my Facebook login data …
Related
I am trying to create a web page which will allow my user to upload a file to my S3 storage. For choosing the file user can use Google Drive, Dropbox and also local system. Am facing issues while implementing the Dropbox part of this.
Am using this technique for integration(using core API and OAuth 2).
First when user chooses Dropbox i am opening an HTML page in an IFrame. Here I have an authorize button which will open the authorize endpoint mentioned in the above link. This link shows me X-FRAME-Options error inside the Iframe so i had to open this link as a popup to work.
Is there a way around this? I'd like the authorize URL to open in the same iframe by using location.href.
Also when i open it as a popup, after the user logs in successfully the redirect_uri which i pass i getting opened in the popup. I had to do some unconventional setInterval coding to go around this. Can someone suggest a solution for this as well?
I also tried using CSRF tokens as mentioned in Smarx's blog but this also gives me the same error.
EDIT :
#smarx i tried using dropbox.js and it works fine. Stuck at one place
I used the OAuth popup driver and have a button which says sign-in.
First on load i create the client and then the popup driver as below
client = new Dropbox.Client({ key: client_id });
client.authDriver(new Dropbox.AuthDriver.Popup({
receiverUrl: "http://localhost/uploadCare/dbcallback.html"
});
);
And in the call back html i am writing
Dropbox.AuthDriver.Popup.oauthReceiver()
as mentioned in the docs.
But this does not take me back to the original page and show me the list of files.
I particularly did not understand this part of the explanation
"To use the popup driver, create a page on your site that contains the receiver code, change the code to reflect the location of dropbox.js on your site, and point the Dropbox.AuthDriver.Popup constructor to it."
Could you please help me out here.
You definitely can't put dropbox.com into an iframe, for security reasons (e.g. clickjacking).
A few suggestions:
Can you just use the Chooser for your use case? That would certainly be easier for you and your users.
If you can't use the Chooser, is there a reason you're not using dropbox.js? It has a popup auth driver that will pretty much just take care of all this for you. The redirect will definitely happen in the same window as auth, so communication between the windows (usually via localStorage) is generally necessary. This is already done in dropbox.js.
I am building a basic login page using the existing sign-in portlet.
I just want to have a functionality that when a user access the website, right now localhost:8080, the sign-in portlet should pop up!
Is this doable? If so, Can someone please hint me how this can be done?
This is how the default page looks like right now:
To log in, I have to explicitely click on the "sign-in" blue button and then it pops out a modal sign in portlet.
But what I am trying to do here is:
Whenever a user clicks on the default url, it should immediately ask the user to login rather than showing a blank page with a sign-in button (something like the output image)
Or even a modal sign-in box (Whatever is easy to customize.)
and
Whenever a user hits any other url for eg. localhost:8080/web/project1/home and if the user is not signed in, it should force him to sign in first.
Two possibilities out of the box:
place nothing but the sign in portlet on the homepage, appearing at that location (typically /web/guest/home)
protect your default page to be not visible to the guest user (this will automatically forward to the sign-in portlet) - see the "Permissions" button on the "Manage Pages" interface
There are more, but these seem to be the first and most obvious ones. Let me know if one of them works for you or what the reason for your request is
From what I understand, you want the Login Portlet to popup as a modal window/lightbox on the current page (i.e. without leaving the page). AFAIK, to achieve this, you'll have to develop all your portlets to use AJAX to create links that point protected resources. So when you get an unauthenticated request, you can stay on the same page and show login dialog.
This is high-level approach. You'll need to 1) embed the Login portlet in your theme and 2) put the below javascript functionality in Theme:
callback function - to handle response for unauthenticated request,
to render modal/lightbox
You might face surprises while implementing this.
I set up an app to allow users to log into my site using Facebook. When users click the FB login button, the expected auth dialog appears. My auth dialog shows a second page which says: "This app may post on your behalf, including status updates, photos and more."
But my app doesn't need any extended permissions, and will not be posting anything to Facebook. I don't want this second page to appear, but I can't figure out how to make it go away.
On my app's settings page, I didn't specify any extended permissions. Is there someplace else I have to specify that I don't want extended permissions?
Thanks for the help.
You might have specified a scope in the "Login with Facebook" button that requests these permissions from the user. Especially if you just copy-and-pasted an example from the documentation, this might have happened.
Check in your HTML whether you have something similar to this:
<div class="fb-login-button" scope="publish_stream">
Login with Facebook
</div>
If so, make sure to get rid of the scope attribute.
I am in the middle of making an app using a PHP web service to log users in/authenticate their credentials.
I am using localStorage (part of phonegaps local storage API) to ensure the user doesnt have to keep logging in when they open the app. This is done by storing the username and password on local storage and checking it when the app opens. If they feel the need to log out I have a simple logout button binded to a tap event which clears their local storage.
$( '#logout' ).live( 'tap',function(event){
window.localStorage.clear();
$.mobile.changePage("#loginPage", {transition: "none"});
});
BUT... when logged out, they are still able to click the back button on the phone and get into the secure area, which doesnt make sense because the "welcome, (username)" part is all messed up etc...
Im wondering if there is a way to ensure that what ever page they open does some sort of check to make sure theyre logged in??
Bind into the pagebeforeshow event of the pages to check if the user is logged on - check if credentials are present in local storage.
If user is not logged on you can either call preventDefault to stop the pageChange or better redirect the user to a loggedOffPage by modifying the toPage passed into the handler.
Refer the Page change events section on JQM Events page.
We're creating a website where we will be giving out code snippets to our users which they can place on their own websites. These snippets contain a link a javascript include. When clicking the link, an iframe containing the login dialog to our site opens. The user then authenticates inside the iframe, does his work and when he leaves the iframe his session is closed. We've got it working allready and it's very slick.
Our main concern though is phishing. The user has absolutely now way of veryifying where the login page is really coming from. On the other hand, phising attacks are also succesfull even if the user can see the fake-url in the address bar.
Would you enter your (OpenId) credentials in an iframe? Does anyone know a pattern with which we could minimise the chances of a phishing attack?
The user has absolutely now way of veryifying where the login page is really coming from.
There are ways around that, by having the user choose a secret that the real login page can display back at them to identify itself. Usually this is done with easily-identifiable pictures.
However that is not the only issue. If you allow your login page to be framed (and the user comes to expect that), you also open yourself to clickjacking attacks. The third-party site can frame your login page, then position: absolute their own HTML elements on top of it. Elements like inputs directly on top of yours, sniffing each keypress to nab the password.
You can allow a simple “start login process” button to be framed, and maybe a username/identifier, but the form into which a password should be typed must open in its own browser window (either in the main window or in a popup) with its own address bar and SSL indicator.
Would you enter your (OpenId) credentials in an iframe?
Goodness no.
I would recommend not using an IFrame as they defeat accessibility, seo, and semantics unless you want those defeated. If you are asking people to login via an IFrame then you have a definite accessibility barrier that may be considered legally discriminatory in certain countries.