DEV Community: Kevin Wasonga

Configuring Apache Fineract Properly: A Practical Guide.

Kevin Wasonga — Mon, 16 Jun 2025 05:48:20 +0000

I stumbled upon Apache Fineract the way many developers discover powerful open source tech while trying to solve a specific, real world problem.

If you’ve ever thought about how microfinance apps, digital lending platforms manage savings, loans, repayments, and customer accounts behind the scenes, there’s a good chance you were standing on the shoulders of systems like Fineract even if you didn’t know it yet.

Apache Fineract is a core banking engine designed for building financial services. It’s the kind of toolkit that can power microfinance institutions, fintech startups, digital wallets, and more. Think of it like an operating system but for money.

It’s open source, APIfirst, and extremely extensible. But like many powerful tools, it doesn’t come prepackaged with a nice “doubleclick start” installer. To get it running reliably, especially in production, proper configuration matters.

That’s where this guide comes in:
Let’s skip the marketing and focus on getting it done right.

📁 1️⃣ Repository and Directory Setup

git clone https://github.com/apache/fineract.git
cd fineract

Dependencies:

Java 17+
Gradle (wrapper provided)
MariaDB (preferred) or MySQL

🗄️ 2️⃣ Database Configuration (MariaDB Recommended)

Create the Main Database

CREATE DATABASE fineract_tenants CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Create a Fineract Database User

CREATE USER 'fineract'@'localhost' IDENTIFIED BY 'StrongPasswordHere';
GRANT ALL PRIVILEGES ON fineract_tenants. TO 'fineract'@'localhost';
FLUSH PRIVILEGES;

Ensure the user has:

CREATE
ALTER
DROP
INSERT
SELECT
UPDATE
DELETE

3️⃣ Configuring application.properties

Location:
fineractprovider/src/main/resources/config/application.properties

Key configurations to review/edit:

 Database Connection
fineract.datasource.url=jdbc:mariadb://localhost:3306/fineract_tenants
fineract.datasource.username=fineract
fineract.datasource.password=StrongPasswordHere

 Liquibase Migrations
fineract.database.schemausername=fineract
fineract.database.schemapassword=StrongPasswordHere

⚠️ Security Tip: Never commit application.properties with credentials to version control.

4️⃣ Running Database Migrations with Liquibase

./gradlew databaseMigration

Common Issue:
ERROR 1044 (42000) → Usually permission related → Verify user grants with:

SHOW GRANTS FOR 'fineract'@'localhost';

5️⃣ Running Fineract (Dev Mode)

./gradlew bootRun

Default REST endpoint (secured with basic auth):

https://localhost:8443/fineractprovider/api/v1/clients

6️⃣ HTTPS Configuration (Recommended for Production)

Recommended setup: Reverse Proxy with NGINX + Let’s Encrypt

Example nginx.conf snippet:

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    location / {
        proxy_pass https://localhost:8443/;
        proxy_set_header Host $host;
        proxy_set_header XRealIP $remote_addr;
    }
}

7️⃣ Configuring Tenants (MultiTenant Support)

Fineract supports multitenant architecture.

Example fineract_tenants.tenant_server_connections row:

INSERT INTO tenant_server_connections (id, tenant_identifier, schema_server, schema_name, schema_username, schema_password, schema_port)
VALUES (1, 'default', 'localhost', 'fineract_default', 'fineract', 'StrongPasswordHere', 3306);

Each tenant points to its own schema/database.

8️⃣ Logging Configuration

Location:
fineractprovider/src/main/resources/logbackspring.xml

Adjust log level here:

<root level="INFO">
    <appenderref ref="STDOUT"/>
</root>

Example change for debugging:

<root level="DEBUG">

Logs output:
build/fineract.log or console with bootRun

9️⃣ Externalized Configuration (Advanced)

For larger deployments:
Consider using Spring Cloud Config or environment variables to manage credentials securely.

Example override using environment variables:

export FINERACT_DATASOURCE_USERNAME=fineract
export FINERACT_DATASOURCE_PASSWORD=StrongPasswordHere

1️⃣0️⃣ API Authentication Configuration

API access requires Basic Auth by default.

curl u tenantId+username:password https://yourdomain.com/fineractprovider/api/v1/clients

For advanced deployments, consider integrating with OAuth2 or external Identity Providers.

1️⃣1️⃣ Docker (Optional)

Fineract does not yet maintain an official Dockerfile in the main repo, but you can find community supported ones here:
https://github.com/apache/fineract/pull/1922

Conclusion

Apache Fineract provides a serious foundation for modern fintech products but it expects you to know what you’re doing with configuration.

Get these pieces right, and you’ll have a reliable, extensible platform that can run everything from a neighborhood SACCO to the next big neobank startup.

Between You and the Server...

Kevin Wasonga — Tue, 13 May 2025 05:52:54 +0000

How Man-in-the-Middle Attacks Work And How to Stop Them

“In the digital realm, trust is the handshake that makes the internet work. A MITM attack? That’s someone silently slipping on gloves during that handshake.”

🌍 Welcome to the Digital AgeAnd Its Shadows
We live in an era where almost everything happens online: Sending money, ordering food, booking rides, paying bills, chatting with friends, filing taxes. The list is endless.
But here’s the twist. The more we rely on digital systems, the more attractive they become to attackers.
One of the oldest and most deceptive forms of cyber intrusion is the Man-in-the-Middle (MITM) attack and it’s still very much alive today.

🧅 What Is a Man-in-the-Middle Attack?
A MITM attack happens when someone silently inserts themselves between two parties who think they’re communicating directly.
Picture this. You text a friend to say “Send me that mobile money,” But someone intercepts the message, changes the details, and forwards a modified version without either of you realizing.You think you’re talking to each other. But there’s someone in the middle eavesdropping, altering, and exploiting.

🕸️ Real-World MITM Attack Scenarios
1. Public Wi-Fi Traps
That “Free_WiFi_CityMall” hotspot? Could be fake.
Once you connect, an attacker can inspect your traffic, stealing login credentials or injecting malicious scripts.
2. Session Hijacking
Attackers steal your session cookie and boom, they’re now logged in as you.
No password needed.
3. HTTPS Downgrade (SSL Stripping/ Secure Sockets Layer Stripping)
Some attackers force your connection to drop from HTTPS (secure) to HTTP (insecure), letting them read everything in plain text.

Common MITM Techniques
Packet sniffing is like overhearing conversations in a crowded café if the data isn’t encrypted, anyone nearby can listen. This technique involves monitoring network traffic to capture sensitive information such as login credentials, session cookies, and unencrypted messages. It is especially effective on unsecured networks. To defend against it, always use encrypted communication protocols such as Hypertext Transfer Protocol Secure (HTTPS), Secure Shell (SSH), or a Virtual Private Network (VPN).

Rogue hotspots, sometimes called “evil twins,” are fake wireless networks that mimic legitimate ones. Imagine a fake Wi-Fi called “CoffeeShop_WiFi” right next to the real one users connect to the imposter, thinking it’s safe. Once connected, the attacker can intercept traffic, capture login details, or inject malicious content. The best defense is to verify the network name with the provider, avoid connecting to open networks automatically, and use a VPN for encrypted traffic.

Address Resolution Protocol (ARP) spoofing is like someone impersonating your office's receptionist so that all incoming mail (network traffic) is rerouted to them. In this attack, the attacker sends forged ARP messages on a local network, tricking devices into sending data through the attacker’s machine instead of the legitimate gateway. This allows the attacker to intercept, modify, or block data. Defenses include enabling Dynamic ARP Inspection (DAI), using static ARP entries, and encrypting all sensitive traffic.

Domain Name System (DNS) spoofing .The attacker corrupts the DNS responses received by the user, redirecting them from a legitimate website to a malicious one that looks identical. This can result in stolen credentials or malware infections. Protection involves using Domain Name System Security Extensions (DNSSEC), choosing trusted DNS resolvers, and verifying digital certificates in browsers.

Secure Sockets Layer (SSL) stripping works like convincing someone to do a confidential transaction outside the bank instead of inside the secure vault. The attacker intercepts the initial HTTP request and prevents it from upgrading to HTTPS, keeping the entire session unencrypted. Victims may not notice because the site still loads. Defense mechanisms include implementing HTTP Strict Transport Security (HSTS), always typing or bookmarking HTTPS URLs, and staying alert for missing browser security indicators.

Final Thoughts
MITM attacks are like digital pickpocketing. You may not notice it happening until your data, money, or identity is long gone.
They exploit: Trust in systems. Weak configurations . A lack of awareness

“Online, trust must be earned. But more importantly it must be encrypted.”

Decoding Django: How Migration Errors Became My Greatest Teacher

Kevin Wasonga — Thu, 20 Mar 2025 06:04:06 +0000

Working with Django: Understanding InconsistentMigrationHistory Error Messages

While building a Django project with multiple apps, I once encountered an error that left me scratching my head:

django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency accounts.0001_initial on database 'default'

At first glance, it seemed cryptic, but I soon learned that decoding error messages is a vital debugging skill. Here’s how I gradually approached the problem:

Read the Error Message Carefully:

The error told me that Django expected the accounts.0001_initial migration to be applied before admin.0001_initial. This meant my migration history was out of order.
Review Migration Dependencies:

I checked the migration files in both apps. The admin app had a dependency declared on the accounts app. This confirmed that my migration sequence was the issue.
Roll Back Migrations:

To reset the order, I rolled back the problematic migrations:

bash python3 manage.py migrate admin zero python3 manage.py migrate accounts zero

This cleared the applied migrations for these apps in the database.

Reapply Migrations Correctly: Once the rollback was complete, I re-ran the migrations:

bash python3 manage.py migrate

This recreated the database schema in the correct order, satisfying all dependencies.

Learn and Reflect: Debugging this error reminded me that understanding migration dependencies and reading error messages carefully is as crucial as writing code. Each error is a learning opportunity, turning a seemingly frustrating moment into a step forward in my Django journey.

In the end, a systematic, procedural approach not only solved the error but also enhanced my understanding of Django’s migration system. Debugging truly is an art—one that sharpens with every error message you decode.

Pointers in Go: An In-Depth Guide to Referencing and DereferencingPointers in Go

Kevin Wasonga — Sun, 27 Oct 2024 04:24:08 +0000

In programming, especially in languages like Go, understanding how to manage memory efficiently is crucial. One of the key concepts in this domain is the use of pointers, which allows developers to reference memory addresses rather than the actual data. This guide will explore the concepts of referencing and dereferencing using practical examples, making the abstract idea more concrete.

What are Referencing and Dereferencing?

Referencing: This is the process of obtaining the memory address of a variable. When you reference a variable, you essentially point to its location in memory, allowing you to interact with the data at that specific address without duplicating it. This is particularly useful when passing data to functions, as it can reduce memory usage and improve performance.
Dereferencing: This is the opposite of referencing. When you dereference a pointer, you access or manipulate the actual value stored at the memory address pointed to by the pointer. Dereferencing allows you to retrieve or change the data in memory directly through the pointer, providing flexibility in managing the variable's value.

Symbols for Referencing and Dereferencing

Referencing with &:
- Symbol: &
- Purpose: Used to get the memory address of a variable.
- Context: Imagine you want to know exactly where a specific resource is stored in a warehouse. By using &, you ask for the location or "address" of that resource rather than the resource itself.
- Example:
```
 x := 7        // Define variable x with value 7
 y := &x       // Reference x; y now holds x's memory address
 fmt.Println(y) // Prints x's memory address (e.g., 0xc000018090)
```

In this example, y stores the address of x, not the value 7. We’ve used &x to retrieve where x is stored in memory.

Dereferencing with *:
- Symbol: *
- Purpose: Used to access the value stored at a specific memory address (or "follow" a reference to get the original data).
- Context: Going back to our warehouse analogy, dereferencing is like using the directions (address) you have to reach the warehouse and see what’s actually inside. When you dereference, you’re asking to see or use the data that the address points to.
- Example:
```
 x := 7          // Define variable x with value 7
 y := &x         // Reference x; y now holds x's memory address
 z := *y         // Dereference y to access x's value
 fmt.Println(z)  // Prints 7, which is the value stored at the address y points to
```

Here, *y dereferences y, meaning it accesses the actual value stored at y's address, which is 7.

How Referencing and Dereferencing Work Together

Referencing is about finding the "where" — it gives you the address of a variable. This is helpful if you want to pass around where something is stored instead of making a copy of it.
Dereferencing is about accessing the "what" — it follows the address to retrieve or modify the actual value.

Practical Example

package main

import "fmt"

func main() {
    x := 10               // Step 1: Define variable x with a value of 10
    y := &x               // Step 2: Reference x with &, assigning x's address to y
    fmt.Println("Address of x:", y) // Step 3: Print x's address (memory location)

    z := *y               // Step 4: Dereference y to get the value at that address
    fmt.Println("Value of x accessed via y:", z) // Prints 10, the value at y’s address

    *y = 20               // Step 5: Change value at y’s address (which is x’s value)
    fmt.Println("Updated value of x:", x) // Prints 20, showing x is updated
}

Explanation of Symbols in the Code:

&x - References x to get its memory address, storing that address in y.
*y - Dereferences y, accessing the value stored at x's memory address.

Output:

Address of x: 0xc000018090
Value of x accessed via y: 10
Updated value of x: 20

In this example, y holds the location of x, and *y (dereferencing y) lets us read or modify x's value directly through that address.

Mastering bufio.NewScanner vs os.ReadFile In Go(Golang)

Kevin Wasonga — Mon, 23 Sep 2024 20:36:03 +0000

Mastering bufio.NewScanner vs os.ReadFile In Go(Golang)
As a Go developer, I initially found the numerous file reading methods somewhat overwhelming. But as I dug deeper, I came to understand that knowing the distinctions between bufio.NewScanner and os.ReadFile is key to performing file I/O efficiently. In this article, we'll take a closer look at both functions, their specific use cases, and how to decide which one to use for better performance and memory management.
bufio.NewScanner : Line-by-line Reading with Buffering
The bufio.NewScanner function, from the bufio package, initializes a new Scanner that reads input from an io.Reader. It's specifically designed for efficient, buffered reading of data line by line, making it ideal for processing large text inputs without loading the entire file into memory.

Below is how bufio.NewScanner works :

It initializes an internal buffer and reads data from the provided io.Reader into this buffer. 2. The Scanner.Scan() function reads data from the buffer and splits it into tokens (by default, it splits on newlines).
Each time Scan() is called, it reads data from the underlying reader and fills the buffer as needed, then scans the buffer for the next token.
The Scanner.Text(), function returns the current token as a string. In the code shown below, os.OpenFile is typically used as the io.Reader. The os.File type implements the io.Reader interface, so that it can be passed directly to bufio.NewScanner.

file, err := os.OpenFile("file.txt")
if err != nil {
// handle error
}
defer file.Close()
scanner := bufio.NewScanner(file)
for scanner.Scan() {
line := scanner.Text()
// process the line
}

The Key advantage of bufio.NewScanner is its efficiency, especially when reading large files or streams of data
os.ReadFile: Reading the Entire File into Memory
The os.ReadFile(filename string) ([]byte, error) function, part of the os package, reads the entire contents of a file into a byte slice. It's a simple and straightforward way to read a file, but it loads the entire file into memory, which can be inefficient for large files or data streams.

data, err := os.ReadFile("file.txt")
if err != nil {
// handle error
}
// data is a byte slice containing the entire file contents
Unlike bufio.NewScanner, the os.ReadFile function does not use buffering or line-by-line reading. Instead, it reads the entire file content into a byte slice in one operation. This approach can be convenient when you need to process the entire file at once or when working with small files. Here's a breakdown of how os.ReadFile works:

The function takes a file path as an argument and attempts to open the file. 2. If the file is opened successfully, it reads the entire contents of the file into a byte slice 3. The byte slice containing the file contents is returned, along with any potential error that may have occurred during the reading process.
You will need to use string() to convert the byte slice into a string.

However, it's important to note that os.ReadFile has a limitation on the file size it can read. On most Unix-like systems, the maximum file size that can be read is limited by the available virtual
memory, which can be a constraint for very large files.
When to Use bufio.NewScanner vs. os.ReadFile
As a general rule, you should use bufio.NewScanner when you need to process a large file or stream of data, especially if you're reading line by line or using a custom delimiter. It's more memory-efficient and allows you to process the data as it's being read.
On the other hand, os.ReadFile can be a more convenient option if you're working with small files or you need to process the entire file at once.
Conclusion
In Go, bufio.NewScanner and os.ReadFile provide two distinct ways to read file contents. bufio.NewScanner excels in reading large files or data streams efficiently, line by line, with buffering. This makes it ideal for handling big files or custom-delimited data where memory
consumption is a concern. By processing data as it’s read, bufio.NewScanner minimizes memory usage, preventing issues like out-of-memory errors when working with large files.
Conversely, os.ReadFile reads an entire file into memory at once, offering simplicity and convenience for smaller files. While it's less efficient for large files due to potential memory overhead, it avoids the complexity of buffered reading.
Choosing between these two depends on your file size, memory limitations, and whether you need to process data line-by-line or all at once. For large files, bufio.NewScanner is the go-to option for performance and memory management. For small files, os.ReadFile can simplify your code.
Understanding when to use each ensures your Go programs handle file reading efficiently, optimizing both performance and resource use.