writing applications for third-party usage

[akitchin]

at the moment, i'm interested in a project which will be geared towards allowing third-party access to a web application.  it will reside on one server, and should allow several users (from different servers) access to use the app in their own site.  the issue comes in where transparency is concerned - we want the app to be as transparent as possible, ie. it should appear as the user's own.

 

i've thought of several ways of doing this.  one was iframes, which frankly i don't want to touch as i'm not a huge fan.  the second is simply a direct link to the central server, with a redirect / link back to their site.  this removes transparency, as it can only be so customized (and the address is clearly not transparent).  finally, i thought of an API approach.  the reason i'm not favouring that is because the majority of users will be non-programmers, and APIs strike me as being one hell of a lot of work.

 

anybody care to weigh in on other methods, or pros/cons to these ones?  has anyone else had to program an app like this?

[roopurt18]

Your situation is very similar to mine actually.  We have a web product for home builders and we support multiple clients on one server.  Each of our clients is given their own database.

 

Our URLs look like:

www.ibswebview.com/wv/<client>

where client is the client's name and maps to an appropriate database.

 

We also use mod_rewrite to map all requests through a single entry point which handles the URI parsing and database connection before passing off control to the proper segment of the program.

 

We provide our clients with an interface in the application to customize the logo, banner, and CSS of the site so to some extent they can match the our site to their own.  Of course, the transition isn't entirely transparent to users.

 

Recently, I added functionality that allows our clients to embed our site into their own using an iframe.  The src attribute of the iframe should be like the URL above but with an appended /IFrameRender/.  I've also added Javascript to the page load to detect if it is sitting within an iframe.  In either of these cases, the header and footer of our site are not rendered so all that appears in the iframe is the content.

 

Providing a direct link or helping our clients assist in setting up the iframe approach seems to be satisfactory for most people.

 

You can see an example of our site here:

http://www.ibswebview.com/wv/beta

Username: beta1

Password: beta1

 

And here is the same page served in an iframe:

http://www.rbredlau.com/test/ponderosa.html

 

Hope that helped.

[akitchin]

thanks, that was helpful.  the more i thought about it, the more it seemed a linkback or iframe would be most suitable, and yours seems to look just fine.  i guess iframe isn't an issue, provided it's deployed correctly.  are you using a third-party base and building off that, or is this thing entirely custom?

[roopurt18]

The application is entirely custom.  I inherited this project last March when I was hired for my first programming job.  Since our program is basically "outsourced" from our client's perspective and also because our clients are homebuilders dealing directly with home owners and home buyers, allowing our clients to brand the product has always been a concern.

 

Initially when I inherited the project, we allowed customization of the following:

top left logo

top right banner

top menu

the entire page header (logo, banner, menu)

CSS

various text blocks within the site (login page, home page, contact page, etc.)

 

However, I noticed that the majority of our clients only ever changed the login page (because we have that stupid CRT monitor on it), the logo, and the banner.  Some of them have updated the CSS to be similar to their regular company web pages, but like I said in my OP the transition was never very seamless.

 

So a few months ago the idea hit me we could probably allow them to just embed our application into their current homepage via iframe and only recently did I have time to look into the actual implementation.  There are some hurdles to overcome dealing with Javascript and cookies though.

 

I'll quickly explain the Javascript problem first.  We didn't want any scroll bars on the iframe which means the iframe has to change heights depending on the size of the content.  This is can be tricky to set up for newer JS programmers, but is fairly straight forward when the site in the iframe is on the same domain as the container site.  However, in our situation, the sites are hosted by different domains.

 

What I had to do in this scenario was give our clients an administrator setting where they can specify a script hosted on their domain.  The script is very simple, it takes a height URL parameter and outputs a small HTML document with some Javascript.  The Javascript grabs the iframe via document.getElementById("wvIFrame"); and sets the iframe.style.height equal to the height passed via the URL.

 

Then I added an onload page handler to all of the pages coming out of our site if its hosted in an iframe.  This onload handler calculates the content height and then uses the DOM to create an invisible iframe and call the resizing script hosted by our client's domain.  This allows our application to pass the height of its content back to our client and because the client page is on their domain it has access to the iframe in the top level container page.  Once the dynamic iframe is loaded it is destroyed to avoid having multiple invisible iframes hanging around.

 

The last issue deals with cookies.  Our site uses sessions to track user activity which means cookies.  However, when visitors to our clients home pages are viewing our application in the iframe, the cookies are considered third party because of the differing domains.  Depending on the user's browser security settings, it may or may not accept these cookies.  There are two ways to combat this problem.

 

The quick and easy solution, the one we took, is to recommend that users set their browser to always accept cookies from our server (ibswebview.com).  The second solution is to set up a privacy policy on our site explaining how the information in the cookies is used.  I read up on this a little and theres a little extra you have to do but what it boils down to is the typical default setting for IE is to accept third party cookies only if a privacy policy exists.  I imagine I'll be doing this at some point in the future.