Question Feedback needed

[raysefo]

Hello there,

I have a web API, which calls 3rd party APIs. A client wants me to put daily sales limits based on terminals (cash registers in shops). I am calculating the current total sales in the AuthorizationFilterAttribute. There are 11 different items a client can purchase. In the request, I am getting the item code, there is no price. Price returns from the 3rd party APIs. In order to correctly calculate daily total sales based on a terminal, I have to know the current request's price. Now, I can add if statements but it is not manageable. I can create a table adding item codes and their prices but still, it is not so elegant. Further I will go to DB one more time. I am hesitant about how to solve, what are your suggestions?

Best Regards.

 

[jmcilhinney]

I am calculating the current total sales in the AuthorizationFilterAttribute.

That seems rather odd for a start. The purpose of that attribute is to determine whether the caller is authorised to make the call. If it is then the call is allowed and it's the called method that should then be doing the work and returning the data.

 

[Skydiver]

Recall his other thread. His clients have a daily limit for transactions. He is using the authorization filter to prevent the clients from doing further requests when they have reached their limit.

 

[raysefo]

yes exactly @Skydiver so what is your suggestion?

 

[Skydiver]

My recommendation is like a defense in depth approach.
The first layer is to have a simple table in your database that has just two columns: client id and daily total. This table contains the total of actual transactions successfully made by the client for that day. Obviously, you'll need some kind of background task to clear out the table on a daily basis. Your authorization filter will simply check this database for a quick check to see if the client is over their limit (or will be shortly over their limit if you have a known fixed cost for each transaction). There is no need to do anything slow or complicated here.

The second layer is to actually start performing the computations for the transaction requested. This can include your complicated logic for looking up the volatile daily prices. If the sum of this current transaction plus the current total in the database being used by the first layer goes over the limit, return the unauthorized error code. If the sum is still below the limit, then finish off the transaction and then update the database that is used by the first layer, and finally return the result requested by the client.

So yes, this has the issue where the client is almost at their limit, but not quite there so they keep on getting to the second layer where more work needs to be done. You could potentially implement some caching in your second layer so that if you see the same client and same transaction request, you can bypass a lot of the database lookups and calculations. If they keep on trying in rapid succession, hopefully, this will trigger your anti-DOS and anti-DDOS detection and you can start throttling/filtering the requests from that client. (You do plan on using/building anti-DOS and anti-DDOS protection, right?)