I've made a tool take people can use and its made in Javascript.
They generate the code and then paste it into their webpage code.
I am just wondering how would I go about making it work in forum posts, or other site posts or do the websites normally block this sort of thing?
Would it be possible to convert it for social media sites also? Like have it so the users can interact with it inside posts? Thanks!
So first a warning: DO NOT DO THIS THE WAY THAT YOU HAVE IT RIGHT NOW
You are forcing people to inject a script directly into their website directly from your servers. This script sets and users global variables and can break other things. I would be very very angry if someone added something like this to a site I ran. For example your script creates a function called clicked() in the global scope. What if the site already had a function named that on it? Then all of a sudden that site breaks. It is possible to do this without these issues (see how twitter buttons work for example) but it still has limitations.
Doing this in the way you have it set up looks to another site exactly like an XSS (Cross Site Scripting) attack so no, you cannot do this in forums/etc - they specifically disallow it.
Occasionally a forum might allow iframes (they have much better security for the including site). In your case using iframes would actually be a much cleaner solution. Simply have them include an iframe that points to your site. Your site then (using php, .Net, node, perl, whatever server scripting language you want) would reply with the markup that you want. You can pass the parameters you want as parameters in your url.
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.
I'm trying to find a solution for the following situation:
I've a web application made of HTML, javascript, AJAX, ad so on.
I want users to contribute to my application/website creating plugin that will embedded in it.
This plugin will be created using similar technologies (ajax, HTML, etc) so i need to allow plugins to run their own javascript code.
Each plugin will work in a page that will contain some user information and the plugin (like old fbml facebook applications)
The problem is that in this way the plugin can also made calls to get users information. (because since plugin's code is embedded it's domain will be the same of the main website, and the code will be entirely on my website).
So the question is: how can I avoid it and have a precise control about what information a plugin can get about the user?
The plugin will not be checked and can be changed anytime, so reading all the plugin code is not a solution.
I'm open to any proposal, possibly easy and effective, and possibily not putting the whole plugin in a iframe.
--
EDIT:
How did facebook do when there was the old way to create applications? (now it's only iframe, but there was FBML application way, how did they get this secure?)
Have you ever heard of exploits allowing arbitrary code execution. Which is one of the most dangerous attacks ?
Well, in this case you are explicitly and willingly allow arbitrary code execution and there's almost no way for you to sand box it.
1) You can run the "plugin" within an iframe from a different subdomain to sandbox it in there, as you've mentioned. This way plugin can't reach your cookies and scripts.
Note that, if you want the plugins to communicate with your services from this domain, then it will be cross-domain communication. So you either need to resort to JSONP or use new cross domain access control specifications. (i.e. return appropriate headers with your web service response -- Access-Control-Allow-Origin "plugins.domain.com")
2) Create your own simple scripting language and expose as much as you want. This is obviously tedious, even if you manage to do that, plugin developers will endure a learning curve.
Facebook had their own "JavaScript" coined FBJS which did the sandboxing by having control over what could run.
Without a juicy backend, this really limits the impact of your script.
However you still have to worry about DOM based xss and Clickjacking
It's 6 years later, but I feel it's important to provide a modern solution to this. The new(er) sandbox attribute can be used to limit the capabilities of an IFrame.
A simple implementation of this system would allow only the allow-scripts permission to the IFrame, perhaps with a simple JS file which would be included along with each plugin containing a few custom library functions.
In order to communicate with your HTML page, you would use postMessage. On the plugin end, a library like I mentioned above could be used to transfer commands. On the user side, another system would have to validate and decode these requests then execute them.
Since a sandboxed IFrame doesn't have cross origin capabilities, it cannot directly modify the page. However, this also means the origin of the postMessage can't be verified, so some sort of code would have to be created for security reasons.
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
I'm connecting to a web site, logging in.
The website redirects me to new pages and Mechanize deals with all cookie and redirection jobs, but, I can't get the last page. I used Firebug and did same job again and saw that there are two more pages I had to pass with Mechanize.
I took a quick look at the pages and saw that there is some JavaScript and HTML code but couldn't understand it because it doesn't look like normal page code. What are those pages for? How they can redirect to other pages? What should I do to pass these?
If you need to handle pages with Javascript, try WATIR or Selenium - those drive a real web browser, and can thus handle any Javascript. WATIR Classic requires either IE or Firefox with a certain extension installed, and you will see the pages flash on the screen as it works.
Your other option would be understanding what the Javascript on the offending page does and bypassing it manually, but that seems onerous.
At present, Mechanize doesn't handle JavaScript. There's talk of eventually merging Johnson's capabilities into Mechanize, but until that happens, you have two options:
Figure out the JavaScript well enough to understand how to traverse those pages.
Automate an actual browser that does understand JavaScript using Watir.
what are those pages for? how they can redirect to other pages. what should i do to pass these?
Sometimes work is done on those pages. Sometimes the JavaScript is there to prevent automated access like what you're trying to do :). A lot of websites have unnecessary checks to make sure you have a "good" browser, so make sure that your user_agent is set to something common, like IE. Sometimes setting the user_agent to look like an old browser will let you get past without JavaScript.
Website automation is fun because you have to outsmart the website and its software developers, using multiple strategies. Like the others said, Watir is the best tool for getting past JavaScript at the moment.