portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Reilly" <tim.rei...@consultant.com>
Subject RE: Iframe Portlet with Authentication for external website
Date Fri, 12 Sep 2003 05:00:19 GMT
I'll try to share my understanding of the 3 general methods available to
bring remote website content into the portal (pertaining to straight http
request/response) There are many other ways such as WSRP, etc, but that's
not related to your question I don't think:

** Client/Browser technology:
The BasicAuthIFramePortlet falls into this category. This sounds closest to
what you are looking for, I think.
The iframe portlet generates the markup for creating the iframe html tag
within the portlet window.

Frames, and iframes (and ilayer for earlier Netscape) can be thought of as
chromeless browser windows embedded in the window.document of a parent
window. So anything you could do within a html frame/frameset as far as
single sign-on is possible.

Two possible methods are:
1) the initial url parameter to the iframe is a url to a document that you
create - use javascript in the document to post a login form to the target
website's login action url. An example page might look like:
      <title>Self posting page</title>
   <body onload="document.forms[0].submit()">
	<form action="https://www.myformsecuredsite.org/loginProcess.do"
		<input type="hidden" name="username" value="yourusername">
		<input type="hidden" name="password" value="secret">
The page loads, the form posts to the target site, and as long as the target
is not checking the http-referer or some other method to prevent folks from
doing this... then the iframe (as a normal browser window would)
communicates directly with the site.
2) If basic authentication is involved then you can login to a basic auth
protect site using a url in the form of:
This how the
ewcvs-markup works.

There are security considerations involved here because you are sending the
credentials over the network to the client (browser) to use so keep your
security requirements in mind if you use one these (at a minimum ssl enable
your portal. And realize viewing the page source will expose the
There are also the usability issues that goes along with frames and
framesets. Here I'm thinking of how users complain about hitting the refresh
button in a frame based page and not understanding why it reloaded to the
initial state. The same applies within the portal.

** Server "one-off"
The WebPagePortlet falls into this category (IMHO). This is great for
retrieving a single page of a remote website and bringing that page or page
fragment into the portal. (The new WebClipper portlet is also great for
getting part of a page) The portlet performs the task of the client/browser
from the portal server. A url connection is used to request the page. The
response to that request is added into the portal page (after parsing and
rewriting  certain elements of the response such as urls) Some manipulation
of the page is required to preserve links, images, etc. Cross domain
security might be an issue - for say cookies, scripts, objects, applets.
When the user clicks a link or submits a form the portal's window will
either be cannibalized, or you can specify that the portlet should rewrite
the link target so a new window is targeted.

** Server proxy-through
This is part of what WebPagePortlet2 aims to achieve (not yet complete last
I left off). The Safeweb free privacy service/site closed sometime in 2001
but if you ever used it - its exactly the http proxy-through that would be
needed IMO to present an entire remote site within the portal if iframes are
not in the picture. (If you're not familiar -
http://www.pcworld.com/news/article/0,aid,75063,00.asp basically it was a
http proxy web based front-end. The upper frame of the site was like a
browser address bar, the bottom frame was the 'browser' document window)

** 2 Top of my head other options:
These require the target site to make the services available.
Cocoon has a web service proxy component

I hope you find this helpful.

> -----Original Message-----
> From: Rajendra Kadam [mailto:rkadam@etouch.net]
> Sent: Thursday, September 11, 2003 9:14 PM
> To: jetspeed-dev@jakarta.apache.org
> Subject: Iframe Portlet with Authentication for external website
> Hi all,
> This is in reference to post "Iframe Portlet with Parameter
> Passing" that was posted by "Dan Elder" on this mailing
> list in month of Jun 2003.
> In that, Dan Elder has mentions  IFrame Portlet (extended
> to original one ) which can pass userid and password ( the
> one used to log into Jetspeed Portal ) to websites that
> require Authentication so that it will provide seamless
> access to protected websites too.
> Does anybody has used that Portlet to access password
> protected websites ?
> Also want to know does it makes "Basic Authentication" as
> well as "Form Based Authentication" ?
> Dan, do you have any examples that will help in
> understanding how protected websites can be accessed ?
> Thanks,
> rajendra
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message