CanCan exception in Spree::Api::BaseController

[Zigreal]

Hi everybody! Can you please tell me if it makes sense that rescue_from CanCan::AccessDenied, with: :unauthorized returns 401 when the user is denied an action? For example, "authorize! :update, @order, order_token" - if I set a condition in the rights set that I can't update the order, then I'll get 401, not 403, because the controller has rescue_from CanCan::AccessDenied, with: :unauthorized. How can i get 403 in normal way?

[kennyadsl]

Good question! I don't have a real answer but I'll try to write some discussion points here to see if we can find the reason why it's like that. I'm assuming you are talking about the API, even if we might have similar logic in the other components as well.

First of all, it has been like that from the origin of that code, see 08656fb. I think the decision here has been to treat both cases (unauthorized and forbidden) in the same way, because there are resources that can be configured to be accessed by guests users as well, which do not require any authentication. To solve that case, being the permission set the single source of truth for who has access to a specific resource, someone decided that returning 401 for everything was enough.

That said, I think what you are saying makes a lot of sense and I think there's a better solution for this problem, which is probably implementing something similar to what has been proposed here: ryanb/cancan#659. Do you think that would be a proper solution?

[kennyadsl]

I guess it has just been considered good enough by Solidus users until now, or it has been patched locally and the solution has not been backported as Pull Request by anyone.

By the way, can I ask you which specific problem are you having with this in your application, other than of course being the right and expected thing to do?

[Zigreal]

I have some way out of the standard order flow. I am implementing a custom payment mechanism with payment pre-authorization, different from the standard one in Solidus, because my business does not involve storing user payment data. When the user goes to the payment section and clicks the "Pay" button, the order goes into the "pending payment" status (custom status), and the user gets to the payment system page. So that the user does not change the details of the order at this moment, I set the order modification block in the "waiting for payment" status. Accordingly, when the user tries to increase the number of positions from another tab before entering data on the payment form, he will receive a ban, but in status 401. On the front-end application, we have a redirect to the login page when we receive 401, so we noticed this.

[kennyadsl]

Oh, nice. I was looking at the other HTTP status codes and there are also other interesting ones for this use case:

• 402 Payment Required (reserved for future usage, but seems used by many)
• 409 Conflict (seems related to resources status)

Getting back to Solidus, to solve the issue mentioned, did you already try to override the rescue_from in the Spree::Api::BaseController with a decorator adding your custom logic? Is that enough?

[Zigreal]

Overriding resque_from solved my problem. But I think it's a good idea to send a pull request with a 403 return if the user is logged in.

[kennyadsl]

Yes, I agree. Feel free to send one!