Hi mkelcu -
This is tomcat specific advice: when I run clearspace (or any webapp) as the root context, I have to replace the ROOT webapp in tomcat/webapps. If you just deploy the war, the container will really really want to make the context /clearspace rather than /. There's probably a way not to have to do this, but if I ever knew it, I have forgotten it, and this is what I do. In our internal deployment, we just make the ROOT webapp a symbolic link to a dir where the war is extracted.
I'm about to dive into this on our extranet deployment of Clearspace 2.0.1, both for proxying the www.example.com/ root to www.example.com:8080/clearspace and for doing SSL encryption through Apache to protect the site. Any positive outcomes from your experimentation?
I think i hit a similar problem. Here is my setup, so you can figure out if you are in the same kind of situation
A reverse proxy gets HTTPS connexions and communicates with the tomcat+clearspace server using HTTP. When the clearspace issues a HTTP redirect (eg 302) (eg to redirect to login page), the HTTP location is set to the tomcat hostname and port, and to HTTP instead of HTTPS.
browser—-https—->port 443 reverse proxy —-http—-> tomcat+clearspace port 8080
I solved my problem by adding these options to the HTTP connector in server.xml of Tomcat:
I also set my jiveURL="https://yourwebsitename.typicallythereverseproxyname.com/clearspace_community" , but it is used only for the rss, blogs and not much
Here you can find some info more related to Apache: http://tomcat.apache.org/tomcat-5.5-doc/config/http.html#Proxy%20Support
and a short howto : http://short-howtos.com/squid-indicate-originserver-https-reverse-proxy
Note that i did not do any extensive testing of this, but it seems to work at least for the initial login redirect