Logging out results in blank screen and undefined function theme() error in Apache

What revisions are you using of securesite.module and securesite.inc? Just look at the top of the files for the ID line.

The notice isn't really a problem. It's the error that's causing the blank screen. This should only happen if there's a problem initializing some parts of core before securesite_init(). What version of Drupal are you using and what other contrib modules do you have installed?

Have a look at this issue; the suggested code was committed so I don’t know how much this helps.
http://drupal.org/node/119009

Your second error suggest you need to add something similar as the above URL but to the securesite_user_auth() and it would have to be for DRUPAL_BOOTSTRAP_FULL.

Something like

  global $base_url;
  include_once('securesite.inc');
  $edit = isset($_POST['edit']) ? $_POST['edit'] : '';
  $securesite_enabled = variable_get('securesite_enabled', SECURESITE_DISABLED);
  $account = '';
  $content = '';
  
  // If cache is enabled we need to load the theme system
  if (variable_get('cache', CACHE_DISABLED) != CACHE_DISABLED) {
    drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
  }

I think if you call DRUPAL_BOOTSTRAP_FULL, it'll fire hook_init, which'll start securesite authentication again.

OK, I reproduce this using the instructions wotstheguts provided. I either get errors on t() or theme(). During a cached bootstrap, drupal_bootstrap calls drupal_bootstrap with DRUPAL_BOOTSTRAP_LATE_PAGE_CACHE, which calls _drupal_cache_init. _drupal_cache_init then fires hook_init. Since securesite_init() uses functions from common.inc (t()) and theme.inc (theme()) and neither has been included by _drupal_cache_init(), errors occur. We could either make our own t() and/or theme() alternatives or include common.inc and/or theme.inc at the top of securesite_init().

I'll work on a patch that includes common.inc to see what y'all think. Cached bootstrapping will be a bit slower, but at least it'll work. ;)

Please test the attached patch. Make sure you update to the latest DRUPAL-5 branch code first, as I've committed some changes today that will cause patching to fail otherwise.

I have not tested your patch but I had a look at it.

Your securesite_status_messages() function looks good but I don’t think including common.inc will work as the t() function in common.inc has a theme() function call in it.

Nowhere are we using argument replacement so in theory we should not have to worry about that theme('placeholder', $value) call.

When somebody is running caching they are trying to speed up its site performance and I think including common.inc every time hook_init() is called would be counter productive.

I think a better solution would be to create our own t() function that way the only extra code is one function rather than a +2000 line file.

Here is my idea for a t() function.

function securesite_t($string, $args = 0) {
  if (function_exists('t')) {
    return t($string, $args);
  }

  global $locale;
  if (function_exists('locale') && $locale != 'en') {
    $string = locale($string);
  }
  if (!$args) {
    return $string;
  }
  else {
    // Transform arguments before inserting them
    foreach ($args as $key => $value) {
      switch ($key[0]) {
        // Escaped only
        case '@':
          $args[$key] = check_plain($value);
        break;
        // Escaped and placeholder
        case '%':
        default:
          $args[$key] = '<em>'. check_plain($text) .'</em>';
          break;
        // Pass-through
        case '!':
      }
    }
    return strtr($string, $args);
  }
}

t() is only part of the problem. The theme('status_message') calls in securesite.inc are also part of the problem, which is why I replaced them.

I wonder why the patch worked if t() still calls theme()? Maybe by the time it's called, theme() is defined?

I'm wondering if we're not barking up the wrong tree. This problem seems to be related to guest logins. I use caching on several sites that use securesite and I've never run into this problem.

One thing I noticed is that we don't call module_invoke_all('exit') in securesite_goto(). Could that be related?

Maybe there's something wrong with the way we create the anonymous user session for guests?

Here's an alternative fix. The basic problem is that the cache table contains a cached page from when the guest was logged in, but that cached information doesn't contain the dialog code used during authentication. When we try to login after a guest, the cached data is used and the PHP error occurs. NaX almost had the correct solution, but data would still be pulled form the cache. So, we have to clear the cache, then run a full bootstrap.

Here's an easy way to reproduce the PHP error. You must have guest logins enabled for this to work:
1) Login as a guest
2) Delete the session cookie stored for the server
3) Restart your browser to clear the HTTP Auth cache
4) Visit the site again

At this point, you should get the PHP error. To get rid of the PHP error, empty the cache_page table in your database.

@wotstheguts: I'd appreciate it if you could test the patch in #11 on your site to see if it resolves the problem. if so, I'll commit it to the DRUPAL-5 branch.

Fixed on the DRUPAL-5 branch.