Views results empty for unprivileged user when using Relationship: Content: Referenced Product

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.

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.

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.

#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.

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] product
Warning: Give to trusted roles only; this permission has security implications.

even if the role has "access all content" perms.

Same issue?

#4 worked for me.

subscribe.

#4 worked for me .

#6 worked for me.

but is the best solution?

Subscribe.

#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.

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?

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.

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 (comments)

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).

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 (comments) and I'm not sure what we should do about it. There are piles of views that depend on the old behavior.

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.

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?

@rszrama, this one is certainly a duplicate of #1222324: Fix query access control on relationships (comments), 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).

This issue is back to the state of the original report using commerce -dev and views -dev -- anonymous users can't see their cart.

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.

Ryan, Randy - what is the recommended quickfix when having this issue? Should I give "View any Product product" privilege to anon users?

#5 has the quick fix.

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.

#5 does not allow for an anon user to view a cart though. It only allows them to view the products.

#5 does not allow for an anon user to view a cart though. It only allows them to view the products.

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?

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

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?

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.

#5 works for me .

tnx @GiorgosK

#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.

@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.

@aussiejen

http://drupal.org/project/commerce_product_attributes

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

#5 also worked for me to allow non admin users to view the product catalog.

#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.

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:

  // 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).

  // 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.

sorry just a mistake

You'd probably have to say why you assigned it to yourself.

#5 Works good so far. Will this be the final solution?

Kirk

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?

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.

The point is, I´m the one who don´t understand at all.

Kirk

Removing "1.1 blocker" tag as 1.1 is out since 2011-Nov-29.

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

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 :)

subscribing

@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!

I was wondering why he wrote "subscribing" ...I wanted to type "drinking coffee"...but then I got too busy drinking coffee :)

lol If only we were on Facebook so I could "Like" your comment. ; )

I'm sure dww would LOVE that suggestion ;-)

hmmm...good idea Ryan! Drupal.org should incorporate the 5star rating module or a similarly a "Like" option :)

oh yeah nice one, I didn't notice that!

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.

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.

hmmm...with the latest updates it's still a problem...so far the only real "quickfix" is #5 "Disable Query Rewritting"

Yepp same here.

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.

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 :)

#5 solved my problem.

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?

#5 is work. Turns out that the use of unsafe Commerce?

#5

Edit your view > Right column "Advanced" > Query settings : check "Disable Query Rewritting"

dont work for me

@Caone: try to clear your cache it should work

Hm i´m using a new Drupal installation and a View without relationship now.
And its working quite nice at the moment :)

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

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 .

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.

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

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!!!

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!

I want to make sure my problem applies here, or if I need to look elsewhere for a solution. For those having/had this problem, when trying to add a product to the cart, instead of the cart appearing, did it say instead "Your shopping cart is empty"?

If not, maybe I'm having a different problem.

@trevorkjorlien no, that has nothing to do with this. Your problem is probably the session dropping because securepages is not set up properly.

As posted on #1349080: node_access filters out accessible nodes when node is left joined, I spent some time in a debugger last night and tracked it down to a core bug in Node module, when any node_access is applied to a query with an optional relationship.

I think this is a duplicate of that issue...

followed.
this is a critical issue.

Subscribing - critical issue, in regards to permissions.

#4 and #6 work for displaying the view to anonymous users, but on the site I'm building anonymous users should not be allowed to see the the 'Add to Cart' button, for example.

All else in the site 'Add to Cart' is hidden via the Field Permissions module, except in this view which happens to be the main Product Catalog :/

subscribing. We just shut off sql rewriting for views currently. A hack would be to override this setting in all views init. Shut off always...

Hi,

There's a patch at http://drupal.org/node/1349080#comment-6263068 that should resolve the issue... still working on test cases for this. Does this patch break anything on your sites?

subscribing

Have the same problem. Hope someone could to solve it.

@dwatts3624 Great tip: you can use the "Follow" button top right of each issue instead of posting a "subscribing" comment.
@laoguxintan - currently two options exist to resolve this issue: The "View any product of any type" permission or in views "Disable SQL rewriting".
See #5 and #6 and throughout the issue comments.

I only wanted to say that the drupal community is wonderful!

+1

Should I assume that if I use either option described in comment #80 that I can't conditionally hide specific products from users if they don't hold a selected role?

So because of the rewrite rules in Views 7.x-3.x either users can see all or no products?

Hrumph!

That puts a bug in the ointment.

@emptyvoid if you are talking about the "View any {product bundle} product" permission then the issue is that while views respects this permission other parts of the commerce system don't like the add to cart form.

Anonymous users can NOT add items to their cart!
drupal 7.16
commerce 7.x-1.3

• They can see all products but clicking add to cart does not add the item to their cart.
• I've changed all of the cart views to Disable SQL rewriting
• I've granted the permissions for anonymous users: View any product of any type and Access checkout

Still no luck, very disheartened on commerce, as this is a show stopper.

I've had the same issue, once.
But it disappeard also. I figured it had to do with the cookie settings.
Could you check that?

Edit: As a matter of fact I still have the issue.
But it only occures on products that are displayed in a block.

Subscribing. 1 year old issue :-(

I'm not finding any instance where adding to cart works for anonymous users whether from a product display page or a product view, it still says the cart is empty.

Hi, doesn't http://drupal.org/node/1276450#comment-5000178 work for you?
greetings, Martijn

@jday is this a problem with the the view or adding to cart. One way to test is to go to /checkout if you cant access the checkout then the problem is probably with the add to cart and not the cart view.

Just repeating what I and others have posted before:

I think that the setting the "View any product of any type" is much more sustainable & secure.

1. I can't see any security implications, the add to cart form doesn't respect this permission anyway.
2. You only need to set it once and not need to wary about remembering to disable sql rewriting when creating new views linked to products.
3. If at any point other content access restrictions are added to the system they will not get bypassed.

The solution should be removing the warning for the permission and changing the default to true for both anonymous & authenticated user.

but that's just my opinion

@summit - yes I've checked the 'Disable SQL rewriting ' for all the product and cart views.
@guy_schneerson - I've given anonymous users the 'view any product' permission, and anonymous users can see all products (pages and views) and they can see the add to cart button, but clicking 'add to cart' does not actually create a cart, although the message is displayed that it has been added to the cart. If I try to go to checkout it says the cart is empty.

I tried all the suggestions here and none worked. I tried with the latest versions of Commerce, Views, even with -dev. I understood that it isn't a simple question, but it's sad to see a basic feature for e-commerce sites, anonymous checkout, not working with Drupal Commerce. This sounds as a critical issue to me.

What can we do to solve it? Does anybody knows a way to fix it "consistently", so that no one else face the problem again, but maybe doesn't have time to implement it? What about collecting money with Chipin, so that someone could invest time in this?

@rszrama, i think that we, as a community, need to solve questions like this without asking help for companies, but this issue isn't a priority for Commerce Guys?

Hi mmm And is it also not working in a clean Drupal with clean latest commerce? Commerce Kickstart?
I find it curious never experienced this behavior...
greetings, Martijn

@pedrorocha, you should give some details about your problem covering whats installed and configuration.
As far as I know this issue has two solutions to the problem and both worked on every commerce site I was involved with.

I have Commerce Kickstart 2 beta2. I tried to update modules to see if it solves the problem, so now i'm with CK2, but with some modules updated(Commerce and Views are the latest version now)

I made 2 sites with Commerce, without further problems, but this one is the first with CK2. The 2 first was with Commerce alone and with CK1.

@pedrorocha If this actually prevented anonymous checkout for working, you can bet I wouldn't have had any intermediate releases until it was fixed. Unfortunately, we don't have unlimited resources to put on every bug report, and I've had to leave this one open since there are suggestions above that have worked for other people.

As soon as we can fix it for a release, you can bet this issue will be updated (so keep following : ), but it would be just as great for someone who's being blocked by this issue to post a fix (it hasn't affected us on any of our sites yet).

There is nothing to fix here.

We added a workaround for the original issue when it was first reported. What remains is a support request.
If you're displaying fields from a related entity (product in this case), you need to have access to view that entity.
This means that you need to grant users the "view any product of any type privilege" permission.
It has a security warning, which is a mistake on our part, and the warning should be removed.

Kickstart v2 doesn't have this problem because it doesn't show fields from the related entities, it renders the complete related entity in a view mode instead.
(So it's the complete rendered product in a "product in cart" view mode, instead of a relationship to products with a field pulled that way).

Leaving the issue open for now so that we can do a final confirmation before release.

As I mentioned in #86 I've experienced the same problem. But then only in a view block.
I had this view enabled with a global filter: random. By removing that filter my anonymous customers were able again to put the items of that view in to their cart.

Not sure this is the same issue, but maybe it helps.

http://drupal.org/node/1420034 problem with Global Random in this issue.

Hi,

As I mentioned in #77, I believe this is a duplicate of #1349080: node_access filters out accessible nodes when node is left joined . I've had a ton of other things on my plate, but I did finally get a test case out for this core bug, for D8. However, my D8 patch does not work correctly -- haven't had time to dig into how to extend the joined table with the proper sql. Anybody intimately familiar with SelectQuery objects, I could use some help...

The issue is not with Commerce. It's a node access issue, and it's triggered when you use a Views Relationship with a node access module (such as OG or Domain Access), and there's no related item the user has access to. The quick work-around is to disable SQL rewriting, which allows the view to get all results and ignore the node_access rules -- of course, this will show content the user should not otherwise have access to.

I think the real issue behind that is the availability of product (not product display) fields into commerce line items entity.

A possible solution to the access problem would be to make all products fields available directly on line items level, so the user that want to add the product image for example into the shopping cart just have to add the new field, without creating relations to forbidden entity type and so, without bugs.

Regards,

Alex

From #98:

you need to grant users the "view any product of any type privilege" permission.

I have done this, and although anonymous users can view and modify their cart on the cart page, there is no block view in the "shopping cart contents" pane for anonymous users on the checkout page.

I'm using the Commerce 7.x-1.4 and Views 7.x-3.3

Disabling SQL rewriting solves the problem, but the exclamation point and yellow background on the security warning makes me nervous.

I know the root of this issue is #1349080: node_access filters out accessible nodes when node is left joined but surely there must be something that commerce can do to rewrite the SQL to ensure that when anonymous users are given the "access checkout" permission and the "view any product of any type privilege" that they should be able to see products in their shopping cart on the checkout pages.

This is not the case right now...

If the issue were truly related to permissions on the related product type, then the solution offered in #98 would work and I'd be satisfied this is not a commerce issue. But that doesn't work. So I'm not satisfied :p

I'll probably just go with disabling SQL rewriting, but are you guys sure that this problem is not solvable in commerce?

I think the add to cart/checkout for anonymous users stopped working for me once I added a new Line item type, for customizable products. I've tried all of the 'fixes' that are posted in this thread and unfortunately none of them have worked for me.

@jday Forgive me if I'm barking entirely up the wrong tree, but have you configured the add-to-cart button to create the right kind of line item?

@AndyF If you mean check the box for " Include this field on Add to Cart forms for line items of this type. " then yes, I did that. If you mean something else, I'd love to hear that I just missed a setting somewhere. This is the product with the line item fields: http://offtilt.asdhost.net/custom-built-poker-table

If you visit it, you will see that you can not add it (or any other 'regular' products) to the cart when not logged in.

Like so many others, when authenticated users added a product to the cart on one of my websites, it worked, but anonymous users could not add items to the cart. I tried everything on this forum and others to no avail. I finally ran across this post:

http://www.ubercart.org/forum/bug_reports/8693/anonymous_user_add_cart_d...

Even though the post was for Ubercart, the problem for me was the same. Somehow UID 0 for guests got deleted from the users table in my sql database. It may have happened when I upgraded to Drupal 7. Anyway, I went into the database and reinstated UID = 0. Now it works great.

The solution makes sense because line items in the cart get appended with a UID (I think) and if a UID isn't set up for anonymous users, it couldn't add the items to the cart. This also explains the maddening problem of why the product works for some and not others (or at least one possible reason).

For a possible product enhancement I wonder if during the Drupal commerce module installation if a routine couldn't verify that uid=0 exists and if not, set it up; or at the very least add a status message that says User ID 0 is not set up on the system". Its pretty important for cart modules.

I hope this post helps others.

Fix in #98, assigning "View any product of any type" to anonymous users (ignoring the erroneous security warning on the permissions page), works for me.

Fix from #6 is better if you have the domain module (or any other access module that uses sql rewriting) enabled. That way your cart will still only display items from the current domain, and not show items to which you don't have access.

I mean that problem is in taxonomy field in product.
I have a product of type "Shoe" with taxonomy field "Maker". When I clear cache and load some product display with referenced product (Shoe) like user without id 1, I see all fields except field "Maker". Catalog view is empty. But when I load catalog view like admin (user with ID 1), all is OK.

Solution..?

@gynekolog do you have any access module enabled? og_access, domain_access, tac? If this is at all related to #1349080: node_access filters out accessible nodes when node is left joined, I'd like to get more test cases.

And I'm also looking for more people to review my patch on that case, whether it's a valid approach -- once that's confirmed I'll be happy to backport to D7.

@freelock
I had no access module on. I downloaded and activated the module http://drupal.org/project/taxonomy_access, disable the privilege to view the term and then enable again and the problem is solved.

This one's got me a bit stumped. Running Commerce 7.x-1.5 and Views 7.x-3.5. I've set View permissions to "View any product of any type." I've tried disabling SQL rewriting. Flushed the cache. Checked to make sure UID 0 still exists (per #107). But I still can't get the view to display for anonymous users (authenticated users can view it without issue). Wondering if anyone else out there has an alternate solution. Thanks.

@predde - It sounds like you may not have assigned the "View any product of any type" permission to anonymous users at admin/people/permissions.

Bingo @Cottser. Thanks.

Thanks @Cottser (#115)

Linking related issue #1303194: Clarify security implications of granting "View any Product product" permission.

Tanks dude ! I had created a view products with glossary and anonymous users culd not see. Your tip help me :D

I just want to throw in a comment about a real use case where the "View any Product product" permission is not appropriate, and where I have had to resort to disabling query re-writing to get a cart view to show.
We have a complicated site in which certain user roles are allowed to create and buy their own products (don't ask).
But only THEY are allowed to see/purchase them.

I need to add a product relationship to the cart so it displays the product details, but I don't want to allow them to see other user's products elsewhere.
So I am stuck with the disable query re-write as my only solution since it is local to the cart and does not have the global permissions implications.

My question is... why does that relationship plugin enforce the access permission?
There are plenty of ways to enforce permissions that are deliberate and determinate, such as assigning access control in a view, or using a views relationship or filter, but only if the choice is left up to me.
This kind of behind the scenes magic makes it hard to figure out why things are happening (I would offer the 119 comments here as proof of that), and none of the options for solving it are appealing.

@jkopel, I still think this is a core bug: #1349080: node_access filters out accessible nodes when node is left joined. It happens whenever a relationship introduces the node table a second time into any query that is tagged with node_access (which views does, unless you disable the rewrite query option).

Does the node table appear in the generated SQL? Is there a LEFT JOIN between the two instances of the node table? Does the query work as visible in Views when you try it in MySQL? If yes to all three, it's almost certainly that core bug biting you -- its net effect is to turn that LEFT JOIN into an INNER JOIN.

If you want to see this fixed, please come review my patch, and let's get this fixed in core!

Hi, I have very similar problem here - https://drupal.org/node/2105309

I created new order and line item types to implement two shopping carts on my site. It works great, but for anonymous users I must enable "View any orders of any type" to allow anonymous users to view the second basket. "View own orders of any type" does not work for such task.

I have no "Node reference" relation in my view. It is clean clone from default Commerce Shopping cart view.

@freelock like @prorokxp says, there are no node table joins in the query that I can find.
I don't think that is what is going on in this particular case.
Admittedly I have turned off query rerwiting and moved on, since I have to hit a deadline, but once I am done I indent to come back and spend some more time on this.

It doesn't need to be two instances of the node table -- it just needs to join a node table with a left join for the core bug to trigger a problem.

Here's a thoroughly unvetted patch to try -- after applying this patch, can you turn on SQL rewriting in the view and get the expected results?

If so, this is definitely the same issue. If not, it could be that my patch is incomplete -- it's checking specifically node_access applied to the node table, but there are also joins that might get written incorrectly to other entity tables. I don't yet have a good test case for that condition.

Also in my very quick backport from D8, I'm not noticing where the placeholders are generated -- this almost certainly is an incomplete patch -- what's missing are tests and improper placeholder name rewriting. If you hit that, you'll get a SQL error, so that's a pretty obvious fail ;-)

In any case, I'd love some feedback on whether this patch fixes this specific issue.

Patch fails to apply because it is against core, not commerce. Can I get somebody to test this locally to see if it indeed addresses this issue? If so, then perhaps we can get some more people reviewing the core issue ;-)

I can confirm that the problem still exists and happens in this query for my case (see the WHERE "1=0" at the end)

SELECT commerce_recurring.id AS id, commerce_recurring.status AS commerce_recurring_status, commerce_product_field_data_commerce_recurring_ref_product.product_id AS commerce_product_field_data_commerce_recurring_ref_product_p, commerce_recurring.uid AS commerce_recurring_uid, commerce_recurring.start_date AS commerce_recurring_start_date, commerce_recurring.due_date AS commerce_recurring_due_date, commerce_recurring.end_date AS commerce_recurring_end_date, 'commerce_recurring' AS field_data_field_subscription_topics_commerce_recurring_enti, 'commerce_product' AS field_data_field_recurring_cockpits_cardina_commerce_product FROM commerce_recurring commerce_recurring LEFT JOIN field_data_commerce_recurring_ref_product field_data_commerce_recurring_ref_product ON commerce_recurring.id = field_data_commerce_recurring_ref_product.entity_id AND (field_data_commerce_recurring_ref_product.entity_type = 'commerce_recurring' AND field_data_commerce_recurring_ref_product.deleted = '0') INNER JOIN commerce_product commerce_product_field_data_commerce_recurring_ref_product ON field_data_commerce_recurring_ref_product.commerce_recurring_ref_product_target_id = commerce_product_field_data_commerce_recurring_ref_product.product_id WHERE (( (commerce_recurring.uid = '8601' ) ))AND (1 = 0) ORDER BY id ASC LIMIT 50 OFFSET 0

I hope this example perhaps helps in the Discussion.
Removing the entity reference solves the problem.

FYI, I just added a new issue which might be due to the same underlying bug: #2155713: commerce_entity_access_query_alter can add crazy conditions if the base table does not match the entity type

124: commerce.cart_.1276450-124.patch queued for re-testing.

#5 and #6 not working for me. cache is cleared but no products for anon and authenticated users.

I got something. After putting the checkmarks in "View any [TYPE] product" and saving the page and getting the security warning i can see that there is no checkmark for "View any [TYPE] product" any more. So anon and authenticated users are not getting the needed permissions.

Is there any settings to handle this automatic security check?

I've found the solution. The "paranoia" module which was included in "drupal commons" was protecting the change of permissions. This module will not get listed in admin/modules page and you need to use drsuh to disable it.

confirm that this is still the issue and no solution worked for me

I can say definitively that the solution in most cases is to edit the View's query settings to disable SQL rewriting and use filters to control access to entities in the View's result. This has been described several times above, and having worked through the same issue on multiple sites now, it's the safe and most obvious solution.

Most Views in Commerce this applies to are going to limit their results to specific entities as a result of contextual filters passed in - a shopping cart order ID or a specific set of line items. In these cases, access control has already been performed, so I know, for example, that it's safe to disable SQL rewriting when joining from the cart View's line items to their referenced products. Even without the access control system determining if my user account technically has access to "view product 1", I know that since I added it to my cart it should be displayed to me.

The alternative, also documented above, would be to enable "view any product entity" permission for all users. That isn't a safe default recommendation, because we don't know what a particular site might be doing to display products to users dependent on the access check, but if you know it's safe for your site (i.e. because there's no way aside from product references for product entities to be displayed on your site), then it's also a fair solution.

About the only thing I can imagine us doing is determining product view access based on a user's access to view any other entity that references that product. I have no clue what that would do for performance of a site in general, especially on catalog pages, but I'm assuming it wouldn't be good.

Hi,

How about getting some help on the underlying issue, #1349080: node_access filters out accessible nodes when node is left joined? This is a fixable problem. The current patches over there need to be updated to properly generate placeholders for the database that can never collide, and there's some strange Postgres conflict happening.

If that core bug gets fixed and released, this one will resolve itself.

I do agree with Ryan that it is generally safe to disable SQL rewriting, though it's possible this could expose individual products to users who should not have access to them, if you have a complex access system... If the underlying issue gets resolved, entity access rules should enforce appropriately. If it doesn't, you need to enforce any such rules yourself in the view and disable SQL rewriting.

As per #134, if you have Commerce installed with Drupal Commons, in order to enable "view any product entity" permission for all users, you have to disable first the "paranoia" module which is included in Commons Distribution, and is protecting the change of permissions.

This module will not get listed in admin/modules page and you need drush to disable it : drush pm-disable paranoia. Very useful for me, thanks to Lameei !

I'm running into this issue as well.

I've created a custom view with a relationship to 'Commerce Line item: Referenced products'. When I do this an anonymous user sees nothing. If I disable sql rewriting then the user can at least see the line item total.

I also added the field 'Commerce Line item: Product' rendered in a specific view_mode similar to how the kickstart does it. An anonymous user does *not* see this field unless I enable the 'View any product of any type' permission. (I could use the view any [product] permissions).

So I'm not quite sure why I can't display that particular field unless the user has the extra permissions. The user can view the product display pages without issue.

Side note: the only reason I need this relationship is to get the product type so if there's another way I'm all ears, though I don't think removing that relationship solves my issue with displaying the rendered product field.

#4 worked for me. no idea what i'd do without this wonderful community!!!

#5 worked for me too. Thanks.

#5 worked for us as well
using views 7.10

We don't use commerce, but basic view with relationships and contextual filter.

The suggestion in #6 by 1kenthomas
Giving Permissions to Anonymous User to:
View any product of any type
Warning: Give to trusted roles only; this permission has security implications.
Seems to fix this problem problem more cleanly, without explicitly searching through all Views and changing setting there.

#4 worked for me and this solution was better than #6, because then anonymous user can search all the products.

#6 Did the trick. Thanks :)

how to display anonymous user history in view tab. anyone know about that. pls tell me as soon as possible. adv thanks

I have a store which has some products which all of them should be available to anon customers. is this safe to give persmission to anon users to view all product types?

It is not an option to use #4 or #6 for my organization's website. :(

Commerce Products do not have a direct way to be viewed - they do not have a direct front facing entity display path and are referenced through fields or Views. I'd say you are more than safe to give that permission to view product types, it's just a repercussion of the Drupal 7 Entity API - in my opinion.

So for #148 yes it has been addressed - in nearly every Commerce contrib module's queue. You either grant access to the product type permission OR on specific views disable rewriting. You should only have issues with the rewrite if you're using node access and the node table is not your base table - AFAIK.

If you're afraid of anonymous users seeing products.. well then your catalog is only available to authenticated users? Issue resolves itself on its own.

This is more of a documentation bug and general Drupa7WTF.

I'll second Matt to confirm it's completely safe to disable SQL rewriting whenever a View has some other mechanism of filtering the results. Heck, you can even add node access checking directly to a View's filter list if you want to.

The problem is... this isn't a bug. It's a support request, and there is no technical fix. The recommendations above are appropriate and safe to use. The challenge is reading people's minds to know what they're going to search for to find help when they encounter the issue, and developers are even worse mind readers than we are documenters.

Hi,

Actually, this is a bug, in Drupal core, and there is a fix, in #1349080: node_access filters out accessible nodes when node is left joined. It just has not been committed to Drupal core yet, because the fix is a bit brittle and may not work in all corner cases. It has to do with the node_access system, and any view that connects the node table or an entity table multiple times (e.g. via a relationship), when there is any access module enabled on the site, will trigger it.

Disabling SQL rewriting will bypass the issue, and should be entirely safe to do, unless you have some access rules you want to enforce (such as products in an OG group that only members of that group should be able to see) -- in which case you can usually address that by adding your own explicit filter to the view instead of relying on the core node access to filter it out for you.

If all your products are public, there's no need for this node_access check.

Cheers,
John

#4 worked for me also

#4 worked for me as well, solved a long running issue I have had for a while.

Same here, adding:

$handler->display->display_options['query']['options']['disable_sql_rewrite'] = TRUE;

as per #4 as workaround seems to work.

#4 don't work for me... and I have the last version of core drupal, commerce, views, rules...

Had the same problem with another (non-commerce) relationship and #4 helped. Thanks!

@rennevat

#4 worked for me..

Thanks man you save my ass.

AS per #4 and http://drupal.org/node/1276900#comment-4980066

edit your View > "Advanced" > "Query settings" : check "Disable Query Rewritting"

As #155, even disabling sql rewrite doesnt work work me. Fields of the nodes is not visible for anon users.

The solution for me was in #4 and http://drupal.org/node/1276900#comment-4980066

The answer is in http://drupal.org/node/1276900#comment-4980066

edit your View > "Advanced" > "Query settings" : check "Disable Query Rewritting"

All the best

Hans

After hours, it's just this "edit your View > "Advanced" > "Query settings" : check "Disable Query Rewritting""

Thx!

What's the next step here? Turning off query rewriting scares me...

wizonesolutions, what is the problem wit turning off query rewriting?

Hans

It means that the person maintaining the View has to have a full picture of security. This is OK sometimes, but sometimes the automatic access checking that third-party modules provide is useful, e.g. not showing nodes to users who don't have permissions to see them.

In my case, it's fine, since it's just a list of pricing plans, and I want everyone to see them.

@Wizonesolutions the underlying issue is #1349080: node_access filters out accessible nodes when node is left joined. The next step is to get that committed to core...

#6 worked for me..

Got the same issue, but not related to the Cart.

The attached patch fixes the access checking in query_alter() by allowing to select rows that left-join to non-existing commerce entities.

#167

I tried the patch cleared the cahche. But didn't worked well.

So reverted back and used Disable Query Rewriting which worked well for me for now.

Hopefully there will be a better solution in future.

Regards,
Amjad

@amjad1233 well, maybe you have another issue, not related to those query conditions.

#4 which is the same as #5 worked for me
patch in #167 did not work
permissions to view all products were already set

not using commerce, just views with flag module, Comment #5 worked for us, on this display only, adjusted views advanced query settings, disabled access controls.

 Disable access checks
Do not apply node_access checks to this query. Selecting this option omits that tag from the alterable query.

#174 link didn't help, went with comment #5 solution, works nicely.

Thanks

The parent issue of this Commerce-D7 issue should be the core-D7 issue rather than the core-D9 issue.

@pingwin4eg thank you for the patch in #167, that solved my issue:

I have a table of line items view, and I added a left join on the products, so that I could display some fields from a product if the line item referenced one, but that removed the line items which didn't reference a product.
Your patch allowed the rows that didn't left join a product in to be allowed again, and thus appear in the table.

From #150 @rszrama seems to be suggesting that nothing is going to get committed here, rather we'll document lots of use-cases and tradeoffs, and let people discover this issue and work out an appropriate fix for their site.
So is there actually a way forward to resolution for this ticket, should it be left open, with a clearer message in the issue summary about what the purpose of this ticket is? Or should we commit the bug fixes (like #167 but maybe handle that in its own 'bug report' ticket) that have been found and then close this ticket out?