1

My client is reporting a problem that I am unable to reproduce, either locally or on the live, production server. The issue they are reporting comes when they try to change a file. The site contains a 'Latest events' link, which simply links to a PDF or JPG. There is a channel set up specifically for this link, containing nothing but a single 'file' field type. It is also set up to use the Single Entry add-on, so that the existing entry will always be edited rather than new entries added.

The client reports that when they go to edit this channel, they frequently find that clicking the 'Add File' link sends them to the CP log-in screen – presumably logging them out, although looking at the CP log shows no formal log-out taking place. On occasions when they have not been kicked out of the CP in this way they have had mixed success with actually uploading a file; some attempts work, whilst others result in the error message "The file could not be written to disk". (They have reported that they have had more success in uploading jpegs than with PDFs).

The perplexing bit is that when I log into the site from my own computer, even if I use the client's own login details, I see none of these problems -- files and images upload without a hitch, both in Safari (Mac) and IE9 (which is the browser that the client uses, AFAIK).

Has anybody here come across anything like this? Without being able to reproduce the problem from my end it's pretty hard to diagnose; I'm thinking that it's maybe something to do with the client's own browser set-up, but that's a pure guess and I haven't a clue regarding where to look for the specific cause. Um... help?

1

Are they using some sort of proxy to connect to the site? Are they using some sort of remote session (e.g. Citrix) to connect to the site? Are you uploading the same PDF they're uploading? Some PDFs trigger the XSS filter and prevent the file from uploading, maybe try turning that off in your system settings.

  • Thanks for the ideas Nuno; as far as I know their connection is pretty standard - no proxies or remote session weirdness. (I'll check with them, of course). XSS filters might be a good thing to check, though -- that hadn't occurred to me, and yes I do have XSS filtering turned on. I'm going to get the client to send me the PDF that they were trying to upload, and see if that causes any glitches from my end. – Rick Lecoat Apr 24 '13 at 17:34
  • Also verify that you have Control Panel Session Type set to Cookies and Session ID. I've had issues with this setting in the past, so now I always deafault it to Cookies and Session ID. – Nuno Albuquerque Apr 24 '13 at 21:23
  • Yes, it is set to that Nuno, but thanks for flagging it in case. – Rick Lecoat Apr 24 '13 at 21:25
1

Before doing anything, make sure you are running the most recent version of EE. It's possible they have updated EE code in a newer version to deal with changes in how PDFs are created.


The issue sounds specific to the PDF so you'll have to have it in hand for testing. When you get it, disable XSS Filtering as a test.

Admin > Security and Privacy > Security and Session Preferences

Set Apply XSS Filtering to uploaded files? to No and save

If your upload works with this disabled, reenable it and then add this to your code to exempt specific member groups from the filtering:

$config['xss_clean_member_group_exception'] = "1|6";

This could also be related to the size of the actual PDF and the amount of PHP resources the upload needs to complete. Try increasing the amount of memory allotted to PHP if the above doesn't solve the problem.

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.