Hi there,

I updated yesterday one of my test site to the latest and greatest
1-3-stable.
In this site, I have created a custom role. Any user with that role should
only be able to access part of the admin section
To that end, I created an ability_decorator to add the specific actions
that the new role can do. The ability_decorator was then added to
Spree::Ability using

Spree::Ability.register_ability(Spree::AbilityDecorator)
This decorator contains for instance
can :manage, Spree::Order

It all worked well until the commit "6b0de3179e =>Add instance level
permissions in Admin controller"

Using the custom role, I am not able to access the Orders tab in the admin
section anymore => Authorization failure

More precisely, the following line was added in the order_controller, in
the load_order method

def load_order
@order = Order.find_by_number!(params[:id], :include => :adjustments)
if params[:id]
* authorize! params[:action], @order*
end

Removing that line is enough to gain access again to the orders tab.

I believe that my ability_decorator is not being used, or the
Spree::Ability might be created again without using the AbilityDecorator

Anyone know what might be going on? Why are the ability_decorator not being
used anymore?

Thanks for any input,

Cheers,
Michael

--
You received this message because you are subscribed to the Google Groups "Spree" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Ryan Bigg at Feb 17, 2013 at 10:33 pm
    Hey Michael,

    Have you been able to fix this error yet?

    If not, do you have an application which reproduces the issue?

    On Fri, Feb 8, 2013 at 1:42 AM, Michael Sevestre wrote:

    Hi there,

    I updated yesterday one of my test site to the latest and greatest
    1-3-stable.
    In this site, I have created a custom role. Any user with that role should
    only be able to access part of the admin section
    To that end, I created an ability_decorator to add the specific actions
    that the new role can do. The ability_decorator was then added to
    Spree::Ability using

    Spree::Ability.register_ability(Spree::AbilityDecorator)
    This decorator contains for instance
    can :manage, Spree::Order

    It all worked well until the commit "6b0de3179e =>Add instance level
    permissions in Admin controller"

    Using the custom role, I am not able to access the Orders tab in the admin
    section anymore => Authorization failure

    More precisely, the following line was added in the order_controller, in
    the load_order method

    def load_order
    @order = Order.find_by_number!(params[:id], :include => :adjustments)
    if params[:id]
    * authorize! params[:action], @order*
    end

    Removing that line is enough to gain access again to the orders tab.

    I believe that my ability_decorator is not being used, or the
    Spree::Ability might be created again without using the AbilityDecorator

    Anyone know what might be going on? Why are the ability_decorator not
    being used anymore?

    Thanks for any input,

    Cheers,
    Michael


    --
    You received this message because you are subscribed to the Google Groups
    "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brian Quinn at Feb 18, 2013 at 9:38 am
    Michael,
    Can you paste your Spree::AbilityDecorator file?


    --
    Brian Quinn

    Co-Founder, CTO
    Spree Commerce, Inc.
    http://spreecommerce.com

    On Thursday 7 February 2013 at 14:42, Michael Sevestre wrote:

    Hi there,

    I updated yesterday one of my test site to the latest and greatest 1-3-stable.
    In this site, I have created a custom role. Any user with that role should only be able to access part of the admin section
    To that end, I created an ability_decorator to add the specific actions that the new role can do. The ability_decorator was then added to Spree::Ability using

    Spree::Ability.register_ability(Spree::AbilityDecorator)
    This decorator contains for instance
    can :manage, Spree::Order

    It all worked well until the commit "6b0de3179e =>Add instance level permissions in Admin controller"

    Using the custom role, I am not able to access the Orders tab in the admin section anymore => Authorization failure

    More precisely, the following line was added in the order_controller, in the load_order method

    def load_order
    @order = Order.find_by_number!(params[:id], :include => :adjustments) if params[:id]
    authorize! params[:action], @order
    end


    Removing that line is enough to gain access again to the orders tab.

    I believe that my ability_decorator is not being used, or the Spree::Ability might be created again without using the AbilityDecorator

    Anyone know what might be going on? Why are the ability_decorator not being used anymore?

    Thanks for any input,

    Cheers,
    Michael


    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com (mailto:spree-user+unsubscribe@googlegroups.com).
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brian Quinn at Feb 19, 2013 at 9:43 am
    Hi Michael,
    Thanks for all the detail, its my understanding that CanCan doesn't fail if you don't meet the requirements of a particular rule, it will evaluate everything.

    I'm not sure how the "cannot" directive affects that statement, but it looks like you're not using any cannots anyway.

    I'd suggest you add some debugging and confirm that you are indeed hitting the has_spree_role?('owner') check (using the standard approach)?



    --
    Brian Quinn

    Co-Founder, CTO
    Spree Commerce, Inc.
    http://spreecommerce.com

    On Monday 18 February 2013 at 19:16, Michael Sevestre wrote:

    Hi there,

    I am in Europe now and don't have access to my files, but here is what I believe happened off the top of my head

    The default ability in Spree::Core looks sthg like this (copied from Github)

    if user.respond_to?(:has_spree_role?) && user.has_spree_role?('admin')
    can :manage, :all
    else
    ....
    ....
    can :read, Order do |order, token|
    order.user == user || order.token && token == order.token
    end
    can :update, Order do |order, token|
    order.user == user || order.token && token == order.token
    end


    ....
    end if

    My Spree::AbilityDecorator added sthg like that

    if user.has_spree_role(:owner)
    can :manage, Order
    ....

    I believe the problem resides in the fact that my custom abilities are loaded *after* the default one.
    That means that for a non admin user having my custom defined role owner, cancan would see *first* that an existing order can only be read by a user that owns the order *and then* see the second rule, which although more generic (:manage), is simply ignored.

    The addition in commit
    authorize! params[:action], @order

    now passes an existing order instance instead of order.new which makes the first rule
    can :read, Order do |order, token|
    order.user == user || order.token && token == order.token
    end

    fail


    What I ended up doing is overriding completely the Ability file from spree and adding my custom logic like so:

    if user.has_spree_role?('admin')
    can :manage, :all
    else if user.has_spree_role?('owner')
    my logic here
    else
    default Spree::Core logic

    end

    It's not DRY since I have to duplicate the code from Spree::Core. But it does work.

    In conclusion, I think it is possible to add more constraints to cancan using an AbilityDecorator. But I don't think that it's actually possible to remove or soften constraints.

    Makes sense?

    Cheers,
    Michael
    ....
    On Mon, Feb 18, 2013 at 10:38 AM, Brian Quinn (mailto:brian@spreecommerce.com)> wrote:
    Michael,
    Can you paste your Spree::AbilityDecorator file?


    --
    Brian Quinn

    Co-Founder, CTO
    Spree Commerce, Inc.
    http://spreecommerce.com


    On Thursday 7 February 2013 at 14:42, Michael Sevestre wrote:


    Hi there,

    I updated yesterday one of my test site to the latest and greatest 1-3-stable.
    In this site, I have created a custom role. Any user with that role should only be able to access part of the admin section
    To that end, I created an ability_decorator to add the specific actions that the new role can do. The ability_decorator was then added to Spree::Ability using

    Spree::Ability.register_ability(Spree::AbilityDecorator)
    This decorator contains for instance
    can :manage, Spree::Order

    It all worked well until the commit "6b0de3179e =>Add instance level permissions in Admin controller"

    Using the custom role, I am not able to access the Orders tab in the admin section anymore => Authorization failure

    More precisely, the following line was added in the order_controller, in the load_order method

    def load_order
    @order = Order.find_by_number!(params[:id], :include => :adjustments) if params[:id]
    authorize! params[:action], @order
    end


    Removing that line is enough to gain access again to the orders tab.

    I believe that my ability_decorator is not being used, or the Spree::Ability might be created again without using the AbilityDecorator

    Anyone know what might be going on? Why are the ability_decorator not being used anymore?

    Thanks for any input,

    Cheers,
    Michael


    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com (mailto:spree-user+unsubscribe@googlegroups.com).
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com (mailto:spree-user%2Bunsubscribe@googlegroups.com).
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com (mailto:spree-user+unsubscribe@googlegroups.com).
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Michael Sevestre at Feb 27, 2013 at 3:49 pm
    Hey guys,

    I believe that the problem might be due to
    https://github.com/spree/spree/pull/2609

    I'll check the problem again once the PR is merged

    Cheers,
    Michael
    On Tue, Feb 19, 2013 at 10:43 AM, Brian Quinn wrote:

    Hi Michael,
    Thanks for all the detail, its my understanding that CanCan doesn't fail
    if you don't meet the requirements of a particular rule, it will evaluate
    everything.

    I'm not sure how the "cannot" directive affects that statement, but it
    looks like you're not using any cannots anyway.

    I'd suggest you add some debugging and confirm that you are indeed hitting
    the has_spree_role?('owner') check (using the standard approach)?



    --
    Brian Quinn

    Co-Founder, CTO
    Spree Commerce, Inc.
    http://spreecommerce.com

    On Monday 18 February 2013 at 19:16, Michael Sevestre wrote:

    Hi there,

    I am in Europe now and don't have access to my files, but here is what I
    believe happened off the top of my head

    The default ability in Spree::Core looks sthg like this (copied from
    Github)


    if user.respond_to?(:has_spree_role?) && user.has_spree_role?('admin')
    can :manage, :all
    else
    *....*
    * ....*

    can :read, Order do |order, token|
    order.user == user || order.token && token == order.token
    end

    can :update, Order do |order, token|
    order.user == user || order.token && token == order.token
    end

    * ....*
    * *end if

    My Spree::AbilityDecorator added sthg like that

    if user.has_spree_role(:owner)
    can :manage, Order
    ....

    I believe the problem resides in the fact that my custom abilities are
    loaded *after* the default one.
    That means that for a non admin user having my custom defined role *owner*,
    cancan would see *first* that an existing order can only be read by a user
    that owns the order *and then* see the second rule, which although more
    generic (:manage), is simply ignored.

    The addition in commit

    *authorize! params[:action], @order*

    now passes an existing order instance instead of order.new which makes the
    first rule

    can :read, Order do |order, token|
    order.user == user || order.token && token == order.token
    end

    fail


    What I ended up doing is overriding completely the Ability file from spree
    and adding my custom logic like so:

    if user.has_spree_role?('admin')
    can :manage, :all
    else if user.has_spree_role?('owner')
    my logic here
    else
    * default Spree::Core logic*

    * *end

    It's not DRY since I have to duplicate the code from Spree::Core. But it does work.

    In conclusion, I think it is possible to add more constraints to cancan using an AbilityDecorator. But I don't think that it's actually possible to remove or soften constraints.

    Makes sense?

    Cheers,
    Michael
    * ....*

    On Mon, Feb 18, 2013 at 10:38 AM, Brian Quinn wrote:

    Michael,
    Can you paste your Spree::AbilityDecorator file?


    --
    Brian Quinn

    Co-Founder, CTO
    Spree Commerce, Inc.
    http://spreecommerce.com

    On Thursday 7 February 2013 at 14:42, Michael Sevestre wrote:

    Hi there,

    I updated yesterday one of my test site to the latest and greatest
    1-3-stable.
    In this site, I have created a custom role. Any user with that role should
    only be able to access part of the admin section
    To that end, I created an ability_decorator to add the specific actions
    that the new role can do. The ability_decorator was then added to
    Spree::Ability using

    Spree::Ability.register_ability(Spree::AbilityDecorator)
    This decorator contains for instance
    can :manage, Spree::Order

    It all worked well until the commit "6b0de3179e =>Add instance level
    permissions in Admin controller"

    Using the custom role, I am not able to access the Orders tab in the admin
    section anymore => Authorization failure

    More precisely, the following line was added in the order_controller, in
    the load_order method

    def load_order
    @order = Order.find_by_number!(params[:id], :include => :adjustments)
    if params[:id]
    * authorize! params[:action], @order*
    end

    Removing that line is enough to gain access again to the orders tab.

    I believe that my ability_decorator is not being used, or the
    Spree::Ability might be created again without using the AbilityDecorator

    Anyone know what might be going on? Why are the ability_decorator not
    being used anymore?

    Thanks for any input,

    Cheers,
    Michael


    --
    You received this message because you are subscribed to the Google Groups
    "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.




    --
    You received this message because you are subscribed to the Google Groups
    "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.




    --
    You received this message because you are subscribed to the Google Groups
    "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.




    --
    You received this message because you are subscribed to the Google Groups
    "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupspree-user @
categoriesrubyonrails
postedFeb 7, '13 at 2:42p
activeFeb 27, '13 at 3:49p
posts5
users3
websitespreecommerce.com
irc#RubyOnRails

People

Translate

site design / logo © 2022 Grokbase