Posted by rucx on September 12, 2011 at 1:23pm
94 followers
| Project: | Drupal Commerce |
| Version: | 7.x-1.2 |
| Component: | Views integration |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
A view with a Content: Referenced Product Relationship (Drupal Commerce) shows the desired output of fields for admin, but the output is empty for Anonymous users.
When I delete the relationship, the view's content does show for Anonymous.
Here's the view:
$view = new view;
$view->name = 'test_catalog';
$view->description = 'A view that lists currently available tests.';
$view->tag = 'default';
$view->base_table = 'node';
$view->human_name = 'test Catalog';
$view->core = 7;
$view->api_version = '3.0';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
/* Display: Master */
$handler = $view->new_display('default', 'Master', 'default');
$handler->display->display_options['title'] = 'tests';
$handler->display->display_options['access']['type'] = 'none';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['query']['type'] = 'views_query';
$handler->display->display_options['query']['options']['query_comment'] = FALSE;
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'some';
$handler->display->display_options['pager']['options']['items_per_page'] = '9';
$handler->display->display_options['style_plugin'] = 'default';
$handler->display->display_options['row_plugin'] = 'fields';
/* Relationship: Content: Referenced product */
$handler->display->display_options['relationships']['field_product_ref_product_id']['id'] = 'field_product_ref_product_id';
$handler->display->display_options['relationships']['field_product_ref_product_id']['table'] = 'field_data_field_product_ref';
$handler->display->display_options['relationships']['field_product_ref_product_id']['field'] = 'field_product_ref_product_id';
$handler->display->display_options['relationships']['field_product_ref_product_id']['label'] = 'Product Reference';
$handler->display->display_options['relationships']['field_product_ref_product_id']['required'] = 1;
/* Field: Content: Title */
$handler->display->display_options['fields']['title']['id'] = 'title';
$handler->display->display_options['fields']['title']['table'] = 'node';
$handler->display->display_options['fields']['title']['field'] = 'title';
$handler->display->display_options['fields']['title']['label'] = '';
$handler->display->display_options['fields']['title']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['title']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['title']['alter']['absolute'] = 0;
$handler->display->display_options['fields']['title']['alter']['word_boundary'] = 0;
$handler->display->display_options['fields']['title']['alter']['ellipsis'] = 0;
$handler->display->display_options['fields']['title']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['title']['alter']['trim'] = 0;
$handler->display->display_options['fields']['title']['alter']['html'] = 0;
$handler->display->display_options['fields']['title']['hide_empty'] = 0;
$handler->display->display_options['fields']['title']['empty_zero'] = 0;
$handler->display->display_options['fields']['title']['link_to_node'] = 1;
/* Field: Field: Image */
$handler->display->display_options['fields']['field_image']['id'] = 'field_image';
$handler->display->display_options['fields']['field_image']['table'] = 'field_data_field_image';
$handler->display->display_options['fields']['field_image']['field'] = 'field_image';
$handler->display->display_options['fields']['field_image']['relationship'] = 'field_product_ref_product_id';
$handler->display->display_options['fields']['field_image']['label'] = '';
$handler->display->display_options['fields']['field_image']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['path'] = '[view_node]';
$handler->display->display_options['fields']['field_image']['alter']['absolute'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['external'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['replace_spaces'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['trim_whitespace'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['alt'] = '[field_image-alt]';
$handler->display->display_options['fields']['field_image']['alter']['nl2br'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['word_boundary'] = 1;
$handler->display->display_options['fields']['field_image']['alter']['ellipsis'] = 1;
$handler->display->display_options['fields']['field_image']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['trim'] = 0;
$handler->display->display_options['fields']['field_image']['alter']['html'] = 0;
$handler->display->display_options['fields']['field_image']['element_label_colon'] = FALSE;
$handler->display->display_options['fields']['field_image']['element_default_classes'] = 1;
$handler->display->display_options['fields']['field_image']['hide_empty'] = 0;
$handler->display->display_options['fields']['field_image']['empty_zero'] = 0;
$handler->display->display_options['fields']['field_image']['hide_alter_empty'] = 0;
$handler->display->display_options['fields']['field_image']['click_sort_column'] = 'fid';
$handler->display->display_options['fields']['field_image']['settings'] = array(
'image_style' => 'width-220',
'image_link' => '',
);
$handler->display->display_options['fields']['field_image']['field_api_classes'] = 0;
/* Sort criterion: Content: Title */
$handler->display->display_options['sorts']['title']['id'] = 'title';
$handler->display->display_options['sorts']['title']['table'] = 'node';
$handler->display->display_options['sorts']['title']['field'] = 'title';
$handler->display->display_options['sorts']['title']['order'] = 'DESC';
/* Filter criterion: Content: Published */
$handler->display->display_options['filters']['status']['id'] = 'status';
$handler->display->display_options['filters']['status']['table'] = 'node';
$handler->display->display_options['filters']['status']['field'] = 'status';
$handler->display->display_options['filters']['status']['value'] = 1;
$handler->display->display_options['filters']['status']['group'] = 0;
$handler->display->display_options['filters']['status']['expose']['operator'] = FALSE;
/* Filter criterion: Content: Type */
$handler->display->display_options['filters']['type']['id'] = 'type';
$handler->display->display_options['filters']['type']['table'] = 'node';
$handler->display->display_options['filters']['type']['field'] = 'type';
$handler->display->display_options['filters']['type']['value'] = array(
'test_display' => 'test_display',
);
/* Display: Page */
$handler = $view->new_display('page', 'Page', 'page');
$handler->display->display_options['path'] = 'tests';
$handler->display->display_options['menu']['type'] = 'normal';
$handler->display->display_options['menu']['title'] = 'Tests';
$handler->display->display_options['menu']['weight'] = '0';
$handler->display->display_options['menu']['name'] = 'main-menu';
Comments
#1
fixed with latest dev's of views and commerce but now getting the https://drupal.org/node/1265152 error
#2
I'm having a similar problem. There seems to be a difference in that it doesn't make a difference whether I remove the relationship or not. [EDIT]: I realized I created my view directly displaying the product type instead of their display nodes. I recreated the view properly, and now I see the same behaviour with the relationship removed. Updating to the dev versions hasn't helped though.[/EDIT] Anonymous users can't see views displaying products. I've tried using the most recent dev versions of Commerce and Views available on their project pages, but still no results.
Using a clean install of Commerce (no kickstarter), Views 7.x-3.0-rc1, Commerce 7.x-1.0. I've attached a txt with the views export and a couple of screenshots.
#3
Experiencing same issue for anonymous users (Views 7.x-3.x-dev) when using Referenced Product (Commerce 7.x-1.x-dev). Other content views functioning properly. Attempted rebuilding permissions, flushing cache, modifying Views access by Role then Permission but no success. Subscribing.
#4
Implementing the suggestion in this post http://drupal.org/node/1276900#comment-4980066 to all the catalog views now allows anonymous users to view the product catalog again.
#5
#1 comment on the mentioned issue above solves this
Edit your view > Right column "Advanced" > Query settings : check "Disable Query Rewritting"--> Disabling SQL rewriting will disable node_access checks as well as other modules that implement hook_query_alter().
but can someone confirm that "Disable Query Rewritting" does not create other problems ?
my view was working fine until I updated views to dev version 10 days ago
EDIT:
this is the warning in the query settings
WARNING: Disabling SQL rewriting means that node access security is disabled. This may allow users to see data they should not be able to see if your view is misconfigured. Please use this option only if you understand and accept this security risk.#6
Hmm. I *think* this is the issue I'm having, so I'll stick to adding here.
I must grant (at least) the following permission, for roles to see products in display nodes in views:
View any [TYPE] productWarning: Give to trusted roles only; this permission has security implications.
even if the role has "access all content" perms.
Same issue?
#7
#4 worked for me.
#8
subscribe.
#9
#4 worked for me .
#6 worked for me.
but is the best solution?
Subscribe.
#10
#4 worked for me. Don't want to try #6 since it opens a big security hole in my website. but anyway I don't think #4 is a final solution.
#11
I have the same problem, #4 works for all views except cart #6 works for cart.
This only happened to me after I updated to the latest release of views.
#4, #6 cant be a long term solution to the problem, is there any progress on fixing this?
#12
Having the same problem, my view displays ok until I add a relationship ( Drupal Commerce ) , then it no-longer displays for anonymous. #4 works but I agree with #11 we should not close the issue.
#13
IMO this is probably not a bug. We're giving access to products through a view like this, and an anon user doesn't have privileges on them.
The relevant views discussion is in #1222324: Fix query access control on relationships
#14
I'm going to call this a 1.1 blocker. I'm pretty sure the behavior described here is correct, but it's just appearing strongly in recent views versions.
It's going to break some existing sites with views of nodes that reference products.
At least the release notes need to let people know about this (assuming it is in fact a change).
#15
This is critical, as it breaks an enormous number of existing installs. It is in fact a result of #1222324: Fix query access control on relationships and I'm not sure what we should do about it. There are piles of views that depend on the old behavior.
#16
I think the existing behavior is probably a bug. If a user doesn't have rights to view product entities, that user should not be able to view product entities via a relationship. I'm not sure exactly what the state of the views fix is. I'm using the current-dev and do have the issue, but not the issue where view cart is completely gone. Not sure exactly what got rolled back.
Can anyone explain the security implications of the view product permission? Perhaps viewing the products via the admin URL? If so maybe products need a separate entity permission that allows them to be viewed as front end objects such as via relationships.
#17
Randy, can you clarify for me how the other issue interacts with this one? I don't know the history behind it, but it looks like you bumped this to critical even though the problem is a bug in Views itself. Is the issue jus with the Views 3.0-rc3 release, or is it still just in Views dev?
#18
@rszrama, this one is certainly a duplicate of #1222324: Fix query access control on relationships, which is apparently not actually a bug, but a feature. It's a *new* feature, though, and it dramatically affects what we've been telling people to do for a long time.
Essentially, all the sitebuilders who have been building customer-facing views of product display nodes using relationships to products are going to be completely broken. We probably need a new permission that is not security sensitive that allows end-users including anon to view products somehow (avoiding whatever the security problem is with this).
#19
This issue is back to the state of the original report using commerce -dev and views -dev -- anonymous users can't see their cart.
#20
I don't think it's changed. The views folks would say we've been relying on a bug. And this isn't just anon users, IMO, it's any user that doesn't have "access products" permission. Or at least it should be.
#21
Ryan, Randy - what is the recommended quickfix when having this issue? Should I give "View any Product product" privilege to anon users?
#22
#5 has the quick fix.
#23
I took a quick look at the permissions on product entities. If I enable view any product type for anon users, they are still unable to access products at admin/commerce/products/1234, but the access control on the menu item itself is just commerce_product_access, which would allow it. I'm assuming anon users are bumped out of anything below admin/* by parent menu items. Seems like it might also accidentally allow access to view the entity at other URLs perhaps added by third party modules.
It would be quite straightforward to add a new permission to "view products of any type in queries" and change
commerce_product_query_commerce_product_access_alter()to check that permission in addition to the built in entity permission, give anon users access by default and add a simple update script.#24
#5 does not allow for an anon user to view a cart though. It only allows them to view the products.
#25
I've just checked and #6 fixes the issue and does allow anonymous users to view their carts. At least, for me it does.
Anyways, I have a question of another kind. On permissions page it says that if I give away "View any product of any type" permission, that would be a security issue. But admin pages with enlisted products are still closed for anonymous users. So, what is the danger of giving it away?
#26
Hi, using #5, but not yet seeing what risk I am having with doing this?
Thanks a lot in advance for your reply!
Greetings, Martijn
#27
I am also using #6 and can confirm it is working. But, I am also concerned about security implications.
Any detail what the implications are or how at risk we are for using this workaround?
#28
I've now extended #5 to include the shopping cart block and summary pages so that an anon user can see the lot. I'm still unsure as to why #6 is deemed unsafe, so will probably stick with applying #5 wherever it's needed for now. Would be interested to learn more.
#29
#5 works for me .
tnx @GiorgosK
#30
#6 worked for me also.
Just wanted to add: I'm using DC for a clothing store. I need to add the relationship to the shopping cart so that I can include the colour and size of the product in the cart. If I don't do this, it's very confusing as when you select the product colour, click 'add to cart', the product is added to the cart but the screen jumps back to the default colour which would leave the user wondering what colour product they've just added to their cart.
#31
@Aussiejen, you can show the attributes in the cart by amending your view. I'm putting together something similar, although it's just sizes. My line items show the size alongside the product.
#32
@aussiejen
http://drupal.org/project/commerce_product_attributes
#33
I have put the attributes in the cart by amending the view, but I did need to implement #6 to make the cart visible to anonymous users
#34
#5 also worked for me to allow non admin users to view the product catalog.
#35
#5 worked and $6 also worked for me but still haven't seen an answer above as to which is better to do, so... subscribing.
#36
OK, after digging through this for a while I've come to a couple of conclusions.
1.) commerce_entity_access_query_alter() seems to be the offending problem here (this plus some clarification on permission usage). Specifically the "'view any ' . $entity_type . ' entity of bundle '" permission doesn't actually work for this because of 2.)
2.) lines 1045-1068 of commerce.module read thus:
<?php
// Loop over every possible bundle for the given entity type.
foreach ($entity_info['bundles'] as $bundle_name => $bundle_info) {
// If the user has access to view entities of the current bundle...
if (user_access('view any ' . $entity_type . ' entity of bundle ' . $bundle_name, $account)) {
// Add a condition granting access if the entity specified by the view
// query is of the same bundle.
$conditions->condition($base_table . '.' . $entity_info['entity keys']['bundle'], $bundle_name);
}
elseif ($account->uid && !empty($entity_info['access arguments']['user key']) && user_access('view own ' . $entity_type . ' entities of bundle ' . $bundle_name, $account)) {
// Otherwise if an authenticated user has access to view his own entities
// of the current bundle and the given entity type has a user ownership key...
$really_restricted = TRUE;
// Add an AND condition group that grants access if the entity specified
// by the view query matches the same bundle and belongs to the user.
$conditions->condition(db_and()
->condition($base_table . '.' . $entity_info['entity keys']['bundle'], $bundle_name)
->condition($base_table . '.' . $entity_info['access arguments']['user key'], $account->uid)
);
}
else {
$really_restricted = TRUE;
}
}
?>
And I'm pretty sure that the $really_restricted setting here needs to be moved out of the foreach and instead some sort of static test variable should be added.
3.) Beyond that, the elseif in this code is almost repeated verbatim a few lines later (after the return for $really_restricted is done).
<?php// If the given entity type has a user ownership key...
if (!empty($entity_info['access arguments']['user key'])) {
// Perform 'view own' access control for the entity in the query if the user
// is authenticated.
if ($account->uid && user_access('view own ' . $entity_type . ' entities', $account)) {
$conditions->condition($base_table . '.' . $entity_info['access arguments']['user key'], $account->uid);
}
}
?>
The code in the elseif inside the 2.) snippet seems a little more complete, so I'm confused...
4.) Permission wise, the only place that user_access() against the 'view any ' . $entity_type . ' entity of bundle ' permission is used is in commerce_entity_access_query_alter(). There's enough indirection here that it could be used elsewhere, but I think this permission might be safe at this point to use for fixing this situation if the code in 2.) can be fixed.
I would have attempted this myself, but there's enough going on here and my access to the significant maintainers of commerce is limited enough right now that I decided to just document this and put it on the issue.
#37
sorry just a mistake
#38
You'd probably have to say why you assigned it to yourself.
#39
#5 Works good so far. Will this be the final solution?
Kirk
#40
Sorry for bringing this up again.
I´m quite a newbie in Drupal, the "Disable SQL rewriting" option make me confused.
I´m still wondering is this the only handy solution to get product entities visible for anonymous user?
Is or isn´t is a matter of security?
The point is, I´m the one who don´t understand at all.
Kirk
#41
Removing "1.1 blocker" tag as 1.1 is out since 2011-Nov-29.
#42
Sorry I don´t understand what doe´s it mean:
Removing "1.1 blocker" tag as 1.1 is out since 2011-Nov-29.
Kirk
#43
I used #5 and it worked... still a bit nervous as to working with "quick fixes" :) but for now it will do.
Thanks for the help...hope to see this "feature" resolved soon :)
#44
subscribing
#45
@ajaysolutions, You don't need to post a comment to "subscribe" any more; there is a "Follow" button in the upper-right corner of the issue page. Thanks!
#46
I was wondering why he wrote "subscribing" ...I wanted to type "drinking coffee"...but then I got too busy drinking coffee :)
#47
lol If only we were on Facebook so I could "Like" your comment. ; )
#48
I'm sure dww would LOVE that suggestion ;-)
#49
hmmm...good idea Ryan! Drupal.org should incorporate the 5star rating module or a similarly a "Like" option :)
#50
oh yeah nice one, I didn't notice that!
#51
For a while now there's been a fix in Views (now part of 3.1) and patches by bojanz to attempt a solution in Commerce as well. I'd be interested in seeing if the patch in #1323366: Query access fails in certain cases on post-RC1 Views fixes this for anyone before marking this a duplicate.
#52
Pach fix the problem with relationships Product for me.
But if I add 2 product to 1 product display the product display will be display twice in view list.
#53
hmmm...with the latest updates it's still a problem...so far the only real "quickfix" is #5 "Disable Query Rewritting"
#54
Yepp same here.
#55
Guys, I recently had to explain to a colleague the implications of disabling SQL rewriting, so I thought it would be useful to share it here. However, can someone who knows SQL rewriting intimately please validate that this is correct?
So my attempt at a layperson's explanation goes like this... feedback please:
Whenever there is access control involved, query rewriting is used. So for example, if you want the results of a view to be filtered by a specific user, or specific role, then query rewriting is used.
This applies when you are relying on Drupal to do the filtering based on user permissions. For example, if in the user permissions you specify that an order can only be viewed by the person who made the order, and then you create a view that lists all orders in the system, the result of the views will contain only orders belonging to the currently logged in user. So, internally, Views goes and gets everyone's orders, then asks Drupal which one of those orders it should display. Drupal then uses the query rewrite to tell Views how to filter the results.
If you turn off query rewriting, Views will not go and ask Drupal to filter the results, and will display everything. Which is probably what you don't want.
But, you can still achieve the same effect by getting Views to take more control of the results, and applying that filtering within Views itself. If you do this, then it doesn't matter whether query rewriting is enabled or now... the View you create wil be doing the filtering based on the rules you give it.
Which is why, in the warning message that comes up in Views when you disable query rewriting, it says:
"This may allow users to see data they should not be able to see if your view is misconfigured"
Note the bold text. Basically, it doesn't say that it will open up a security hole, full stop. It says that it *may* open up a security hole (which allows users to view unauthorised content), if you do not explicitly handle that access control filtering within Views itself.
And disabling the query rewrite only affects that view for which you have disabled it for. It does not mean the whole system now ignores query rewriting.
What I would suggest is:
1. If the info you want to display with Views isn't ultra sensitive (eg if you don't mind one user accidentally seeing another user's orders), then disable it for now while we wait for a fix. But,
2. Make sure you explicitly handle any access control requirements and filtering within the View itself.
#56
Thanks Farez for explaining it. I went ahead and closed my eyes and disabled query SQL :) But now I understand better...strange that such a bug would be open for such a long time without being fixed...but I understand that the maintainers have real lives and real jobs outside of Drupal :)
Hopefully the fix comes before I officially launch my commerce website :)
#57
#5 solved my problem.
#58
Had to keep rewriting for some other things so had to go with #6.
I've tried to find out what the security risk is - I can't (as anon) seem to get to anything I'm not supposed to.
What are we being warned about there?
#59
#5 is work. Turns out that the use of unsafe Commerce?
#60
#5
dont work for me
#61
@Caone: try to clear your cache it should work
#62
Hm i´m using a new Drupal installation and a View without relationship now.
And its working quite nice at the moment :)
#63
We are using the "Disable SQL rewriting", however I can't figure out (and no answer in this issue) what the view product permissions security issue
"Warning: Give to trusted roles only; this permission has security implications." is. And if it is an issue, why a new permission is not created instead of disabling it all together using the "Disable SQL
rewriting".
I also think 'Semantically' that the "view products" permission should be 'true' by default and any security involved should be moved to another permission.
And that not only views use this permission but all other places like the product reference formatter
#64
I basically agree with #63 and think that the essence of this is: Is it a security issue to allow viewing products? "View any product of any type" is the related permission. I suppose there are situations where you would not want this to be possible (not wanting users to discover either deliberately or by accident products that are priced differently? products that are aimed at a different currency or audience?).
IMO if your site does not feel that products should only be displayed under controlled circumstances, then there is actually no security issue here and it's OK to use the technique in #5 .
#65
thanks @rfay,
I would much prefer to enable the "View any product of any type" then use the "Disable SQL rewriting" as we have no special conditions for products.
We didn't find any security reason why not to. its only that If something does go wrong and and we ignored a security warning...
Sounds to me like this issue can be closed down by rewording the permission description.
#66
I just used #5 and #6 to get what I needed. It's weird, because another site I have works just fine without this (the changed site is a clone of the original).
I had an issue in views, where I had the two queries (working and non-working): for the curious, the are here: http://drupal.org/files/twoqueries.txt
#67
I can see this feature of not showing products to anonymous users very helpful if you've got a subscription-based service or sell very kinky stuff but by default I think the concept of an online store is to show your products to anyone.
I'm running a drupal commerce website for a client now for less than a month (20 000 pageviews, 3000 visitors, plenty sales) and have not come across anything that looks suspicious or security holes that I can see so I guess the "Disable SQL Query" warning is perhaps just a fineprint to cover all bases :)
DRUPAL COMMERCE ROCKS!!!
#68
Thanks, @guy_schneerson #63 #65 and @rfay #64.
In my case, I also don't mind my users having "view any product of any type" permission.
This solution seems more maintainable/future-proof than changing the query option of the view (#5). A future developer (including future-me) may have a hard time debugging a problem with that view!