Closed (fixed)
Project:
Commerce Ajax Add to Cart
Version:
7.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Reporter:
Created:
13 Sep 2014 at 14:56 UTC
Updated:
4 Nov 2015 at 15:39 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
drupalina commentedI have the same issue: the remove button gives "You don't have access permissions for this page" (regardless of browser) for authenticated users and anonymous users. Admins don't get this error.
I'd say this is a pretty major issue, if not critical.
Comment #2
drupalina commentedThe only way around this is to give Anonymous and Authenticated users "View Product of any type" permission. But that permission also notes "Warning: Give to trusted roles only; this permission has security implications." - I'm not yet sure what security implications are those, but this doesn't seem like the correct way of doing things.
It seems like the problematic line in dc_ajax_add_cart.module is
'access arguments' => array('view any commerce_product entity'),and something must be done about it.
Comment #3
subhojit777How about a separate permission for removing product from cart, the permission will be provided by module. By default every user role will have permission to remove products from cart. You can change it later. I hope this will fix the issue.
Comment #4
subhojit777Comment #5
joe huggansDid anyone figure out a fix for these issues? It seems like a pretty major bug to me, I will try have a look myself at some point in the next week as I have already set this module up in a site and really need to get it working. Other than this it is a really nice module.
Does anyone know, is this permission being declared as a hook within this actual module or is it coming from somewhere else?
I was having issues with Views showing up due to the fact that the view was using commerce products rather than the usual nodes /fields.
Maybe this is related? Please see here >> https://www.drupal.org/node/1276450
Comment #6
joe huggansFrom comment 136 on that page
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.
Comment #7
joe huggansAlso comment 137 seems to be claiming that this is the underlying issue
https://www.drupal.org/node/1349080
Comment #8
subhojit777The problem is this permission. I think the permission string is wrong, it does not matches with the job of the menu link.
I have searched for the functions that call
commerce_line_item_delete()(since this is the API function that removes product from cart), but there are no references of access there. Its like the function is simply called to delete line item.Also if you see the default cart page of Commerce Kickstart, you will see its a view. The view adds a commerce line item delete button, and the view does not has any special access role.

Therefore, it would be best if we use
'access arguments' => TRUEhere.More research and suggestions are welcome and patches too :)
Comment #9
subhojit777Comment #10
subhojit777Comment #11
alensaqe commentedIs this fixed yet!
Should we try the 'access arguments' => TRUE ?
Comment #12
joe huggansalensaqe it may be safe to allow that permission as mentioned above, it just depends how your products are displayed
Comment #13
subhojit777Drupal commerce does not provides any extra permission to remove items from cart. Adding a new permission for removing item from cart will add an extra layer. We will go with
'access callback' => TRUE, we will go along the same lines and will not add any new layer.Comment #15
subhojit777The last commit will fix the issue. Thanks!
Comment #18
iampumaAlso stumbled upon this issue and have changed the permission to "edit own commerce_order entities"
Comment #19
subhojit777@iampuma sorry didn't get you
Comment #20
iampumaSorry, apparently I skipped your comment above stating you would not implement a new permission, which makes sense in your reasoning that it would add an extra layer. So disregard my previous comment.