Easy-digital-downloads: User cannot access own sales history through API's sales endpoint

[julien731]

I'm currently working on a project that involves querying the sales API endpoint from a customer to get his own sales history (using his API credentials). However...

I can see that the get_recent_sales() method only grants access to users with the view_shop_reports capability. Is there a reason why a user cannot access his own data using his API key and token (given that the email query param is provided... or not)?

I believe it would make sense to give a user access to his own information. We don't even need to check for the email query param in this case and only retrieve sales info for the owner of the API key. I'd be happy to send a PR for that, but I wanted to double-check with you in case I missed a security concern somewhere.

[cklosowski]

Note: I've updated the title to state cannot access, since that's the reported issue.

From a larger standpoint, I think it'd be interesting to offer access to customer data, however I think it should be through a different endpoint that simply the /sales endpoint for a couple reasons:
1) It leaves us open to bugs that could expose store information if the checks are done incorrectly
2) As it's a Restful API, the URL should be a little descriptive to what it's retrieving so I propose the following...

We should add a /my action to the Rest API that allows accessing information for the currently authenticated user (via API Keys). This means we can do things like:
/my/downloads
/my/licenses - when SL is active
/my/purchases

This gives a precedence that the user is accessing their own data, and since they are new endpoints that are crafted, we can easily limit it to just the authenticated user, without any risk of exposing store data if there is something wrong with the auth process.

Thoughts @easydigitaldownloads/core-devs?

[brashrebel]

I agree that it would be useful to allow customers a way to access their information and that the /sales endpoint is probably not the best choice. A /my endpoint is an interesting idea Chris. I've never seen that before, was that inspired by something you've seen or did you just come up with it? I know that Instagram has /users/self and I've seen other structures like that. We could consider /customers/self or something along those lines to direct customers through the /customers endpoint. Just a thought.

[julien731]

Really glad to see that you like the idea!

@cklosowski I agree with both points you made. Sounds like a better idea to use a new, dedicated endpoint. In terms of using descriptive endpoints, I like @brashrebel idea as it is self-explanatory and it also makes sense to have the "self" endpoint being sort of a child of the main customer one.

What is your recommended way to move forward with this (if at all)?

[cklosowski]

Yes this seems like it could work better. I hadn't thought of a subset action like /sales/self

If we do go this route, we need to be sure that the logic is self contained, meaning that the /self action doesn't run the same code to get data as the action for a user with view_shop_reports capabilities. That's simply just to avoid any unintended data leak, since it will be a completely different set of code that's being executed.

[cklosowski]

Some endpoints we could look into adding for EDD Core:
/sales/self - Give a list of sales
/downloads/self - Give a list of file downloads (similar to something like this, just included in core)
/customers/self - A general customer overview with sales, purchased downloads, etc.

With this precidence in core, then things like Software Licensing and Commissions could add endpoints like /licenses/self or /commissions/self.

While commissions already has an endpoint, I think moving to a more descriptive endpoint going forward would be useful.