0

I have a custom module implementing hook_file_download() for both public and privately managed files. At the head of my hook implementation I have the typical declarations to access the $user global:

function contractor_file_download( $uri ) {
  $caller = 'contractor_file_download';
  global $user;

  devlog( $caller.': uri is "'.$uri.'", user is "'.$user->uid.'"' );
  devlog( $caller.': globals user is "'.print_r( $GLOBALS['user'], 1 ).'"' );
  ...
}

The problem I'm having is that $user contains the anonymous user sometimes, if that makes any sense. Although it makes no sense, when testing via an OSX machine, any browser, the $user is always the valid logged in user. But when testing via any flavor of Windows, about 70% of the time both $user and $GLOBALS['user'] both contain the anonymous user. Yet, in all instances, the "My Account" link can be clicked and the correct logged in user profile loads.

What could cause $user to contain the anonymous user even after the user has logged in?

Additional info: the files being accessed getting the anonymous user are all private managed files.

Improve this question
9
  • I don't know about the OSX vs. Windows distinction (more likely a difference due to browser than OS), but is there any chance that you're sometimes accessing the file via a slightly different base url than you're using to access the user's account page? Like www.example.com vs. example.com, or accessing the site via https rather than http? Or perhaps your web server or reverse proxy (Varnish?) is set to strip cookies for requests under a particular set of circumstances. – Aaron Sep 1 '15 at 20:20
  • The uri passed to hook_file_download() look like "private://uc_attribute_files/orders/[orderId]/[jobId]/filename.jpg", which is a local private file reference. That does differ from the user's profile link, which has a fully qualified url looking like "www.site.com/user". I'll try making the private file uri fully qualified, and report back. – Blake Senftner Sep 1 '15 at 20:26
  • That part with private:// is called a streamwrapper and that's as it should be. But what about the actual request that results in triggering hook_file_download...what does that request look like? – Aaron Sep 1 '15 at 20:28
  • These are images on a custom form, with markup looking like: <img src="example.com/system/files/uc_attribute_files/orders/[orderId]/…"> – Blake Senftner Sep 1 '15 at 20:34
  • the url "manager" here is modifying what I wrote. I have www.example.com in my references. – Blake Senftner Sep 1 '15 at 20:35
1

Solution is insuring all site urls use the same subdomain, either including the www before the domain or not including the www before the site domain. Plus within .htaccess forcing all user urls to reference the site via that same subdomain qualifier.

The problem was inconsistent use of www and nothing as the site's subdomain.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.