portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul" <4jmli...@snafu.de>
Subject Re: WebPageProxyPortlet
Date Tue, 08 Apr 2003 16:26:20 GMT
Hello David,

I am new here on the list. I have tried out Jetspeed 1.4-b3 for a while. Now it 
is running at work in "test-mode" :-) (on Suse 8.1, Tomcat 4.1.18) I have found 
workmates that are also interested and some have already tested things like I 
have. I have learned that they have tried out the WebPagePortlet and 
WebBrowserPortlet. I have checked the sources and saw, that you participated 
developing them, so here a few comments. Maybe they are helpful:

The WebPagePortlet did run with a simple test page easily but more interesting 
was the WebBrowserPortlet. Key point is the URL rewriting, so that you are not 
kicked out of the portal when clicking a link or so. That makes it possible to 
combine different info sources.

> -----Original Message-----
> From: David G. Powers [mailto:jetspeed-dev@pssp.com] 
> Sent: Thursday, March 06, 2003 9:34 PM
> To: Jetspeed Developers List
> Subject: WebPageProxyPortlet

> The admin / user will set the initial page parameters including:
> 	URL
> 	default HTTP headers
> 		authorization (username/password/method)
> 		cookies

Here was a big problem. We tried to include a simple web application running in 
our LAN. It's a web interface where you type in your request and get the 
results displayed. The application is running on WAS4. The problem: WAS was not 
able to store the session and died. The engine "portal" could not talk with the 
engine "webserver". I must add that the session is important because it stores 
some user specific data. It worked with disabling the session/cookie for 
testing somehow but that's actually not a solution. :) So the session handling 
seems to be really not easy. But it would open very interesting ways and seems 
to be a necessary key feature.

> 	general config
> 		field-rename-prefix
> 		method (GET, POST)

And this is another point we stumbled across. Discussing possible use cases we 
came to the point that you maybe want to add an application with an own login. 
That brings SSO into view. So a question is, how hiding a login from the user? 
With other words: a user visits the portal... is logging in ... is using 
the "imported" web application (which has an own login and runs at a different 
server anywhere on earth) but does not need to login. :) So actually the portal 
must keep or handle the user's login information and authorize the user against 
the remote web server without any notice. Hmmm.... kind of hard to describe. Do 
you know what I mean? What do you think?

Greetings,
Paul


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message