Forum OpenACS Development: Ssl application layer issues

Posted by Andrew Grumet on
We're running into some application layer issues with SSL installed, and wonder if anyone else has thought about them:
  • If the login page is served over SSL, embedded graphics do not materialize. (The cause is known: sec_handler redirects any https request for which ad_login_page is false.)
  • With SSL installed, the code in packages/acs-tcl/tcl/admin-init.tcl results in about 9,000 calls to ad_parameter (once for each mounted package). This in turn adds about 90 seconds to the restart time on our hardware.
  • We would like to protect user passwords, but don't need to protect most other system data. This approach will not protect the user's login rights---login and/or session cookies---but it WILL protect their password, which may be used on any number of other systems. Applying this sort of protection is fairly straightforward but will require editing several files---user-login.tcl, user-new*, password-update*.
We can hack up solutions for these, but the issues seem general. Have you run into these issues and written code to solve them?
Posted by C. R. Oldham on
I tracked this down and sort of documented what I was seeing in this thread:

I still think it's a bug but haven't gotten back to it to see if I can fix it without compromising the security model.

Posted by Andrew Grumet on
Thanks for that pointer. I think the solution is to consolidate system graphics into a single directory (active discussion in this thread: , and modify the security system to allow viewing of those graphics by non-logged-in users over https.

We are still mulling over the other two issues above: admin-init inefficiencies and password protection. The quick hack solution is to comment out the big "for all mounted packages" loop and add individual registrations of ad_restrict_to_https for some key pages.

Posted by Don Baccus on
I think admin-init could first check for the nsd.tcl value (still supported for legacy reasons):
ad_parameter RestrictToSSl acs-subsite
followed by a modified form of the query that joins explicitly with the parameters table to only process those rows that have the parameter set on.  The ad_parameter call inside the loop would then disappear.  This would be fast, I'm sure.
Yes, this breaks abstraction but sometimes for performance reasons we can live with doing this, I think.
<p>Actually a slight improvement abstraction-wise would be to write a new proc in defs-procs that returns a list of package_ids for all packages which have a particular parameter set to a particular value.  This proc could be grouped with the various procs that deal with parameters (including ad_parameter itself) so would move the dependency on the apm table structure to a common place.
<p>Then admin-init itself wouldn't be dependent on the apm datamodel.
<p>It sounds like a solution for the graphics issue's been found.
<p>As far as restricting logins only ... maybe another "RestrictLoginToSSL" parameter local to acs-subsite and looked at by the login pages themselves would be OK?  The current filter value ("admin/*") that RestrictToSSL defaults to doesn't cover the login pages, and usually one doesn't want to set the filter to "/*" (!) ...
Posted by Andrew Grumet on
I like both suggestions (list of package_id's, RestrictLoginToSsl), which are improvements over our current hacks.  We'll code these up at some point in the next week or two and email them to the appropriate maintainers.