DEV Community: illia wolkow

Best Practices for Storing Access Tokens in the Browser

illia wolkow — Fri, 07 Feb 2025 14:47:20 +0000

When searching for the best way to store auth tokens for one of my pet projects, I was overwhelmed by the amount of information. Here’s a concise summary to help navigate this complex topic.

I chose JWT (JSON Web Tokens) because they provide a compact and secure way to transmit information between parties. They ensure data integrity via signature verification but lack encryption by default, making the content visible if intercepted.

After diving deep into various methods, I've found that using HTTP-only cookies is the most secure way to store tokens and sensitive data in the browser:

Local Storage: Easily accessible via JavaScript, making it highly susceptible to XSS attacks.
Session Storage: Similar to local storage, it’s vulnerable to XSS attacks. Although the data is cleared when the page session ends, it's still exposed to the same security risks.
In-Memory Storage: While offering some isolation, it loses data on page reloads and significantly affects user experience. Moreover, it remains vulnerable to XSS attacks.
IndexedDB: Though more secure than local storage, it is complex to implement and still vulnerable to XSS attacks, exposing stored tokens if an attacker injects malicious scripts.
Web Workers: Provide some isolation but can still be compromised by XSS attacks. Implementing secure communication between workers and the main thread adds complexity.

Setting Up Secure HTTP-Only Cookies:

HTTP-Only Flag: Ensure cookies are not accessible via JavaScript to prevent XSS attacks.
Secure Flag: Enforce transmission over HTTPS to prevent interception.
SameSite Attribute: Set to Strict or Lax to prevent CSRF attacks.
Encryption: Encrypt cookie data to add an additional layer of security.

Here’s a visual representation of the threat matrix to illustrate the risks and mitigations:

Why HTTP-Only Cookies Are Superior: HTTP-only cookies mitigate these risks by preventing JavaScript access, ensuring tokens are only sent over secure connections (HTTPS), and adding protection against CSRF through the SameSite attribute.

Python Metaclasses: A Deep Dive

illia wolkow — Fri, 07 Feb 2025 14:42:33 +0000

In Python, classes are foundational elements that help us create and manage objects with specific attributes and behaviors. However, there’s an advanced concept that takes our understanding of classes to the next level: metaclasses. In this article, we’ll explore what metaclasses are, how they differ from regular classes, and how they are used in Python, particularly within frameworks like Django.

What is a Class?
A class in Python serves as a blueprint for creating objects. It defines a set of attributes and methods that its instances (objects) will have. For instance, if you have a Car class, it might have attributes like color and model, and methods like drive() and stop(). When you instantiate the class, you create an object with these attributes and behaviors.

What is a Metaclass?
A metaclass, on the other hand, is a class of a class. Just as classes define the behavior of objects, metaclasses define the behavior of classes themselves. The default metaclass in Python is type, which governs the creation and manipulation of classes. This concept allows you to customize how classes are constructed and how they behave.

Types of Metaclasses
Metaclasses in Python can be broadly categorized into two types:

Default Metaclass (type): This is the default metaclass used by Python. It handles the creation and initialization of all classes.
Custom Metaclasses: You can define your own metaclasses to tailor the creation and behavior of classes to meet specific needs.

Functions vs. Bound Methods
A common point of confusion is understanding the difference between functions and bound methods. When you call a method directly from a class, it behaves as a function and is not bound to any particular instance. For instance, consider this example:

Creating Class Combos with type
One of the most fun uses of metaclasses is creating classes dynamically using type. Here’s a code snippet that demonstrates how you can use type to create a class on the fly:

Metaclasses in Action: Django
Metaclasses play a crucial role in frameworks like Django. For example, Django’s ORM (Object-Relational Mapping) system uses metaclasses to manage model classes and their interactions with the database. Django’s metaclasses ensure that model classes follow the correct structure and behavior expected by the ORM, including methods for querying and manipulating data.

Conclusion
Metaclasses may seem complex at first, but they offer powerful tools for customizing the behavior of classes in Python. Whether you're building custom class behaviors or working with frameworks like Django, understanding metaclasses can provide you with deeper insights into Python’s object-oriented capabilities. I encourage you to explore metaclasses further and see how they can enhance your Python programming practices.

ACID in Databases: A Comprehensive Guide

illia wolkow — Fri, 07 Feb 2025 14:39:16 +0000

In database systems, transactions play a crucial role in ensuring data integrity and reliability. A transactional database allows operations to be executed as a single, atomic unit, ensuring that either all operations succeed or none at all. To achieve this level of reliability, databases adhere to the ACID properties: Atomicity, Consistency, Isolation, and Durability.

Decoding ACID
The term ACID refers to a set of four essential properties that guarantee transactions in a database are processed reliably. These properties are Atomicity, Consistency, Isolation, and Durability, and they work together to ensure the accuracy and integrity of a database, even in the event of system failures or concurrent access by multiple users.

Let's break down each of these properties.

Atomicity Atomicity ensures that a transaction is treated as a single, indivisible unit of work. Either all the operations within the transaction are completed successfully, or none are. If any part of the transaction fails, the database must roll back to its previous state, as if the transaction had never occurred.

For example, consider a bank transfer where money is moved from one account to another. The transaction involves two operations: subtracting money from the sender’s account and adding it to the recipient’s account. Atomicity guarantees that either both operations succeed, or neither operation happens, preventing inconsistencies.

Consistency Consistency ensures that a transaction brings the database from one valid state to another. After a transaction completes, the database must satisfy all integrity constraints (such as unique keys, foreign keys, etc.), ensuring that data remains valid and accurate.

For example, if a transaction updates the balance of a bank account, Consistency ensures that the new balance adheres to predefined rules, such as non-negative balances or limits on transactions.

Isolation Isolation ensures that transactions are executed independently of one another, even if they occur concurrently. Changes made by a transaction should not be visible to other transactions until the transaction is committed, preventing issues such as dirty reads, non-repeatable reads, and phantom reads.

There are various isolation levels that define the extent of this independence:

3.1 Read Committed
At the Read Committed isolation level, a transaction can only read data that has been committed by other transactions. Uncommitted changes made by other transactions are invisible, preventing dirty reads. However, Read Committed does not prevent non-repeatable reads, meaning a value could change if another transaction commits an update after the initial read.

3.2 Snapshot Isolation (Repeatable Read)
In Snapshot Isolation, also known as Repeatable Read, a transaction sees a consistent snapshot of the database as it existed at the start of the transaction. This ensures that once a value is read, it will not change for the duration of the transaction, preventing both dirty reads and non-repeatable reads.

3.3 MVCC (Multi-Version Concurrency Control)
Many databases, such as PostgreSQL, use a technique called Multi-Version Concurrency Control (MVCC) to implement snapshot isolation. MVCC allows the database to maintain multiple versions of data. Each transaction reads from its own consistent snapshot, preventing conflicts between transactions and improving performance in high-concurrency environments.

3.4 The Lost Update Problem
One problem that Isolation helps mitigate is the Lost Update problem, which occurs when two concurrent transactions read the same data and both update it based on the initial value. Without proper isolation, one transaction's update may overwrite the other's, resulting in data loss. Higher isolation levels, such as snapshot isolation, prevent this issue by ensuring transactions do not interfere with each other.

Solution 1: Atomic Updates (Optimistic Approach)
An atomic update ensures that a read-modify-write operation is executed as a single, indivisible unit. This is often achieved using SQL commands like UPDATE with an expression rather than first reading the value and then writing it back.

For the counter example, you can use a single SQL query that increments the value atomically:

In this approach, the database manages the concurrency internally. If multiple users try to update the counter simultaneously, the database handles the updates atomically, preventing lost updates.
Solution 2: Explicit Locking (Pessimistic Approach)
Explicit locking ensures that only one transaction can modify a piece of data at a time, while others must wait for the lock to be released. This approach can be used to prevent lost updates but may reduce performance in high-concurrency environments.

For example, in PostgreSQL, you can lock a row before updating the counter:

In this scenario, the
Solution 3: Automatic Lost Update Detection
Some databases offer mechanisms to automatically detect and resolve lost updates. One common technique is optimistic concurrency control, which uses versioning or timestamps to detect if a record has been modified by another transaction before allowing an update.

Durability Durability ensures that once a transaction has been committed, its changes are permanent and will survive any system failure (e.g., power loss, crashes). This is typically achieved by writing transaction data to non-volatile storage (like a hard drive or SSD) before the transaction is considered committed.

For example, in a bank system, once a transaction is completed and the changes (e.g., updated balances) are written to disk, Durability guarantees that those changes will persist even if the system crashes immediately afterward.

In summary, the ACID properties—Atomicity, Consistency, Isolation, and Durability—form the foundation of reliable and consistent transaction processing in databases. By adhering to these principles, databases can ensure data integrity and provide mechanisms for handling concurrent transactions without conflicts or data loss.

A popular method for detecting lost updates is using a version or timestamp column in the table. When a transaction updates a row, it checks if the version number is the same as when it initially read the row. If the version number has changed, the database knows another transaction has modified the data and can abort or retry the transaction.

For example, you can implement this logic as follows:

If the

Durability Durability ensures that once a transaction has been committed, its changes are permanent and will survive any system failure (e.g., power loss, crashes). This is typically achieved by writing transaction data to non-volatile storage (like a hard drive or SSD) before the transaction is considered committed.

"Why Composition is Better than Inheritance in OOP: A Practical Guide to Cleaner Code"

illia wolkow — Fri, 07 Feb 2025 14:32:54 +0000

Introduction
In the world of Object-Oriented Programming (OOP), developers often face the dilemma of choosing between inheritance and composition to share and reuse code. While inheritance has long been a fundamental OOP principle, it can lead to overly complex and rigid class hierarchies that are difficult to maintain. Composition, on the other hand, offers a more flexible and modular approach to building software. In this article, we will explore why composition is often a better choice than inheritance and how it can lead to cleaner, more maintainable code.

The Complexity of Inheritance Hierarchies
Inheritance allows classes to inherit properties and behaviors from a parent class, forming a hierarchy. While this can initially seem like an elegant solution, it quickly leads to complexity, especially in deep inheritance chains. When a class system has multiple levels of inheritance, understanding the relationships and encapsulation moments becomes increasingly difficult. Each subclass might override or extend behaviors from its parent class, leading to a tangled web of dependencies.

Encapsulation Issues: One of the core tenets of OOP is encapsulation—keeping the internal state of an object hidden and protected. Deep inheritance hierarchies can blur encapsulation, as subclasses gain access to the internals of their parent classes. This can result in unintended side effects when modifying base classes, breaking the encapsulation principle.

Tight Coupling and Rigid Structures
Inheritance creates a tight coupling between base and derived classes. Subclasses are dependent on their base classes, inheriting all their properties and methods. This tight coupling means that changes to a base class can have a ripple effect, impacting all subclasses. This rigidity makes it hard to adapt the system to new requirements or to reuse code in different contexts.

Composition Provides Flexibility: Composition offers a way to decouple classes and build more flexible systems. Instead of inheriting behavior, classes can be composed of other classes, allowing behavior to be shared and reused without creating a rigid hierarchy. By using composition, you can replace or modify parts of an object without affecting the entire system.

Favoring Composition Over Inheritance
The principle of "favor composition over inheritance" encourages developers to use composition to build more modular and flexible systems. In composition, objects are built using other objects as components. Each component has a distinct responsibility, and they work together to achieve the desired behavior.

Reuse Through Composition: Rather than inheriting all the functionality of a base class, composition allows you to create smaller, more focused classes that can be reused in various combinations. This granular approach enables you to build complex behavior by composing simpler, more manageable components.

Enhanced Maintainability and Testability
Composition leads to systems that are easier to maintain and extend. When using composition, you can modify or replace individual components independently, reducing the risk of unintended side effects. This modular design makes it easier to understand and modify the system as requirements change.

Better Testability: With composition, you typically end up with smaller, more focused classes that are easier to test in isolation. Dependencies can be injected and mocked, allowing for more comprehensive testing. This improves the overall test coverage and robustness of the system.

Real-World Examples
To illustrate the benefits of composition, let's consider a few examples:

Example 1: Vehicles Imagine a Vehicle class hierarchy where Car, Truck, and Motorcycle inherit from Vehicle. Each subclass might override methods to account for differences between these vehicles. Using composition, you can create a Vehicle class that contains instances of classes like Engine, Wheels, and Transmission. You can mix and match these components to create different types of vehicles without altering the class hierarchy.

Example 2: Bird Behaviors In a traditional inheritance model, you might have a Bird class with subclasses like FlyingBird and NonFlyingBird. This can become problematic if the behavior of flying changes. Using composition, you can have a Bird class that has a FlyBehavior component. Different birds can be assigned different flying behaviors (or none), making it easy to change behavior at runtime without modifying the class hierarchy.

When Inheritance Makes Sense
While composition offers many advantages, there are still cases where inheritance is the right choice:

Use for "Is-A" Relationships: Inheritance is suitable when there is a clear "is-a" relationship. For instance, a Dog class that inherits from an Animal class makes sense if the behavior of dogs is fundamentally tied to the concept of an animal.

Frameworks and Tooling: Inheritance is often used in frameworks to provide standard behaviors. For example, Django's class-based views use inheritance to define and extend the functionality of views. However, these cases are typically well-designed to avoid the pitfalls of deep inheritance hierarchies.

Conclusion
Composition often leads to cleaner, more maintainable, and flexible code compared to inheritance. By using composition, you can create systems that are easier to understand, test, and extend. You build complex behaviors by combining simple components, leading to a more modular design. However, inheritance is not obsolete and still has its place when there is a clear "is-a" relationship or when used judiciously within frameworks.

By favoring composition over inheritance, you embrace a more modular approach to software design, making your codebase easier to maintain and evolve over time.