This config file affects all the Tomcat applications on the installation, which may be part of my problem.
Then I changed the redirect in the Connector from the Tomcat default port of 8443 to the Rhythymx SSL default port of 9443 in /Rhythmyx/AppServer/server/rx/deploy/jbossweb-tomcat55.sar/server.xml. This is what the beginning of that file looks like for me (and that also might be part of my problem):
I got wonderful fast redirects to https in the Content Explorer, but I lost my Publishing and Workflow tabs, as well as the User, Roles, and Community, and Logout options in the upper right corner of the browser. I decided that was too much to give up.
Another possibility is to front Tomcat with Apache, which could send http:cms.univ.edu/ to https:cms.univ.edu:9443. Has anyone tried either approach? This would prevent user names and passwords from being sent insecurely.
Actually, the last line of my current config is port 8443 not 9443:
14:25:43,095 FATAL [PSTransformErrorListener] javax.xml.transform.TransformerException: Error reported by XML parser
14:25:43,095 WARN [PSTransformErrorListener] javax.xml.transform.TransformerException: org.xml.sax.SAXParseException: Premature end of file.
When I try to view the banner frame only, I get
An error occurred generating HTML from XML using the "" style sheet for the request submitted by session id 85d9ba83a9339acdcf2d00313c1057071d170547.
1 An exception occurred while processing the bannerpage XML document through the file:sys_cx/bannerpage.xsl style sheet: com.percussion.data.PSConversionException: An exception occurred while processing the bannerpage XML document through the file:sys_cx/bannerpage.xsl style sheet: Error transforming the xml document with stylesheet Error reported by XML parser; Line#: -1; Column#: -1 Error reported by XML parser; Line#: -1; Column#: -1
If your only concern is to force users to login over https to avoid clear text uid/pwd transmission, but are not concerned about encrypting the rest of the communications, the product has built in support for this.
Edit the user-security-conf.xml file found in the rxapp.war\WEB-INF\config\user\security directory. Set forceSecureLogin=“yes” on the root securityConfiguration element. This will automatically redirect any http requests to the login form over https, and then after that form is posted, the user is redirected to the originally requested url (usually just the Content Explorer) over the originally requested protocol.
So if a user requests http://myserver:9992/Rhythmyx, they will be reditected to the login form over https, and then back to the http://myserver:9992/Rhythmyx after authentication so that the login credentials are exchanged encrytped.
Jay, that’s great. I do get the redirect now that I’ve made your change, but after logging in at https://myschool.edu:9443/Rhythmyx/, it returns me to the login page as if I hgadn’t entered my uid/pwd. Yet I am logged in after that - I can reach Content Explorer if I refuse to login again and simply enter the appropriate URL.
I’ve done some testing and I can only reproduce your problem if I login to Rhythymx, logout, and then try to log back in using the same browser. Have you completely removed the previous configurations you attempted (as described in this thread)?
However, this feature does not seem to be working correctly in another way - if I test this with a new browser instance, I get redirected to https for the login form, then I get redirected back to http for the community login page which in my case automatically redirects to the applet, and at that point the Content Explorer applet page is loaded over https again, not http as it should.
If you start from a fresh browser instance, do you see the same behavior?
Yes, I see the same behavior. I removed the security-constraint from /Rhythmyx/AppServer/server/rx/deploy/jbossweb-tomcat55.sar/conf/web.xml and I changed all references from 8443 to 9443 in /Rhythmyx/AppServer/server/rx/deploy/jbossweb-tomcat55.sar/server.xml. I hope that was correct. I didn’t yet add proxyName and proxyPort to the config.
Ah yes… if it’s possible to configure IE not to display those warnings, that would be nice. I tried telling it not to “display the nonsecure items” and I couldn’t tell any difference, so I don’t know what they are. All the image URLs on the page begin with https except for a javascript(void).
I’ve gotten both Jay’s and Dave’s suggestion to work together now. For some reason, Dave’s suggestion didn’t redirect for me by itself. I removed proxyName, which might have done something, and changed proxyPort=“9443”.
Also, we’d recently changed our development server name, and Jay’s suggestion is currently redirecting me to the old server name from the new server, even when I’m already using an SSL port in the URL. The production server worked fine without Dave’s additional configuration. Otherwise, things are working much better now.
I get the same complaint in IE 8 beta. Some of my recent cross-browser testing makes me think the problem is related to Java, but it might be caused by source code like this (from the Workflow tab), in which the “http:” is hard-coded:
IE users can disable that message by changing their settings in Tools > Internet Options > Security > Custom Level > Miscellaneous > Display mixed content. By default, it’s set to Prompt, so reset it to Enable. Disable would probably work for Rhythmyx, though - I don’t see any loss in functionality. But expecting users to reconfigure their browsers is probably not a long term solution.
In doing further testing…this configuration does not work for us ( It has about 98% functionality).
We have found with this configuration some of the menu options do not work.This is what we have identified so far:
-Admins can’t purge publication logs under the publishing tab.
-End users can’t workflow items
After looking at the code in the rxlogin.jsp I was able to add some custom processing so we can single-sign-on end users into the CMS directly from our schools portal.
This means we will no longer go the ssl route.
[QUOTE=barre57e;3973]In doing further testing…this configuration does not work for us ( It has about 98% functionality).
We have found with this configuration some of the menu options do not work.This is what we have identified so far:
-Admins can’t purge publication logs under the publishing tab.
-End users can’t workflow items
Good tip, thanks. We’ve since moved on to just the log in being done via HTTPS, so this isn’t a problem anymore, but good to know it wasn’t just a random error.
Something I’ve never come across in 15 years of HTML, is that apparently you can use something like…
src="//hostname/mypage.html"
…and it will use http if the page it is on has been served over http, https if the page has been served over https, and possibly ftp if the page has been served over ftp.
I don’t know what this technique is called to be able to search for it in, I guess, the IETF RFCs. I’m not sure if it would work in this context, but might be worth a try if you say want the entire session to be done of HTTPS, but also allow people to log in without encryption.