portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Huber <shub...@jahia.com>
Subject RE: Iframe Portlet with Authentication for external website
Date Fri, 12 Sep 2003 11:50:39 GMT

I actually went very far in the proxy area in a web application I 
developped. Some websites go out of their way of making sure no automated 
program can log into their systems, mostly to avoid web clippers to avoid 
publicity which makes their business.

Anyway just some of the areas of problems I have encountered with even 
basic form authentification :
- most serious sites generate unique IDs for transactions. If you just 
remember the POST data, it is probably not  enough because you have not 
gone through all the steps required by the remote server, or you are using 
a recorded invalid transaction ID
- some login procedures now heavily depend on Javascript executed by the 
client browser. Yahoo mail is an example where the password is actually 
crypted by some javascript code before being sent by the form. This is 
really neat because it gives them some extract security, without requiring 
all the logins to go through SSL.
- login forms can change, and the name of the parameters may vary (although 
this is more theoretical and I haven't seen it happen that often).

   Serge Huber.

At 01:00 AM 9/12/2003 -0400, you wrote:
>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:
>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
> >
> >
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server

View raw message