Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
After upgrading to filefield 3.13, I get the error "Referencing to the file used in the field is not allowed." when attempting to save any page that has existing imagefield items.
Comment | File | Size | Author |
---|---|---|---|
#60 | increment.txt | 630 bytes | pwolanin |
#60 | 2305969-60.patch | 2.23 KB | pwolanin |
#40 | filefield-2305969-39-fix-predicate-with-19.patch | 2.15 KB | dkinzer |
Comments
Comment #1
Infinitee CreditAttribution: Infinitee commentedI am experiencing the same problem on a Drupal 6 site...
"Referencing to the file used in the field is not allowed."
This error appears upon attempting to edit any field of any page containing a filefield image.
After much research it appears that this is due to a bug in the filefield module and only seams to be occurring since the latest security update of Drupal 6.32 core.
I found that by deleting the current filefield image and either replacing it with a new or, the same image that the page can then successfully be saved and without the error message. Unfortunately, this does not fix the problem and the filefield image needs to be deleted every time an edit is made.
Needless to say, this is not a preferred way of editing pages but, it does work for now.
Comment #2
zanixI am having this issue as well. Looks like the last update added some security checks to the uploaded files.
Comment #3
zanixAnd this line
Comment #4
cdale CreditAttribution: cdale commentedIt looks like the checks fail when the file download method is set to public, as the core drupal function uses hook_file_download() to count the number of headers returned. However, when the download method is public, most modules don't return any headers.... That's what I'm seeing at least.
This should probably check what the file download method is, and only run the access check if file downloads are private.
Comment #5
thalemn CreditAttribution: thalemn commentedI am experiencing this issue with Drupal 6 after upgrading Filefield to 6.x-3.13.
In many cases I have too many files attached to the node to do what comment #1 suggests (although I did have success with this when only one item was attached).
What is our solution?
Comment #6
zanixMy solution was to revert the code back to version 6.x-3.12
Comment #7
thalemn CreditAttribution: thalemn commentedOK - that's what I did, too.
Comment #8
David_Rothstein CreditAttribution: David_Rothstein commentedThis looks like the Drupal 6 equivalent of the problem in the Drupal 7 core File module, so I'm adding a link to that.
Comment #9
David_Rothstein CreditAttribution: David_Rothstein commentedComment #10
othermachines CreditAttribution: othermachines commentedI have two 6.x sites that have been updated to 6.x-3.13, so of course I immediately started testing. I wasn't able to solve this problem, but here are some observations that will hopefully nudge this along:
* Even though I have content types with both 'filefield' and 'image' fields attached, I wasn't able to duplicate the problem exactly as described. There are other factors at play here. This means more details may be needed to track this down.
* In the one instance where I was able to generate the error, it was because a destination subfolder was missing. In the absence of the
file_download_access($file->filepath)
check, this would have passed FileField's validation before. Now, it causesfilefield_file_download()
to query the {files} table using an empty $filepath string. I have no idea if this is related.* @cdale said we shouldn't be checking for # of headers on public files, which is probably true, but I don't think that's the problem here. FileField will always return a header unless something else goes wrong.
* Possibly interesting that in both cases where posters pasted in the error, the field title is missing. It should be "Referencing to the file used in the [field title] field is not allowed." That means $element['title'] is missing, which should only happen in the case of a field where multiple values are allowed. That said and for what it's worth, one of my content types did have a filefield field permitting multiple values, and still I was unable to reproduce the error.
I've run out of time so just wanted to put that out there, in case it helps.
Comment #11
quicksketchThanks @othermachines for all the debugging. When I tested this in 3.12, everything was working fine with a normal FileField and even with FileField Sources.
@David_Rothstein is correct that we should be able to pull the similar fix from the Drupal 7 issue and apply it to FileField.
Comment #12
dmitrii CreditAttribution: dmitrii commentedPatch for #4
Comment #13
theunraveler CreditAttribution: theunraveler commentedIt looks like the ends of the lines in the patch in #12 may have been cut off. Here's a good version of the patch.
Comment #14
thalemn CreditAttribution: thalemn commentedThank you for submitting the patch. Worked perfectly.
Comment #15
nagba CreditAttribution: nagba commentedThe patch looks good code review-wise. I can also confirm that the patch solves the issue.
anyone else wants to do code review / test or shall we push the ticket to 'reviewed & tested by community' ?
Comment #16
yan CreditAttribution: yan commentedSame problem here with Drupal 6.32 and Filefield 6.x-3.13. The patch from #13 doesn't solve the problem in my case. The server is running PHP Version 5.3.3. The file method is public. Another website running at the same ISP but on a different server (also with PHP 5.3.3) doesn't have that problem.
Comment #17
othermachines CreditAttribution: othermachines commented@yan - Can you please describe the problem? Also, what type of node and, if the node is created by a module, which one? Is it a filefield or image field and does it permit multiple values? Thanks -
** Edit - also, what action did you take after applying the patch? Did you attempt to save a node and an error persisted?
Comment #18
TrevorBradley CreditAttribution: TrevorBradley commentedPatch #13 worked for me. Thanks!
Comment #19
danyg CreditAttribution: danyg commentedPatch #13 is almost correct. Only problem is FILE_DOWNLOAD_PRIVATE. This defined variable is FILE_DOWNLOADS_PRIVATE properly.
Comment #20
daveparrish CreditAttribution: daveparrish commented#13 worked well for me too.
Comment #21
Erwin De Vylder CreditAttribution: Erwin De Vylder commentedHaving the same problem. The root cause is filefield_file_download() denying access to the file referenced in the filefield.
Apparently, if you're referencing an existing file, filefield_file_download() will create a list of node revisions where this file is referenced. Next, it will loop those node revisions to find out whether or not you have access to the node revision.
The problem is filefield_file_download() stops looping those node revisions as soon as it finds a single node where the user doesn't have access, instead of continuing to loop until it finds a node where the user DOES have access...
Anyways, patch #13 works by circumventing the problem, but the root cause is still there imho.
Comment #22
reikiman CreditAttribution: reikiman commentedI tried the patch in #19, and it worked on my site
Comment #23
mishunika CreditAttribution: mishunika commentedI have the exactly same issue and the patch from #19 seems reasonable and it fixes the issue.
Comment #24
ZoeN CreditAttribution: ZoeN commentedSame problem here, patch #19 works.
Comment #25
haggins CreditAttribution: haggins commentedConfirming patch #19 is working.
Comment #26
SiliconMind CreditAttribution: SiliconMind commentedAny chance we can get this committed?
Comment #27
dr.admin CreditAttribution: dr.admin commentedSame problem, patch #19 works.
Comment #28
cybergigz CreditAttribution: cybergigz commentedConfirming patch #19 is works.
Comment #29
joelpittetHere's the same patch but relative to the filefield module.
Comment #30
joep.hendrix CreditAttribution: joep.hendrix commented#19 works
Comment #31
askibinski CreditAttribution: askibinski commented#19 works
Comment #32
rajmataj CreditAttribution: rajmataj commented#29 worked for me. Thanks!
Comment #33
pslcbs CreditAttribution: pslcbs commented#29 worked for me too. Thanks!
Comment #34
squarecandy CreditAttribution: squarecandy commented#29 works for me.
http://www.wikihow.com/Get-Over-Fear-of-Commitment
:)
Comment #35
ferrangil CreditAttribution: ferrangil commentedPatch #29 worked just fine. Thank you.
Comment #36
maxferrario CreditAttribution: maxferrario commentedThanks a lot for the patch: #29 worked for me!
Comment #37
askibinski CreditAttribution: askibinski commentedThis patch only seems to fix the issue when the file system is public. It will still return the form error when in private mode.
Comment #38
dkinzer CreditAttribution: dkinzer commentedThere is an error with the code as written in 6.x-3.13:
See the following test case:
The above fails because $step is not available in the third section even though it's defined earlier in the predicate chain. Yet, this is precisely the type of logic that is being used to determine access to file fields. Thus, false negatives are possible whenever access relies on code using said logic.
The following patch fixes this particular issue, but it requires that the user have access to view the specific node revision that get's checked when said node revision is not equal to the current node revision.
Note, that I couldn't find a tag for the current 6.x-3.13 version of filefield in the Git repo, so this patch is against 6.x-3.13 that I downloaded from drupal.org
You'll need to run `patch -p1 < filefield-2305969-38-fix-predicate.patch` in order to apply it.
PS I noticed on my site that certain file fields were attached to node revisions that were not part of the current node revisions. I still don't know why the revisions are off. But I only see this issue when revisions for the files are not the same as current revision.
Comment #39
dkinzer CreditAttribution: dkinzer commentedComment #40
dkinzer CreditAttribution: dkinzer commentedHere's the same patch but with both #19 and #38.
Comment #41
halbtuerke CreditAttribution: halbtuerke commentedI'm using a private file system and the patch from #40 isn't working on my site. I still get the error message for every file I have in the specific post I want to edit.
Comment #42
dkinzer CreditAttribution: dkinzer commented@halbtuerke does the user also have permission for viewing node revisions... because I notice that's the only thing that #40 fixes.
Comment #43
halbtuerke CreditAttribution: halbtuerke commented@dkinzer I've used an administrator account which has all rights.
Comment #44
yan CreditAttribution: yan commentedPatch from #40 seems to solve the problem for me.
Comment #45
joep.hendrix CreditAttribution: joep.hendrix commentedPatch from #40 seems to solve the problem for me.
Comment #46
ShaneOnABike CreditAttribution: ShaneOnABike commentedThis works fine if the file has already been referenced, but if it isn't referenced then it won't work. I think that this was always the 'slightly' annoying case.
So from my perspective with a public system it's a go!
@halbtuerke - perhaps you could add more debug info to find out where it is failing as it would be nice to move this along.
Comment #47
halbtuerke CreditAttribution: halbtuerke commented@ShaneOnABike - What kind of debug information would be helpful and how do I get this kind of information?
Thanks in advance
Comment #48
ShaneOnABike CreditAttribution: ShaneOnABike commentedYou could debug the code to see which part of the if statements are failing? Using devel is a good start... then the patch can be modified accordingly to handle the private system better. Perhaps the private system isn't even reaching that section of patched code?
Comment #49
MakeOnlineShop CreditAttribution: MakeOnlineShop commentedHello, I just started to have this problem, no module update has been released ? So we should use the previous version ?
Could you tell me if I will have problems after trying to put back the 3.12 without updating the database ? Just by changing the files in the module directory ?
Thank you.
Comment #50
yan CreditAttribution: yan commentedThis issue still forces me to use an unsecure version of the module. Could somebody commit the proposed patch to prevent that?
Comment #51
ghmercado CreditAttribution: ghmercado commented#40 worked for me
Comment #52
halbtuerke CreditAttribution: halbtuerke commented@ShaneOnABike - As I currently don't have the means to debug the production environment nor do I have the time to properly setup a local copy of the system, you can go ahead and consider this as fixed as it seems that for everyone else the patch fixes the problem.
Thanks for the help.
Comment #53
iantresman CreditAttribution: iantresman commented#40 worked for me, would be nice to see the module updated to include the fix.
Comment #54
sonoutlaw CreditAttribution: sonoutlaw commented#40 was the silver bullet... thanx dkinzer
Comment #55
jiaqi.yin CreditAttribution: jiaqi.yin commentedAgree with #21, the patches can fix the problem, but the root cause is about the permission of node view and node filefield view which is checked in filefield_file_download()
In our case, we had exactly the same issue, and it turned out this is because the user doesn't have the "view field_file" permission (field_file is the field name in one of the content types, would be different from yours). So by granting the corresponding node view and field view permissions, we can edit the node page again.
It is worth of checking your role permissions before applying patches.
Comment #56
BenMirkhah CreditAttribution: BenMirkhah commented#40 worked for us too thank you.
Comment #57
meanbeth CreditAttribution: meanbeth commentedThanks, dkinzer. #40 worked for us too.
Wish this were in the latest module release.
Comment #58
pwolanin CreditAttribution: pwolanin as a volunteer and at Acquia commentedWould be helpful if someone could improve the issue summary including concise steps to reproduce the bug.
Comment #59
Weka CreditAttribution: Weka commentedThank you dkinzer, patch provided in #40 works.
Comment #60
pwolanin CreditAttribution: pwolanin at Acquia commentedi think patch #40 is missing one bit of logic to check that the node actually got loaded.
Comment #61
sindyy CreditAttribution: sindyy commentedThe patch solved my problem. Thanks!
Comment #63
pwolanin CreditAttribution: pwolanin at Acquia commentedComment #64
aiphesis a new version planed or we must to patch the last one ?
Comment #65
pwolanin CreditAttribution: pwolanin at Acquia commentedyes, I'll roll another release after checking over the issue queue some more
Comment #66
aiphesgreat,because patching (on a dev version + dumped db) doesn't work for me..so will wait :)
Comment #68
MakeOnlineShop CreditAttribution: MakeOnlineShop commentedHello,
Can you confirm that only a patch has been released ? No working module ?
Thank you.
Comment #69
MakeOnlineShop CreditAttribution: MakeOnlineShop commentedNo update on this ?
Comment #70
rares CreditAttribution: rares commentedI downloaded the 3.x-dev code here https://www.drupal.org/node/96616, however the filefield.module didn't match with the changes in the patch. It might be that what is currently packaged as dev is an older version...
In the end, I applied the changes manually (http://cgit.drupalcode.org/filefield/commit/?id=d0701af), and the uploads now work properly.
Comment #71
alexharries CreditAttribution: alexharries commentedI have applied the patch in #40 and it has worked for me. Yay!
Please can we get this two-year-old issue committed into the codebase? :-)
Thank you!
Comment #72
drupalinthailand CreditAttribution: drupalinthailand commentedHello, I have the same problem with the latest version.
So only 3.12 is working correctly ?
Thank you.
Comment #73
tinem CreditAttribution: tinem commentedOn my site with Drupal 6.37 FileField 6.x-3.13 I discovered some problem with some of my images not working as espected when using an API-file for getting data into to my apps with some of my code as:
One day Android app stopped functioning because of
"<mime_type/>
" which should have been<image> <mime_type>image/jpeg</mime_type> <url> http://beta.findtoilet.dk/sites/default/files/images/3/2011/03/borgergade3.jpg </url> </image>
and sometimes images in apps were NOT showed but OK on online site. Hope you understand and someone have time to answerand if this will functioning again if I upgrade to
FileField 6.x-3.14
, please?