Closed (duplicate)
Project:
Image
Version:
5.x-1.6
Component:
image.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
22 Jan 2008 at 17:20 UTC
Updated:
29 Jan 2008 at 06:42 UTC
After adding a new content type, on the whole site images can only be viewed by the author.
For everybody else there are access errors in drupal log. Images can not be viewed anymore.
After looking at some of the tables (with little understanding of what they do), it seems
that table "node_access" is okay, actually the nodes that contain images can be accessed.
The "acl_node" table seems also ok:
acl_id nid grant_view grant_update grant_delete
14 52 1 1 1
But the "acl" table looks strange:
acl_id module name
1 content_access view_2
2 content_access update_2
3 content_access delete_2
4 content_access view_4
...
12 content_access delete_3
13 image_gallery_access 2
14 image_gallery_access 3
15 image_gallery_access 4
It seems like the 'name' is wrong for the last 3 entries?!?
Comments
Comment #1
salvisNo. I can't speak for content_access, but the image_gallery_access entries look fine. ACL manages access control lists on behalf of other node access modules. The format and interpretation of the name field depends on the module that asked ACL to create the entry.
In the case of image_gallery_access, this is the tid of the gallery that this acl applies to.
Have you maybe upgraded the image module? As stated on http://drupal.org/project/image_gallery_access, this may be problematic. I haven't been able to look into the image upgrade yet, but the image issues queue is full of reports about problems with image 5.x-2.x-dev.
You can download the Devel module, http://drupal.org/project/devel, 5.x-1.x-dev and install the devel_node_access module. This will show you the node access entries that control access to each of your nodes. If you update Image Gallery Access to 5.x-1.1 and ACL to 5.x-1.x-dev (wait until the packaging script has had time to create a new tarball!) then you'll even see explanations of the node access entries.
The IGA update will fix some minor bugs, but I don't think it will make a difference for what you're seeing, because you say it used to work fine. Post the node access entries for one of the misbehaving nodes, then we'll try to figure out what is going wrong.
Comment #2
salvisComment #3
MatzeU commentedOk, so this means that the entry in "acl" table
15 image_gallery_access 4
means that the acl entry belongs to the image_gallery with the tid 4.
I think if found this in the table term_data:
4 2 Band und Sonstiges 0 0
That fits, this is a gallery.
No I didn't upgrade any module, and if I understand you correctly I should NOT update image, right?
The version of image is: 5.x-1.6
I installed and configured the dev module as described. This is the result:
Node realm gid Anzeigen update Löschen explained
Satanic Army Flyer content_access_rid 1 1 0 0
Satanic Army Flyer content_access_rid 2 1 0 0
Satanic Army Flyer content_access_rid 3 1 1 1
I updated ACL and image gallery access as you said and after that I get this from the dev module:
Node realm gid Anzeigen update Löschen explained
Satanic Army Flyer content_access_rid 1 1 0 0
Satanic Army Flyer content_access_rid 2 1 0 0
Satanic Army Flyer content_access_rid 3 1 1 1
I dont see the explainations.
Are these the entries you wanted me to post?
The output of the "node_access entries for nodes shown on this page" are the same for a user that can see the stuff and a user that doesn't see it (but should and used to).
Thank you and I hope this helps.
One question, can I leave the module devl node access on or will it slow down the performance (I disabled the block for it for now...)?
Comment #4
salvisYes, for IGA that's how it works. But it's the client of ACL that knows what the 'name' means; ACL doesn't care.
ACL is only used for user-level grants. In IGA that's when you make someone a moderator.
I have no inside knowledge of Image, but I upgraded it without first looking at its issues queue, and I have regretted it. Also, it seems that IGA doesn't work with it, but it doesn't make sense to look into that until Image 2.0 is stable.
Yes, these are the entries. You don't see any explanations because you don't have any ACL or IGA entries for this post, only Content Access entries. Unfortunately, fago (CA maintainer) hasn't yet implemented hook_node_access_explain(), so we don't really know what they mean. However, because the realm is content_access_rid, we can guess that the numbers are rid's; this would mean that roles 1 and 2 have View access and role 3 has Full access, but it's only a guess. You'll have to ask fago.
You should see explanations with ACL and/or IGA entries.
Yes, devel_node_access always shows all the entries that apply to a node, independently of the user.
But let's focus on the issue of this thread: you'll have to show me the entries of an image that is supposed to be visible and isn't.
Slow-down is neglegible if you don't show the block. However, it's not recommended to keep any devel module installed on a production site, because devel modules are just that: developer tools. They aren't tested as thoroughly as you would wish for a module running on a production site.
Comment #5
MatzeU commentedThe "Satanic Army Flyer" is such an image, here is its output again:
Node realm gid Anzeigen update Löschen explained
Satanic Army Flyer content_access_rid 1 1 0 0
Satanic Army Flyer content_access_rid 2 1 0 0
Satanic Army Flyer content_access_rid 3 1 1 1
I am now trying to find out what the gid is referring to.
I found the table "role" and somehow this makes sense:
1 anonymous user
2 authenticated user
3 Administrator
4 Soldat
5 Leader of the Empire
6 Stereo
If this is the right table to check this, this means that anonymous users and authenticated users can view.
Administrator can view update and delete.
All other roles do not have a specific rule. I would expect in that case that the rule for authenticated users would apply.
Anyway, as also anonymous users should be able to view the image according to the table there must be something else wrong, as,
still, the image is not visible for anyone but me (user/1).
Hmm... what can we do next to understand what is going on?
Maybe the info from the log helps:
Typ Datum Nachricht Benutzer Operationen
Warnung Zugriff verweigert 24 Jan 2008 - 10:14 system/files/images/satanicarmy3_flyer1.jpg Andrea
Warnung Zugriff verweigert 24 Jan 2008 - 10:14 system/files/images/satanicarmy3_flyer1.thumbnail.jpg Andrea
Sorry for the german, in english it must be something like:
Typ Date Message User Operations
Warning Access denied 24 Jan 2008 - 10:14 system/files/images/satanicarmy3_flyer1.jpg Andrea
Warning Access denied 24 Jan 2008 - 10:14 system/files/images/satanicarmy3_flyer1.thumbnail.jpg Andrea
Comment #6
salvisSince this node only shows Content Access records, this is unlikely to be an Image Gallery Access problem, but there's one more step we can make: Are your nodes blocked or only the images on your nodes? IOW, do you see the image nodes (like title, text, "comment" links etc.) and with a broken image icon, or do you get access denied on the image nodes?
The log messages that you show say that the images themselves (i.e. the jpg bitmaps) can't be accessed, not the nodes. If it were a problem of node access, then it would say something like "access denied -- /node/123". The log messages that you list could be caused by someone trying to access your bitmaps directly, without looking at your nodes, IF you have set downloading to private at admin/settings/file-system.
Are you really seeing images not being available for viewing, or are you just concerned about the log messages?
Comment #7
MatzeU commentedIt is really just the image itself that is not displayed. The node is fully displayed, but the image itself in the node is not displayed. This is true for all images in all nodes. E.g. also in the overview of all galleries, there is one sample image for each gallery, this is also not displayed. Also there is a random image block. This block also has the problem when I turn it on. The block itself is displayed, but the random image itself is not.
I generated the log message myself by looking at such a node. So I am sure that the message in the log was not generated by trying to access the file directly. But you are right, the download method is set to private.
The images are not displayed in nodes which should show them. Its not about the log message. It is the content that is not correctly displayed.
Looking thru this whole thing again and with your hint about private and public download method I found out one thing:
The log says:
"system/files/images/satanicarmy3_flyer1.jpg"
But the location of the file in the drupal structure is:
"files/images/satanicarmy3_flyer1.jpg"
There is no subfolder "system" anywhere on the webserver. Also in "Administration->Settings->Filesystem"
The filesystem path is set to "files" not to "system/files".
Maybe this is the problem. That in the db for what ever reason the path to the images is messed up?
I checked the table "files" for this specific image the entry is like that:
fid nid filename filepath filemime filesize
80 51 _original files/images/satanicarmy3_flyer1.jpg image/jpeg 45276
The filepath "files/images/satanicarmy3_flyer1.jpg" is the correct path on the server.
So where is "system/files/images/satanicarmy3_flyer1.jpg" in the log coming from??
Comment #8
salvisI believe it's normal to have a simulated download path for the private downloading method.
At this point I have to transfer you to the Image module, because if you see the nodes, then this is not an issue of access control.
I don't know what version of Image you're using — please set the correct version.
Good luck!
Comment #9
MatzeU commentedThe version of image is 5.x.1.6.
Well, to give a short summary, the problem is that images are not displayed at all.
As I am only using image_gallery I first thought it was related to that but salvis found out that it must be related to image itself.
Any hints are welcome.
Maybe look at post #7. I think this shows where we stand.
As this happened suddenly on a productive site, this is quite urgent for me, so any help is appreciated. Thanks.
Comment #10
Hetta commentedDuplicate of http://drupal.org/node/215061