Since first posting this I've been in discussions with a webhoster after explaining to them the behavior that we were seeing with a Jetspeed portal. After some investigation it appears that this may not be a Jetspeed-1 problem after all but due to the way in which webhosts setup apache, rewriting and servlet containers especially in shared host environments. After working with the webhost for about a week we were finally able to get things configured to where any type of permissible access to the webapp would produce consistent and correct results for jetspeed portal sites. This included http://www.portalsite.com, http://portalsite.com, http://portalsite.domain.com, and http://domain.com/portalsite. All these mappings now keep the url consistent for all accesses. So now even active-x controls load from the same domain and don't encounter the cross-site scripting security violations that they were previously. So if you are having any of these types of issues that we had run into I would suggest that you contact your webhost and have them check how they have their apache and servlet container configurations and mappings setup for your portal sites.
Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > One of the things that my users and I have found when accessing > jetspeed-1 portals is that they modify the accessing URL which can > provide for some strange results. For instance if I have a domain > named 'domain.com' and a user accesses the portal using > http://www.domain.com everything works fine. But if the user > accesses > the portal with http://domain.com they get access denied errors for > some of my activeX controls that I load because apparently jetspeed > is > changing some of the accesses to add the 'www' in front which makes > the > browser think that it's a cross-domain scripting access and the > browser > security refuses to load the controls. Secondarily, the same type of > thing applies when I try to access the portal site using the sites IP > address. Instead of all accesses showing up as > http://111.222.333.444/... they are converted back into the > http://www.domain.com/... name style. This doesn't cause the > cross-scripting security problem but what it does do is prevent me > from > setting up a www.domain.com locally in my own network for development > and testing and then using the real portal's IP to test the real > domain > once we push code up. I've done this for years when developing sites > with no problems except for jetspeed. When the IP style of accesses > is > converted back by jetspeed to the name style then when we test the > real > site by using it's IP address as jetspeed is converting the access to > name-style it ends up resolving the access to our internally mapped > test address which screws things up. I think jetspeed should > consistently use whatever form of URL access that the user used to > access the portal and maintain that form consistently throughout the > session. > > > > ===== > Gerry Reno > mailto: grenoml at@ yahoo dot. com > (if mail bounces please retry later - spam rapidly fills up mailbox) > > __________________________________ > Do you Yahoo!? > Free Pop-Up Blocker - Get it now > http://companion.yahoo.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > ===== Gerry Reno mailto: grenoml at@ yahoo dot. com (if mail bounces please retry later - spam rapidly fills up mailbox) __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
