I've got a complex page that can be customized and should be embedded in some clients' websites. For each client it should look the same, but the parameters can be little different. The page also contains a custom object that uses a plugin in the browser.
I had 2 idea to accomplish this:
Using an iFrame - so I just embed my page and pass parameters in the
querystring.
Using a remote JS file - like Facebook SDK and others
work. Passing parameters in the JS code. As I understand, I can just put some 'parent' div on the page and the remote JS file, which should fill the parent div with the needed elements.
Which one should I use? What are the cons / pros of each one?
Thanks!
Take a look at this article which has an in depth look into the ways of what you're trying to achieve.
Pros of IFrame:
If the owner of the mashup page is really concerned with security, malicious scripts running in the widget, then the IFRAME approach is preferable, because the widget’s script will have limited access to the host page and hence couldn’t make much harm to the page where it's embedded into.
Also, this approach is preferable if the owner of the widget wants to control the layout and styling of his/her widget. Since the IFRAME is essentially a separate web page, the mashup’s CSS scripts can’t do much harm to the widget.
Cons:
it is slow, resource intensive [on the browser], and does not give the owner of the mashup page an ability to style the widgets the way s/he wants.
I've had similar issue some time ago. You bassicaly have three options to choose depending how secure and flexible your plugin should be.
iframe
pros
fairly secure - you can present data that should be viewed to specyfic user only and allow passing sensitive data to your service. Page that includes your plugin will not have access to it.
page that includes your iframe will not be able to modify it's content to confuse user
cons
slow
limited communication between your plugin and the page(may be solved by between-window post message/porthole, but this is not perfect)
page still may scam users into beliving they see your plugin, while present own copy or use click jacking
if you include any assets from 3-rd party server that bit of security you had is lost
limited to rectengular box
script
pros
extremly flexible
easy to implement variety of callbacks to react on events on the page
fast
may integrate with interface of the page in many different ways and spots
cons
basically can be modfited in any possible way by page that includes it. You have no controll what users will see in the end.
redirect through your service and then back
pros
most safe solution
cons
hardest to seamlessly integrate
may not interact with other elements of website that uses plugin(since when users see your plugin they are't seeing source website anymore)
Related
In order to see a live preview of another website that users link to on my website, I'm using iframes.
However, this is probably not the best solution, as a website is loaded directly into mine, with every JavaScript element etc that is on the linked page.
My question: how dangerous is it to do such a thing? What is the worst case scenario that could happen? Could a linked site just by using JavaScript (or other technologies) do any serious harm to my site or my user's data?
And then, the second part of my question is, of course, about the website preview.
All I found so far are scripts that contain more than one php and js file in order to load a website preview picture.
Isn't there an easier way to do this? What do you suggest?
how dangerous is it to do such a thing?
Some websites do not like to be embedded using frames. Such websites can possibly take over the full browser by ensuring it is loaded in the topmost window. Aside from that, as long as your website and the website you are loading aren't from the same domain, they won't be able to access your cookies, DOM etc. So its pretty safe in that respect.
about the website preview
There aren't many fool proof mechanisms other than generating the preview image server side - as I believe the scripts you've seen do.
When building a social bookmarking button widget for usage in other websites there are a few challenges. We just recently opensourced the clientside aspects of this. (blog post here: http://www.mellowmorning.com/2010/08/03/creating-your-own-diggfacebook-liketweetmeme-button/)
Basically the goal is to replace the chosen elements
love it
With a button showing how many other people loved it.
There are two approaches to this.
- replace the A with html (script approach)
- replace the A with an iframe (iframe approach)
There are rather complicated differences between these approaches. One particularly annoying is the inability for the script approach to communicate with its popup.
Can anyone suggest a workaround to communicate between the login popup and the button. (IE. when you love something through the popup?, how do you update the count on the button, without being stopped by same origin protection..)
Which approach do you recommend. Iframe or Script and why?
These are the differences I encountered: Iframe vs Script
Iframe:
Popup communication possible
The script approach cannot communicate with popups it creates due to the same origin restrictions. The iframe however can be of the same domain as the popup and freely communicate. This gives a better user experience when for instance logging in.
Easier to develop
The iframe approach is easier to develop and requires less code.
Parallel download in IE
IE doesn’t download the count scripts in parallel, but it does do so for the IFRAMEs. Making this approach somewhat faster.
Independent CSS
External sites don’t interfere with your button’s css if you use an iframe technique. The disadvantage is that it makes things likes hovers impossible to integrate with the other site. (For example Fashiolista’s compact button).
Independent
The iframe approach makes it very hard for other sites to game the users like/love action. With a script approach a foreign site can simply call your javascript to fake someone loving the product. This freedom can be abused but also allows for mashups.
Script:
Slower dom load
Creating iframes takes a lot more time for the browser.
Slower perceived load
The script approach allows you to format the buttons before the data is loaded. Vastly increasing the perceived load speed.
No shared functionality
Buttons can’t share functionality. So when someone logs in for one button its is not possible to update the others.
There is of course a third option too, which is a hybrid between the iframe and the script approach.
You can use script to hook into the pages DOM (gives a loot of freedom with regards to different uses), and to create a hidden iframe pointing to your domain.
The script could communicate both with the current document, and with yours using Cross Domain Messaging and in turn with the popups using the iframe as a proxy.
Of course, the XDM does impose some difficulties, but if you use a proved solution like easyXDM, then it shouldn't be much of a problem.
Here is an example that shows how to interact with a popup.
Basically 2 questions
- Which is the best approach
- Workaround for the popup communication difficulties the script approach faces
Thanks for the popup information!
What is the underlying technology to support these cross domain popups?
If i understand your third option correctly:
- foreign site loading our js
- js replacing dom elements
- js opening hidden iframe to own domain
How do I then open a popup which still allows for communication with our js loaded into the foreign site? For that the popup would need to be instantiated by the iframe right? And we would need a method to communicate with the iframe. I thought im not allowed to do anything with the iframe except setting its window.location.href. Could you explain how that works?
Soon I'll be needing to build a widget that some of our clients can embed in their own websites.
To future proof my widget the embed code would be something like this:
<script type="text/javascript" src="path/to/remote/file.js"></script>
<div id="my_widget"></div>
What are the strengths and weaknesses of iframes vs JSONP?
Are there any common SEO based issues with iframes?
First of all, iframes and jsonp are not mutually exclusive: one is a rendering mean, the other is a communication mean.
Your choice is rather between in-document inclusion (that is creating the widget within the host DOM) or in-iframe inclusion (that is having a new, separate DOM for the widget).
The advantage of an iframe is sandboxing: no collision between your widget and the host's javascript and css. That means you can safely:
use/define any javascript library you want
use simple html code together with simple css rules (which is a clear bonus for maintenance)
As for the drawbacks:
an iframe is heavy-weight and may seriously slow down host page rendering
the iframe will also consume much more memory and resources, which may be a problem if the host page is targetted at mobiles
So, if it is reasonable to assume people using your widget will be willing to "adapt" their pages for it, go the in-document way. If not, use an iframe but understand the limits.
As for SEO issues, as long as you dynamically create the widget (whether it's in-document or with an iframe), search engines won't see it. I dunno if that's what you want, but that's what you'll get ;)
Heres some slides from a presentation on cross domain scripting by Alex Sexton
http://www.slideshare.net/SlexAxton/breaking-the-cross-domain-barrier
Unfortunately its just the slides so is missing the accompanying explanations but could be helpful
If you're making API calls and only fetching data, JSONP will result in better performance. If you're rendering things, then you must use iframes. If you want to prevent the host site from access to your widget data, iframes are the way to go. But if your data is public, then JSONP will result in a simpler implementation (since iframes will mean you need to deal with resizing). On the flip side, iframes provide for good CSS sandboxing, so you won't collide with the host page's CSS.
I chose to go with JSONP. You can see the details of how I implemented it here:
if I allow partner sites to republish my RSS feed, will that boost my SEO ranking?
Some people gave their opinions on SEO. I'm still not sure, however, if it helps SEO. I just got an idea to test it though, and I'm going to carry it out right now! I'm going to make a page with just the JavaScript that renders the widget (feed in this case). Then, I'll use Google's Webmaster Tools to see if Google picks up any of the keywords in the feed content. I'll post the answer to the link above after I get the results.
Wish us the best!
Matt
I recently implemented a fix to create separate landing pages depending on whether or not the user has javascript enabled. Basically the way it works is this.
The default page is an HTML page w/ no javascript. Basic version of the site. Upon landing on it, there is a script that says if javascript is enabled then go to another page. That landing page is generated by sending the user request through a JSP file that renders the page (header, footer, etc.). The final landing page is http://whatever.com/home.jsp if the user has javascript enabled.
My question is if this will hurt SEO. Considering 99% of the world has javascript enabled I would hate to compromise any SEO benefit to accomodate the 1% who doesn't enable javascript.
Hope that make sense.
In general, searchbots should be treated as browsers with JS disabled. I think you can now imagine where they'll land.
This whole question is by the way completely unrelated to JSP. It is just a server side view technology which provides a template to write HTML/CSS/JS in and provides capabilities to control the page flow dynamically with taglibs and access backend data with EL. All what webbrowsers and bots sees (and thus all what counts for SEO) is its generated HTML output.
http://www.google.com/support/webmasters/bin/answer.py?answer=66355
Short version, if your JS sends them to entirely different content, it's probably bad, and Google may give you a a hard time. Other than that, you should be good.
If the alternative version is an (almost) full-featured, full-content version, then it's perfectly OK.
Google even advices for making alternatives for Flash-only sites, for example, in regard to usability.
Read google FAQ
You touch two topics, one is described as "Cloaking", the other as "Duplicate Content". With "cloaking", you present different (optimized-with-bad-intention) content based upon identification of the client that accesses it, e.g. by inspecting the User-agent header (google-bot versus Browser). You are not doing this, you just want to present content in a way that suits your client best, like a redirect on a page optimized for mobile clients ("m.example.com").
The other thing is how to avoid duplicate content. There's a way by indicating the original content source with a canonical tag, see here: http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html
There have been many debates about this topic already here, but none of them fully answered my question so I figured I would pose it and hope I get one or two decent answers.
We're planning on relaunching our company website in the next few months. Our current site, for the most part, is text-driven and because of this we rank very well on Google, Yahoo, and Bing for our primary keywords. We want to increase the "Wow Factor" of the site a bit (we're an interactive agency) but still maintain a majority of our search engine footing. The option to use Flash, AJAX, and other technologies that are not considered to be search engine friendly have come up numerous times in our meetings and each time we have to evaluate what kind of impact it would have on us from an SEO perspective.
Assuming a good portion of the site content will be encapsulated within a Flash (swf) file, what would be the best course of action for maintaining current rankings? I've read numerous times that Google indexes Flash files but I am unsure as to what extent. Further, is there a method of telling Google not to index a Flash file (through a variable or otherwise)?
Finally, I had an idea that seemed sound in theory and wanted to put it out into the world and see what type of feedback I receive on it:
Again, assuming the whole page is in a Flash file living on index.html, would it be possible to build out the site as normal (set up a logical directory structure, add content to static pages within said structure, etc), specify paths to those static pages in a Google XML Sitemap file, and have the spiders crawl only those pages (which are rich in content) while the user experiences some concoction of Flash/Javascript/AJAX/etc? If this works, what would be the pros/cons of this solution? Thanks for bearing with me on this slightly off-kilter question.
Well referencing Google I found that they have made impressive strides into indexing Flash based web pages. The only limitation I found from reading the article is that they are currently still limited in their ability in these three areas:
Googlebot does not execute some types of JavaScript. So if your web
page loads a Flash file via
JavaScript, Google may not be aware of
that Flash file, in which case it will
not be indexed.
We currently do not attach content from external resources that are
loaded by your Flash files. If your
Flash file loads an HTML file, an XML
file, another SWF file, etc., Google
will separately index that resource,
but it will not yet be considered to
be part of the content in your Flash
file.
While we are able to index Flash in almost all of the languages found on
the web, currently there are
difficulties with Flash content
written in bidirectional languages.
Until this is fixed, we will be unable
to index Hebrew language or Arabic
language content from Flash files.
By the sounds of it you won't have any problems with any of the 3 'problems'. Based on this document Flash sounds like a viable option for you.
Adobe has been working on their end as well to accommodate the search engines in their stride to make SWFs more search engine friendly as well. So with the combined efforts of both Adobe and Google/Yahoo if you take a dip in ranking within a year or two the search algorithms will be better than they are even now.
As far as not indexing you should be able to add in a simple
User-agent: *
Disallow: /directory/
Disallow: /directory/page.html
to your robots.txt file.
Andrew,
I've had to deal with this sort of thing a few times and I'd recommend maintaining both a Flash site (for users) and an HTML site (for search engines). Here's how you do it:
With whatever server-side stuff you're using set up some kind of switch that determines whether a particular request is for HTML or for whatever your Flash movie consumes (XML, JSON, another SWF, whatever). Every page on your site should be able to return HTML and whatever you choose to feed your Flash movie. A query string parameter like "requestType=Flash" will work just fine.
Put all of the content in your HTML pages in a div tag and make the div invisible with CSS. Use SWFObject to check if the requesting browser supports Flash and, if it does, have SWFObject replace your HTML content with your Flash movie. Search engine spiders will ignore your scripts and simply crawl your HTML pages and if you'd like to show the HTML to users with browsers that don't support Flash (like mobile browsers), just make the HTML content visible after SWFObject has determined that the browser doesn't support Flash.
Once your Flash movie has loaded, have it request whatever data it needs from the server using the same URL of the page that it was loaded on, but with the addition of the switch variable above.
Handle navigation from that point on with SWFAddress. When a user clicks a button to request a new page, pass the request through SWFAddress first, which will update the browser history using the hash mark trick, and then have your Flash movie make its request to the server.
I'm currently working on a site for a friend that uses this technique here (I should note, to protect my pride, that the site is still very much a work in progress):
http://www.casabarbuenosaires.com/
A browser request to any page on the site will first return the HTML representation of that page (you can view source in your browser to see that). SWFObject then replaces the HTML content with a Flash movie that loads a custom XML description of the same page which the Flash movie then constructs and displays.
I've worked on sites in the past that have used this technique and gotten excellent search engine results. Since you don't need to worry too much about what your HTML site looks like to humans, you can focus solely on what it looks like to search engines.
Another added benefit of building your site this way is that you are compelled to separate your site's content/copy from its visual representation. Throwing your entire site into a single SWF is generally NOT a good way to do that. It's much easier to maintain (or re-skin or scrap) a site when your content isn't all mixed up with your code.
Hope this helps,
Scott