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.
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 have seen that it is not possible to display any Google page from an iframe. An error message is displayed: cannot display, open in a new window.
I need to login to Google (OpenId authentication) from an iFrame in Joomla (cannot change this). Is there a workaround for this? I thought I could open the authentication page in a new window, and then try to kill that window and reload the original one, but I am not sure I can do that.
Thanks
Well you can just get the form (html code) and put it in your iframe but this will get very messy, for example, there maybe certain JS files that you need to include as well.
Redirecting to Google is best way to implement it.As Using IFrame Sometime does not allowed by some Companies Due to Security.
I have facepile plugin on my webpage to show faces who are using the application.
The code snippet to show facepile is
<fb:facepile id="some_id" data-size="medium" data-width="396">
</fb:facepile>
Faces are showing normally.But when I use "Use facebook as:" option from the facebook homepage and selects any of my listed pages, facepile plugin on my webpage turns weird and shows a white box with a small thumbnail and an anchor(with text 'switch') on top of it On inspecting element with chrome's right click context menu I found it's an iframe with width being 396px and height being 1000px which displays in the middle of page hiding html form for normal login too.
If I revert to my profile using "Use facebook as:" option faces start showing normally.
Am I missing something or It's a bug?
I already checked a similar question but that is related to user being not logged.
Also I checked this bug listed
on facebook developer page but it seems to be resolved.
This is intended behaviour, although obviously the error message should be a bit better - the Facepile (and indeed, most of the Social Plugins) is designed to only work with User accounts. You can be fairly sure that 99.9% of people viewing the plugins will not be "Using Facebook as" a Page.
As Pages aren't designed to really interact with Facebook APIs (beyond the manage_pages functionality) then it is likely that these plugins won't be fixed to work for page accounts, but they'd be fixed to show a message informing anyone logged in as a Page to switch back to their user account.
You can find some related bug reports below, you should consider adding your voice to them in order to increase their priority:
https://developers.facebook.com/bugs/372904202778489
https://developers.facebook.com/bugs/313164415437524
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 …