I am about to build a web application and I want to allow other developers extend it with their own applications.
Should I do this with iFrames like Facebook?
Is this a good practice?
Are there other alternatives that let other developers extend my application (that is for the user it looks like it's from my application).
To be specific:
I want developers to be able to code applications that is embedded on my web application. Eg. if I have a file on my application they could provide a way for the users to interact with that file. Maybe a "preview" application that let the users preview the file.
Another application might draw a mindmap tree view of all the user's files.
What is the best way of doing this?
iFrame + Restful API on backend for data exchange?
Let them insert javascript on backend + frontend + html + css on my web application?
Other alternatives?
If you meant "embed" rather than "extend" and you just want people to drop a little box on a page and that's it, then an iframe should be fine.
However, if you want two-way communication or mashupability — rather than "opaque blob of HTML and hope for the best" communication — then a JavaScript or REST API might be a better call.
More specifics would make for an easier answer. If the functionality you need is on the level of an embedded ad or stackoverlflow flair then an iframe would work, if the functionality is more along the lines of a Google Map then an API of some sort would work better.
It depends on what you mean by "extend". When you use iFrames with 3rd parties, presumably vended from different domains than the host page, then you are constrained by cross-domain issues and cannot interact with the contents of those iFrames. If that's not an issue for you, then you can go ahead and try that strategy, but I can't see how merely adding iFrames without interopability is "extending" your web application.
Related
I am making a website which allows users to create ads, apps, etc. Think of it like Adsense for ads and Facebook apps for apps.
So, I am allowing the users to create ads or apps the way they want using either tools provided or through their own HTML code which will then be rendered as ads and apps in the website for other users to see.
My Problem:
1) When I allow users to add their own code which is to be embedded in the website, am I exposing my website to security risks? (I am not sure but I think they will be able to add some malicious code in javascript)
2) If I think of isolating the embedded code from rest of the website using Iframes, will that be a problem or is there any better way to do this?
What I want to achieve:
Some sort of element to render user generated custom HTML, CSS code in a website without affecting security.
Depending on the types of ads or apps they are allowed to make and what languages they can use you can be at risk in a few ways especially if other users can see it.
Let's assume they can use html and they add this code
<img src='fake.jpg' onerror='alert("xss");'>
In this scenario all of your users who can see this are exposed to an xss attack. If this is the case, see this post -> How can I allow my user to insert HTML code, without risks?
I would not recommend server side languages and while iframes may inherently be more secure, the same thing applies, especially if your domain hosts the iframe. If the iframe src is on the same domain as where the iframe is displayed you can toss out any security iframes may pretend to offer.
The best solution is to offer your own wysiwyg editor where your special codes are turned into html code. Allowing JS is going to be something you want to consider doing in a safe way, this could be done through creating your own wrapper (even wrapping a series of jquery functions in a wrapper) and including them in your wysiwyg cleverly.
I want to open any custom application say VLC Player or any other installed application in the system through HTML page. I have tried WScript.shell technique but no luck.
You can't do this in general. There's no way to open any arbitrary application from a webpage. Here are some scenarios where it's still possible. One possibility: some programs have protocol handlers associated with them, and those can be launched through a link or via javascript (e.g. window.location = "someprotocol:path?argument=value"). I don't think VLC (to use your example) is among them, however.
There might be a more useful solution if you limit yourself to a particular browser/OS.
I have a dillema of the way web widget apps should be implemented.
Scenario is that website A should present content of website B as a widget. Lets say that the widget content type is webshop, so all that a webshop can offer will be inside a widget. Items, cart, login, checkout, etc, but no redirection to other site. Window stays on Site A.
There is no interaction between websites. No data passed from one to another.
Technologies that will be used are .net Web API as server side, angular as js framework, and all will be implemented as single page app.
I see two scenarios.
Website B will be embeded in website A through iframe
All js, css, and initial html will be somehow embedded into website A and make calls to WebApi services.
I'm not clear how 2 should be done. Giving some bundles of JS, CSS, and HTML to Site A to implement is kind of overhead for both me and site A, and I see a lot of troubles there. Maybe it all should be injected dynamically somehow.
On the other side..iFrame...this seems like a right scenario for use of iframe, but is it?
Any thought is appreciated.
I wrote a simple web server that takes the public link to a google document containing image urls and names and outputs a print-friendly HTML photo directory with its contents.
I created it for a volunteer organization that I will no longer be able to stay involved in. I need to pass on the ability to generate that directory to my successor.
I'm not confident that I can trust myself to maintain that web application for the long term the organization needs. I'm hoping that instead I can change it to a self contained program, that members of the org could email around to whoever needed to generate the directory.
My first thought was to make a .html file the could open in a browser but I can't download the CSV data from google with Ajax, because it is cross domain. After googling there doesn't seem to be a way around this.
Is there a straightforward framework? I would guess I could do it with Adobe AIR, but I'd prefer something that simply removed the cross domain security feature.
I could take the time to embed a UIWebView into a Mac app, but since I want to write the app primarily in HTML, I'd have to create a bridge to let the web view make a cross domain request anyway right? Also it's not cross platform.
Any other ideas? How can I package my app as a desktop application instead of a web service?
You can get around the cross domain XHR using flash. CrossXhr can do it from apps served by regular http servers. I've never tried it with a static, file-served webapp. Follow the instructions here:
http://code.google.com/p/crossxhr/wiki/CrossXhr
I'm just looking for clarification on this.
Say I have a small web form, a 'widget' if you will, that gets data, does some client side verification on it or other AJAX-y nonsense, and on clicking a button would direct to another page.
If I wanted this to be an 'embeddable' component, so other people could stick this on their sites, am I limited to basically encapsulating it within an iframe?
And are there any limitations on what I can and can't do in that iframe?
For example, the button that would take you to another page - this would load the content in the iframe? So it would need to exist outwith the iframe?
And finally, if the button the user clicked were to take them to an https page to verify credit-card details, are there any specific security no-nos that would stop this happening?
EDIT: For an example of what I'm on about, think about embedding either googlemaps or multimap on a page.
EDIT EDIT: Okay, I think I get it.
There are Two ways.
One - embed in an IFrame, but this is limited.
Two - create a Javascript API, and ask the consumer to link to this. But this is a lot more complex for both the consumer and the creator.
Have I got that right?
Thanks
Duncan
There's plus points for both methods. I for one, wouldn't use another person's Javascript on my page unless I was absolutely certain I could trust the source. It's not hard to make a malicious script that submits the values of all input boxes on a page. If you don't need access to the contents of the page, then using an iframe would be the best option.
Buttons and links can be "told" to navigate the top or parent frame using the target attribute, like so:
This is a link
<form action="http://some.url/with/a/page" target="_parent"><button type="submit">This is a button</button></form>
In this situation, since you're navigating away from the hosting page, the same-origin-policy wouldn't apply.
In similar situations, widgets are generally iframes placed on your page. iGoogle and Windows Live Gadgets (to my knowlege) are hosted in iframes, and for very good reason - security.
If you are using AJAX I assume you have a server written in C# or Java or some OO language.
It doesn't really matter what language only the syntax will vary.
Either way I would advise against the iFrame methods.
It will open up way way too many holes or problems like Http with Https (or vice-versa) in an iFrame will show a mixed content warning.
So what do you do?
Do a server-side call to the remote site
Parse the response appropriately on the server
Return via AJAX what you need
Display returned content to the user
You know how to do the AJAX just add a server-side call to the remote site.
Java:
URL url = new URL("http://www.WEBSITE.com");
URLConnection conn = url.openConnection();
or
C#:
HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create("http://www.WEBSITE.com");
WebResponse res = req.GetResponse();
I think you want to get away from using inline frames if possible. Although they are sometimes useful, they can cause issues with navigation and bookmarking. Generally, if you can do it some other way than an iframe, that is the better method.
Given that you make an AJAX reference, a Javascript pointer would probably be the best bet i.e. embed what you need to do in script tags. Note that this is how Google embed things such as Google Analytics and Google Ads. It also has the benefit of also being pullable from a url hosted by you, thus you can update the code and 'voila' it is active in all the web pages that use this. (Google usually use version numbers as well so they don't switch everyone when they make changes).
Re the credit card scenario, Javascript is bound by the 'same origin policy'. For a clarification, see http://en.wikipedia.org/wiki/Same_origin_policy
Added: Google Maps works in the same way and with some caveats such as a user/site key that explicitly identify who is using the code.
Look into using something like jQuery, create a "plugin" for your component, just one way, and just a thought but if you want to share the component with other folks to use this is one of the things that can be done.