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).
Regards, 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: https://username:[EMAIL PROTECTED]/thepath/ This how the http://cvs.apache.org/viewcvs/jakarta-jetspeed/src/java/org/apache/jetspeed/ portal/portlets/BASICAuthIFramePortlet.java?rev=1.2&content-type=text/vnd.vi 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 credentials.) 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. WSRP Cocoon has a web service proxy component
I hope you find this helpful.
> -----Original Message----- > From: Rajendra Kadam [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 11, 2003 9:14 PM > To: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- - www.jahia.org : A collaborative source CMS and Portal Server
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
