Using CRUD API to implement marketplace behavior

[Lucas001]

Hello everyone,

we currently have some thinkings about the security while using CRUD API.

What we want to have is something similar to all other marketplaces.

1. You have your page to select products - each product is only available once (First Dataverse table)
2. Those selections are submitted to a shopping cart (If needed 2nd table)
3. We assumed the best thing would be to now set a flag for the product so others cannot select it.
4. Purchase it which adds the item to a third table and runs a cloud flow deleting the entry from the first table

Issues we thought about.

• Somebody knowing how to use the API can just flag all products with a script and the page won't work as intended.
• Liquid is not working as the cache can not always be loaded in realtime which is needed
• The UPDATE function could be used to delete the flag so others can see the item again

Does somebody has a good approach for such a thing?

The CRUD API security documentation is a bit short, if one has experience there or can point out things to take care about, highly appreciated.

[OliverRodrigues]

"Purchase it which adds the item to a third table and runs a cloud flow deleting the entry from the first table"

Maybe this shouldn't be a Cloud Flow, but instead a classic Workflow or Dataverse Plug-in

"Liquid is not working as the cache can not always be loaded in realtime which is needed"

For critical validations, I would always consider server-side validations (via plug-ins) to make sure the data is getting to dataverse as expected

would that help? 

[Lucas001]

Hi @OliverRodrigues,

I think the first option could be a classic workflow or even the current option with a cloud flow as it would not be necessary to send that data in realtime, but rather that the customer gets a mail with the purchase data.

I have not that much experience with plug-ins, but from what I have seen so far, the validation would take place quiet similar to the CRUD Api, only that it's than server sided. Question for me would be here if the performance would be fast enough. Do you have a recommendation for more info? I found the MS Learn page not to cover the subject in details as I need it.

[OliverRodrigues]

By moving the validation to server-side, you could basically disable Portal API so nobody with the knowledge would be able to perform actions using the API, this would be one benefit.

In terms of performance, the logic itself will run super fast, but from a front-end perspective, in case there is an exception, the error is only thrown after page refresh, while if you are using the Web API this doesn't need a refresh as it's all client-side.

So it's more about UX vs validation accuracy. 

[Lucas001]

Hi @OliverRodrigues ,

if I use fetchXML for server side validation. Can FetchXML access the data even though it's currently not fetched for display into PowerPages due to the caching time?

My solution for now would be to use the localStorage to save some data and later on submit it via CRUD which also creates a row inside another table so that I can check in the end, if the item is not listed in both tables, and if it is the user gets a message that it's not longer available. If that is the best approach, I really don't know. That way I don't have to to give anybody the option to delete a row in any table.

[OliverRodrigues]

Apologies for the delay on coming back, using the localStorage I guess people might still have access to that via DevTools, so it's not 100% secure. 

In terms of Fetch and Cache, just add a condition for example, name != datetime.now (including milliseconds), this will force the query to be always different and basically bypass the cache.

[Lucas001]

Hi @OliverRodrigues,

I already started implementing the local storage solution.

I created a case where they will submit a JSON Object with there products. Even if they want to change it the CRUD API will read firstly and later submit. As I still face the issue that in case of using the devTools and forcing a submit directly that approach will be blocked by the suggestion of yours as a Flow controls whether or not a submission with those items has already been done. In case it is that way, I now know that somebody used the dev tools and can block the purchase as well as the user permanently.

Another way I thought about is to include a REST-Api to confirm that the purchase is allowed or not and later on submit it via that API. Do you have any further thoughts about that?

[OliverRodrigues]

That last API call would technically work, but you would again face similar issues, the API call is ultimately JS, and users could disable JS or something like that to bypass it. Please also note that the likelihood of this is very low.

I know you have play around with Dataverse plug-ins yet, but ultimately this would give you a lot more tools to enhance your project. There are plenty of tutorials/content on that and you seem to already be familiar with programming in general. Trust me, it sounds more scary than it actually is.

[Lucas001 · Accepted solution]

Hi @OliverRodrigues,

the best solution I found is to even limit security issues by letting people write into dataverse-tables (high risk of misbehaviour) is using a cloud flow. I yet have to test the performance but for the test scenario it seems to work.

What I did and probably helps others is creating a shopping cart where you can submit your data via flow. The flow is run asynchronously to display a loading spinner to improve the UX. The flow working as a middle ware compares data and returns nothing if the products are all available (success messsage) or the itemID of the non available products for further DOM-manipulation.

Thanks a lot for your time.