CiviCRM Community Forums (archive)

*

News:

Have a question about CiviCRM?
Get it answered quickly at the new
CiviCRM Stack Exchange Q+A site
This forum was archived on 25 November 2017. Learn more.
How to get involved.
What to do if you think you've found a bug.



  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Using CiviCRM »
  • Using Core CiviCRM Functions (Moderator: Yashodha Chaku) »
  • CiviCRM using deprecated HTTP_request package, leading to single sign on problem
Pages: [1]

Author Topic: CiviCRM using deprecated HTTP_request package, leading to single sign on problem  (Read 760 times)

ericaack

  • I’m new here
  • *
  • Posts: 8
  • Karma: 0
CiviCRM using deprecated HTTP_request package, leading to single sign on problem
November 29, 2012, 10:02:53 am
I recently upgraded a site from Drupal 6 to Drupal 7 and from CiviCRM 3.3 to 4.2, then moved the site to a new server. Both the old and the new servers use Cosign for single sign on. The new Drupal environment is multisite, which was not the case before. All the data seems to have come over correctly, but I've been having trouble with the dashlets. When I go to the home page, instead of dashlets displaying, I get text saying "Found. The document has moved here." The word "here" is a link to our single sign on service (Cosign) with a redirect to the dashlet report:

https://weblogin.umich.edu/?cosign-ginsberg&https://ginsberg.umich.edu/civicrm/index.php?q=civicrm/report/instance/34&reset=1&section=2&snippet=5&context=dashlet

So if you strip off the beginning of the URL up until the second "https", you see an unformatted view of the dashlet's report.

Normally, the HTML for the dashlet gets cached in the civicrm_dashboard_contact table is a snippet that starts with a <div>. What I'm getting in the database instead is the full text of an HTTP 302 redirect:

Code: [Select]
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://weblogin.umich.edu/?cosign-ginsberg&amp;https://ginsberg.umich.edu/civicrm/civicrm/report/instance/29?reset=1&amp;section=2&amp;snippet=5&amp;context=dashlet">here</a>.</p>
<hr>
<address>Apache/2.2.14 (Ubuntu) Server at ginsberg.umich.edu Port 443</address>
</body></html>
It is possible to trick CiviCRM into showing the dashlets correctly for a little while by setting the "content" field of the civicrm_dashboard_contact table for that contact to Null and then doing some magic series of refreshes and cache clearing (I'm not sure exactly what is required -- it just starts to work sometimes).  But by the next day the dashlets are always back to showing the redirect. The developer/systems administrator who set up the multisite Drupal environment we moved to says that that redirect is triggered whenever an HTTP rather than HTTPS URL is requested. He believes that the problem is that CiviCRM uses the deprecated HTTP_request package, rather than the newer HTTP_request2 package, and that the reason the dashlets used to work is that the old environment must have used an older version of Ubuntu. Here is what he wrote:

Quote
I know the issue is coming from the getServerResponse method in the CRM/utils/system.php. It is firing off a server side request using the HTTP_Request package, which will not work with Cosign. I've already tried several URL locations to turn off cosign in an Apache directive, but the URL is being rewritten to a generic /?q=url. ... The way CiviCRM handles retrieving the html block is unorthodox in the first place. Using a server call to get content from a local data store is a bad hack. The package it uses to do this (HTTP_request) is old and deprecated in favor of HTTP_request2. I can't integrate that myself as its wrapped into Civicrm and would take a lot of work. The old code is trying to pass session info during the call, but it is wonky and it sometimes works and other times fails, which is why we're seeing intermittent success.

The steps he took to get Cosign to work with CiviCRM are described here:

Quote
On other sites, we have successfully turned off Cosign by default, and then turned on for specific directories. Unfortunately, the opposite is looking impossible. Cosign fires too early in the process and forces the redirect to happen. I've tried a bunch of ways around it – directory and location directives, httaccess, mod-rewrite in various combinations and firing order – and none will prevent Cosign from taking control before we can turn it off. I even tried keeping in off by default, but Apache doesn't allow exclusionary regex (only load Cosign if NOT report/instance) on the LocationMatch directive, so that idea failed too.

I have two questions. First, is the other developer's diagnosis correct that the problem is caused by HTTP_request? Second, does anyone have any idea how to work around this?


« Last Edit: November 29, 2012, 10:06:55 am by ericaack »

JoeMurray

  • Administrator
  • Ask me questions
  • *****
  • Posts: 578
  • Karma: 24
    • JMA Consulting
  • CiviCRM version: 4.4 and 4.5 (as of Nov 2014)
  • CMS version: Drupal, WordPress, Joomla
  • MySQL version: MySQL 5.5, 5.6, MariaDB 10.0 (as of Nov 2014)
Re: CiviCRM using deprecated HTTP_request package, leading to single sign on problem
November 29, 2012, 10:28:21 am
One thought, which may or may not help move things along. You can't keep a session when switching from https to http or from http to https, so that may figure in here in somewhere. Make sure that the base_url in civicrm.settings.php, settings.php, and in the Administer > System Settings > Resource URLs all have the same protocol, either https or http. I also am guessing session timeout from one day to next may be a cause of the failure the next day. Check if the sessions had a timeout of 0 (never) on the old system and a day on the new system.

I'm not convinced upgrading the HTTP_request package will make much difference, but it might.
Co-author of Using CiviCRM https://www.packtpub.com/using-civicrm/book

Parvez

  • I post occasionally
  • **
  • Posts: 91
  • Karma: 7
Re: CiviCRM using deprecated HTTP_request package, leading to single sign on problem
December 03, 2012, 04:12:38 am
I'm with Joe on this one, switching HTTP/HTTPs within a site normally has these sorts of symptoms i.e. the session getting lost or confused.

ericaack

  • I’m new here
  • *
  • Posts: 8
  • Karma: 0
Re: CiviCRM using deprecated HTTP_request package, leading to single sign on problem
December 03, 2012, 12:33:05 pm
The HTTP_request package really does seem to be the culprit, in that it is not properly maintaining the session. Here's what the developer/sysadmin had to say:

Quote
Normally, the only thing to cause Cosign to redirect to the login server is calling http on a page that is access protected. But in this case, after digging in deeper, it turned out Civicrm uses the unusual method of a server-based HTTP call using the HTTP_Request package. The assumption now is that the HTTP_Request package is not properly retaining the session.

The workaround was to change the <Location> directive so that we only redirect to Cosign from the /civicrm/usr/login page. Going to any other url just gives you an access denied message.
Pages: [1]
  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Using CiviCRM »
  • Using Core CiviCRM Functions (Moderator: Yashodha Chaku) »
  • CiviCRM using deprecated HTTP_request package, leading to single sign on problem

This forum was archived on 2017-11-26.