Introduction
Security architecture is a comprehensive security design that considers the requirements and potential risks in a specific situation or environment. Additionally, it details where and when to implement security controls. In general, the design process is repeatable.
Clear design principles are reported in security architecture, and detailed security control specifications are typically recorded in separate documents. The system architecture is a design that includes a structure and addresses the connection between its parts.
Security Architecture
In Vaadin, All your application state, business logic, and UI logic reside on the server when using the server-side framework flow. A Flow application never exposes its internals to the browser, unlike client-driven frameworks, where a hacker could take advantage of security holes.
Through a single, secure endpoint, flow automates server and client communication. This endpoint has numerous built-in security features, which we go over in the following chapters.
The following example shows how to retrieve private user information from the database. However, we never reveal any client information that is not necessary:
-
A user clicks a button in the user interface (UI) to edit their data, like their name.
-
These two entities are translated from this click by the framework JavaScript and sent to the server:
- The distinct ID of the Button instance, which the framework had previously assigned sequentially;
-
The mouse information is related to the action taken with the button, in this case, a click (what type of click it was, and the associated cursor position).
-
Using the single server endpoint, the data is transmitted to the server. The correct user session is located by the application server using Servlet Session standard methods, and it is then provided to Vaadin along with the request payload.
-
Vaadin verifies the session data a second time and ensures a Button with the specified ID is present. If it does, the button's server-side click handler is called and given the event information.
-
The user information is retrieved from storage by the server-side code. Although it is not necessary to filter this data at this time, the developer may decide to do so if it is.
-
By designating it as the content for any components, the developer decides which portions of the data to display to the user.As an illustration, use nameTextField.setValue(user.getName()).
-
Vaadin does not retain references to the fetched data after the handler code has finished running. User IDs hashed passwords, and salts are just a few examples of data discarded because it is not explicitly set to be displayed.
-
The entire user object is not sent to the client for display; only the user name string is. Even the existence of a user object on the server side is unknown to the client.
- After the user changes the name, the new value is sent back to the server. The user object may be reloaded by the developer, given a new name, and kept on the server.
The example demonstrates that, even when working with UI code, the developer can safely handle sensitive data in their code. The framework only keeps information that the developer explicitly provides. Only information that belongs to the client is transmitted there.
19+ registered 
