How to separate insecure from critical logic?
Follow me on Medium
Original article
Where does business and UI logic live?
These are the business rules, validations, and calculations that operate on the data as it is brought into an information system or displayed by it. — Martin Fowler
Your services are in the business layer. Business rules that you apply to data, and create conclusions on the data.
Your controllers are in the UI layer, responsible for UI, pages, and simple logic around them.
Why is the business layer critical?
Let’s explain in layman’s terms.Laurent S.has a great explanation for this topic. I’ll try to deliver his words, with my own opinion attached.
Let’s look at the truck loading process. There are two workers.
One loads the truck, the worker, one is supervising, the supervisor. Worker represents presentational logic. Supervisor — business rules.
The supervisor cares about the truck weight.How much the truck can carry?— business rule.
The worker puts the boxes in the truck. The worker decides_where to put the box_— presentation logic.
When you don’t have a supervisor, you need to teach the worker the rules. Let’s say it is a simple rule, 1 tone is the weight limit.
Your business expands, you hire more workers (mobile, desktop, other devices). You teach them this rule.
New rules come. Now you need to adhere to the laws of the country. Laws change too often.
You have two options here:
- Hire lawyers to fill the truck.
- Workers call the lawyer.
Let’s say you pick lawyers to fill your truck. They know the laws and can figure out the weight limit.
In software terms, you put more logic in your presentational layer.
The other option is more beneficial. Workers call the lawyer, get an answer if they continue loading or stop.
In software terms, add business rules to the business layer, which UI can call for information.
What‘s wrong to do in the UI?
Don’t deceive your customers. Look at this article below.
Don’t lie about active customers. Any developer will see through this lie.
Solve this on the backend. Look at active sessions, and extra info to identify the product. A product which the customer is looking at.
Query the backend for data. Calculate active customers, and respond to the UI layer.
Don’t do your business logic on the frontend. Don’t calculate promotions on the frontend, for example.
Act on the data on the back-end. Hide sensitive info from the front-end.
Keep your promo rules in the backend. Promotions are conditions and actions. You do need some rule engine to decide if the promotion is valid.
After the decision is made, apply promotion, and return the page. In a headless approach, you call the promo API to get the information.
Seems logical, yet we have bad examples.
What’s appropriate in the UI layer?
Access the backend logic. Send promo codes. Get back the response. Or embed in the page applied promotion.
Call the backend, get relevant active users to count, and present it on the UI. The backend should calculate this count. Not jQuery.
Don’t do this —source
Conclusion
These are few examples of how to combat unwanted behavior.
Do your critical rules on the backend. Check promotions, develop algorithms, on the backend. Less critical ones can go on the frontend. Develop conditional styling in this layer.
With this, you can rest assured, your app is protected. Protected from unwanted behavior.
Resources
Most of this topic was derived from thisquestion.
Top comments (0)