Monday, January 6 2025 \u2013 Last week, I focused on developing the UI for the sign-in functionality. During this process, I discovered an intriguing security feature: the token received from the API is frequently used to retrieve data that requires authorization. This piqued my interest, as I had always wondered how authorization is managed on the front end.<\/p>\n\n\n\n
The token is retrieved and then stored in a cookie. A cookie is a small piece of data stored on the user’s device by their web browser. It allows the website to remember information about the user, such as authentication details, across sessions or requests.<\/p>\n\n\n\n
In addition to the sign-in page, I worked on creating related UI elements, such as the edit page. One aspect I found particularly interesting was the process of calling an API to retrieve an entity. To ensure that the user making the request has the necessary privileges, the token must be sent for validation. Unlike passing an ID directly in the URL, which could expose sensitive data, the token is sent securely in the request headers.<\/p>\n\n\n\n
This was my first time encountering token-based authorization in this way, and it was a fascinating learning experience.<\/p>\n\n\n\n
Next, I shifted to working on another entity. I started by designing the UI, incorporating a dropdown button that supports nested input fields. These fields are dynamically populated based on data retrieved from the API. Once the UI was complete, I moved to the backend to create the API query list that the UI would use.<\/p>\n","protected":false},"excerpt":{"rendered":"
Monday, January 6 2025 \u2013 Last week, I focused on developing the UI for the sign-in functionality. During this process, I discovered an intriguing security feature: the token received from the API is frequently used to retrieve data that requires authorization. This piqued my interest, as I had always wondered how authorization is managed on … <\/p>\n