Jonathan Lalou's Blog

Archive for the ‘General’ Category

In an engaging and humorous presentation at NDC Melbourne 2025, Lee Dunkley explores how Domain-Driven Design (DDD) can prevent software projects from spiraling into chaotic, unmaintainable codebases—likening such failures to Australia’s infamous Emu War. By drawing parallels between historical missteps and common software development pitfalls, Lee illustrates how DDD practices, such as event storming and ubiquitous language, can steer teams toward solving the right problems, thereby enhancing maintainability and extensibility.

The Emu War: A Cautionary Tale for Coders

Lee begins with a whimsical analogy, recounting Australia’s 1930s Emu War, where soldiers armed with machine guns failed to curb an overwhelming emu population devastating crops. The emus’ agility and sheer numbers outmatched the military’s efforts, leading to a humbling defeat. Lee cleverly translates this to software development, where throwing endless code at a problem—akin to deploying infinite soldiers—often results in a complex, bug-ridden system. This sets the stage for his argument: without proper problem definition, developers risk creating their own unmanageable “emu wars.”

He illustrates this with a hypothetical coding scenario where a client demands a solution to “kill all the pesky emus.” Developers might churn out classes and methods, only to face mounting complexity and bugs, such as emus “upgrading to T-Rexes.” The lesson? Simply writing more code doesn’t address the root issue, much like the Emu War’s flawed strategy failed to protect farmers’ crops.

Modeling Smells in E-Commerce

Transitioning to a more practical domain, Lee applies the Emu War analogy to an e-commerce platform tasked with implementing an “update order” feature. Initially, the solution seems straightforward: create an endpoint to modify orders. However, as Lee demonstrates, this leads to bugs like customers receiving too many items, being undercharged, or getting empty boxes. These issues arise because the vague “update order” requirement invites a cascade of edge cases and race conditions.

By examining the system’s event timeline, Lee highlights how an “order updated” event disrupts critical processes like payment capture and stock reservation. This modeling smell—where a generic action undermines system integrity—mirrors the Emu War’s misaligned objectives. The real problem, Lee argues, lies in failing to define the business’s true needs, resulting in a codebase that’s hard to test and extend.

Refining with Domain-Driven Design

Here, Lee introduces DDD as a remedy, emphasizing techniques like event storming and the five whys to uncover the true problem space. Revisiting the Emu War, he applies the five whys to reveal that the goal wasn’t to kill emus but to secure employment for returning soldiers. Similarly, in the e-commerce case, the “update order” request masks specific needs: ensuring shoppers receive only desired items, adding forgotten items, and canceling orders.

By reframing these needs, Lee proposes targeted solutions, such as a “supplementary order” endpoint for adding items and a time-bound “order received” event to allow cancellations without disrupting the system. These solutions, rooted in DDD’s ubiquitous language, reduce complexity by aligning the code with business intent, avoiding the pitfalls of generic actions like “update.”

Simplicity Through Abstraction

Lee challenges the notion that complex problems demand complex solutions. Through DDD, he shows how elevating the level of abstraction—by focusing on precise business goals—eliminates unnecessary complexity. In the e-commerce example, replacing the problematic “update order” endpoint with simpler, purpose-specific endpoints demonstrates how DDD fosters maintainable, extensible code.

He acknowledges the challenges of implementing such changes in live systems, where breaking changes can be daunting. However, Lee argues that aligning solutions with the problem space is worth the effort, as it prevents the codebase from becoming a “Frankenstein’s monster” burdened by accidental complexity.

Conclusion: Avoiding Your Own Emu War

Lee wraps up by urging developers to wield their coding “superpower” wisely. Instead of burying problems under an avalanche of code, he advocates for DDD practices to ensure solutions reflect the business’s true needs. By employing event storming, refining ubiquitous language, and questioning requirements with the five whys, developers can avoid fighting futile, unmaintainable battles.

This talk serves as a compelling reminder that thoughtful problem definition is the cornerstone of effective software development. Lee’s blend of humor and practical insights makes a strong case for embracing DDD to create robust, adaptable systems.

Dawn a horizon where authentication dissolves into biometric whispers and cryptographic confidences, banishing the tyranny of forgotten passphrases. Maud Nalpas, a fervent advocate for web security at Google, charted this trajectory at dotJS 2024, escorting audiences through passkeys’ ascent—a paradigm supplanting passwords with phishing-proof, breach-resistant elegance. With a lens honed on Chrome’s privacy vanguard, Maud dissected the relic’s frailties, from 81% breach culpability to mnemonic mayhem, before unveiling passkeys as the seamless salve.

Maud’s reverie evoked 1999’s innocence: Solitaire sessions interrupted by innocuous files, now echoed in 2024’s tax-season tedium—yet passwords persist, unyielding. Their design flaws—reusability, server-side secrets—fuel epidemics, mitigated marginally by managers yet unsolved at root. Enter passkeys: cryptographic duos, private halves cradled in device enclaves, publics enshrined server-side. Creation’s choreography: a GitHub prompt summons Google’s credential vault, fingerprint affirms, yielding a named token. Login? A tap unlocks biometrics, end-to-end encryption syncing across ecosystems—iCloud, 1Password—sans exposure.

This ballet boasts trifecta virtues. Usability gleams: no rote recall, mere device nudge. Economics entice: dual-role as MFA slashes SMS tolls. Security soars: no server secrets—biometrics localize, publics inert—phishing foiled by domain-binding; faux sites summon voids. Adoption surges—Amazon, PayPal vanguard—spanning web and native, browsers from Chrome to Safari, platforms Android to macOS. Caveats linger: Linux/Firefox lags, cross-ecosystem QR fallbacks bridge. Maud heralded 2024’s synchrony strides, Google’s Password Manager poised for ubiquity.

Implementation beckons via passkeys.directory: libraries like @simplewebauthn streamline, UX paramount—progressive prompts easing novices. Maud’s missive: trial as user, embed as architect; this future, phishing-free and frictionless, awaits invocation.

Passkeys’ Cryptographic Core

Maud illuminated the duo: private keys, hardware-harbored, sign challenges; publics verify, metadata minimal. Sync veils in E2EE—Google’s vault, Apple’s chain—device recovery via QR or recreation. Phishing’s nemesis: origin-tied, spoofed realms elicit absences, thwarting lures.

Adoption Accelerants and Horizons

Cross-platform chorus—Windows Edge, iOS Safari—minus Linux/Firefox snags, soon salved. Costs dwindle via MFA fusion; UX evolves prompts contextually. Maud’s clarion: libraries scaffold, inspiration abounds—forge passwordless realms resilient and radiant.

Links:

• Maud Nalpas on LinkedIn
• Google

Jim Rush and Tomais Williamson, security researchers from Wellington, New Zealand, electrified DEF CON 32 with a deep dive into exploiting NTLM authentication before its planned phase-out in Windows 11 and beyond. Representing CyberCX, they unveiled new vulnerabilities, bypassed existing fixes, and exposed insecure defaults in Microsoft’s NTLM-related controls. Their fast-paced presentation, infused with humor and technical depth, offered a final hurrah for NTLM hacking, urging attendees to turn off NTLM where possible.

Revisiting NTLM’s Persistent Flaws

Jim and Tomais began by contextualizing NTLM, a 25-year-old authentication protocol still prevalent despite its known weaknesses. They highlighted Microsoft’s plan to deprecate NTLM, yet emphasized its lingering presence in legacy systems. Their research uncovered new bugs, including a bypass of a previously patched CVE, allowing attackers to coerce NTLM hashes from various applications. By exposing these flaws, Jim and Tomais underscored the urgency of transitioning to more secure protocols like Kerberos.

Novel Exploitation Techniques

The duo detailed their innovative approaches, combining multiple bug classes to extract NTLM hashes from unexpected sources, such as document processors and build servers. Their live demonstrations showcased “cooked” bugs—exploits leveraging URL inputs to trigger hash leaks. Jim’s anecdotes about their discoveries, including a nod to their CyberCX colleague’s assistance, highlighted the collaborative nature of their work. These techniques revealed NTLM’s fragility, especially in environments with permissive defaults.

Insecure Defaults and Systemic Gaps

Focusing on Microsoft’s NTLM security controls, Jim and Tomais exposed glaring gaps, such as libraries allowing unauthenticated hash extraction. They demonstrated how attackers could exploit these defaults in applications like Microsoft Teams or PDF generators, turning innocuous features into attack vectors. Their findings, supported by CyberCX’s research efforts, emphasized the need for organizations to audit NTLM usage and disable it wherever feasible to prevent hash coercion.

Community Collaboration and Future Steps

Concluding, Jim and Tomais called for community engagement, inviting attendees to share ideas for extracting hashes from novel sources like video games. They praised Microsoft’s MSRC team for their responsiveness and urged continued disclosure to advance research. Their advice to “turn off NTLM, then turn it back on when someone screams” humorously captured the challenge of legacy system dependencies, encouraging proactive steps toward more secure authentication frameworks.

Links:

• CyberCX company website

At DevoxxUK2025, Daniel Garnier-Moiroux, a Spring Security team member at VMware, delivered an engaging talk on implementing passwordless authentication using passkeys and the WebAuthn specification. Highlighting the security risks of traditional passwords, Daniel demonstrated how passkeys leverage cryptographic keys stored on devices like YubiKeys, Macs, or smartphones to provide secure, user-friendly login flows. Using Spring Boot 3.4’s new WebAuthn support, he showcased practical steps to integrate passkeys into an existing application, emphasizing phishing resistance and simplified user experiences. His live coding demo and insights into Spring Security’s configuration made this a compelling session for developers seeking modern authentication solutions.

The Problem with Passwords

Daniel opened by underscoring the vulnerabilities of passwords, often reused or poorly secured, leading to frequent breaches. He introduced passwordless alternatives, starting with one-time tokens (OTTs), which Spring Security supports for temporary login links sent via email. While effective, OTTs require cumbersome steps like copying tokens across devices. Passkeys, based on the WebAuthn standard, offer a superior solution by using cryptographic keys tied to specific domains, eliminating password-related risks. Supported by major browsers and platforms like Apple, Google, and Microsoft, passkeys enable seamless authentication via biometrics, PINs, or physical devices, combining convenience with robust security.

Understanding WebAuthn and Passkeys

Passkeys utilize asymmetric cryptography, where a private key remains on the user’s device (e.g., a YubiKey or iPhone) and a public key is shared with the server. Daniel explained the two-phase process: registration, where a key pair is generated and the public key is stored on the server, and authentication, where the server sends a challenge, the device signs it with the private key, and the server verifies it. This ensures phishing resistance, as keys are domain-specific and cannot be used on fraudulent sites. WebAuthn, a W3C standard backed by the FIDO Alliance, simplifies this process for developers by abstracting complex cryptography through browser APIs like navigator.credentials.create() and navigator.credentials.get().

Integrating Passkeys with Spring Security

Using a live demo, Daniel showed how to integrate passkeys into a Spring Boot 3.4 application. He added the spring-security-webauthn dependency and configured a security setup with the application name, relying party (RP) ID (e.g., localhost), and allowed origins. This minimal configuration enables a default passkey login page. For persistence, Spring Security 6.5 (releasing soon after the talk) offers JDBC support, requiring two tables: one for user credentials (storing public keys and metadata) and another linking passkeys to users. Daniel emphasized that Spring Security handles cryptographic validation, sparing developers from implementing complex WebAuthn logic manually.

Customizing the Passkey Experience

To enhance user experience, Daniel demonstrated creating a custom login page with a branded “Sign in with Passkey” button, styled with CSS (featuring a comic sans font for humor). He highlighted the need for JavaScript to interact with WebAuthn APIs, copying Spring Security’s Apache-licensed sample code for authentication flows. This involves handling CSRF tokens and redirecting users post-authentication. While minimal Java code is needed, developers must write some JavaScript to trigger browser APIs. Daniel advised using Spring Security’s defaults for simplicity but encouraged customization for production apps, ensuring alignment with brand aesthetics.

Practical Considerations and Feedback

Daniel stressed that passkeys are not biometric data but cryptographic credentials, synced across devices via password managers or iCloud Keychain without server involvement. For organizations using identity providers like Keycloak or Azure Entra ID, passkey support is often a checkbox configuration, reducing implementation effort. He encouraged developers to provide feedback on Spring Security’s passkey support via GitHub issues, emphasizing community contributions to refine features. For those interested in deeper WebAuthn mechanics, he recommended Ubico’s developer guide over the dense W3C specification, offering practical insights for implementation.

Links:

• Spring Security website
• WebAuthn website
• FIDO Alliance website
• Ubico Passkeys Guide

J. Hoffman and Colby Morgan, offensive security engineers at Robinhood, delivered a compelling presentation at DEF CON 32, exploring vulnerabilities in the 1Password macOS desktop application. Focusing on the risks posed by compromised endpoints, they unveiled multiple attack vectors to dump local vaults, exposing weaknesses in 1Password’s software architecture and IPC mechanisms. Their research, blending technical rigor with practical demonstrations, offered critical insights into securing password managers against local threats.

Probing 1Password’s Security Assumptions

J. and Colby opened by highlighting the immense trust users place in password managers like 1Password, which safeguard sensitive credentials. They posed a critical question: how secure are these credentials if a device is compromised? Their research targeted the macOS application, uncovering vulnerabilities that could allow attackers to access vaults. By examining 1Password’s reliance on inter-process communication (IPC) and open-source components, they revealed how seemingly robust encryption fails under local attacks, setting the stage for their detailed findings.

Exploiting Application Vulnerabilities

The duo detailed several vulnerabilities, including an XPC validation bypass that enabled unauthorized access to 1Password’s processes. Their live demonstrations showcased how attackers could exploit these flaws to extract vault data, even on locked systems. They also identified novel bugs in Google Chrome’s interaction with 1Password’s browser extension, amplifying the attack surface. J. and Colby’s meticulous approach, including proof-of-concept scripts released at Morgan’s GitHub, underscored the need for robust validation in password manager software.

Mitigating Local Threats

Addressing mitigation, J. and Colby recommended upgrading to the latest 1Password versions, noting fixes in versions 8.10.18 and 8.10.36 for their disclosed issues. They urged organizations to enhance endpoint security, emphasizing that password managers are prime targets for red teamers seeking cloud credentials or API keys. Their findings, developed over a month of intensive research, highlighted the importance of proactive patching and monitoring to safeguard sensitive data on compromised devices.

Engaging the Security Community

Concluding, J. and Colby encouraged the DEF CON community to extend their research to other password managers, noting that similar vulnerabilities likely exist. They shared their code to inspire further exploration and emphasized responsible disclosure, having worked with 1Password to address the issues. Their call to action invited attendees to collaborate on improving password manager security, reinforcing the collective effort needed to protect critical credentials in an era of sophisticated local attacks.

Links:

• Colby Morgan’s GitHub
• Robinhood company website

Overcoming Barriers to Adoption

The promise of memory-safe programming has positioned Rust as a leading candidate for industrial applications, yet its adoption in traditional sectors faces significant hurdles. At OxidizeConf2024, a panel moderated by Florian Gilcher from Ferrous Systems, featuring Michał Fita, James Munns from OneVariable UG, and Steve Klabnik from Oxide Computer Company, explored strategies to enhance Rust’s uptake in industrial companies. The discussion, enriched by audience questions, addressed cultural, technical, and managerial barriers, offering actionable insights for developers and organizations.

Michał highlighted the managerial perspective, noting that industrial companies often prioritize stability and cost over innovation. The challenge lies in convincing decision-makers of Rust’s benefits, particularly when hiring skilled Rust developers is difficult. James added that industrial users, rooted in mechanical and electrical engineering, are less likely to share challenges publicly, complicating efforts to gauge their needs. Florian emphasized the role of initiatives like Ferrocene, a safety-compliant Rust compiler, in opening doors to regulated industries like automotive.

Technical and Cultural Shifts

Steve underscored Rust’s technical advantages, such as memory safety and concurrency guarantees, which align with regulatory pressures from organizations like the NSA advocating for memory-safe languages. However, he cautioned against framing Rust as a direct replacement for C++, which risks alienating skilled C++ developers. Instead, the panel advocated for a collaborative approach, highlighting Rust’s total cost of ownership benefits—fewer bugs, faster debugging, and improved maintainability. James noted that tools like cargo-deny and cargo-tree enhance security and dependency management, addressing industrial concerns about reliability.

Cultural resistance also plays a role, particularly in companies reliant on trade secrets. Michał pointed out that Rust’s open-source ethos can clash with proprietary mindsets, requiring tailored strategies to demonstrate value. The panel suggested focusing on high-impact areas, such as safety-critical components, where Rust’s guarantees provide immediate benefits. By integrating Rust incrementally, companies can leverage existing C++ codebases while transitioning to safer, more modern practices.

Engaging Stakeholders and Building Community

Convincing stakeholders requires a nuanced approach, avoiding dismissive rhetoric about legacy languages. Florian stressed the importance of meeting developers where they are, respecting the expertise of C++ practitioners while showcasing Rust’s practical advantages. Steve highlighted successful adoptions, such as Oxide’s server stack, as case studies to inspire confidence. The panel also discussed the role of community efforts, such as the Rust Foundation, in providing resources and certifications to ease adoption.

Audience input reinforced the need for positive messaging. A C++ developer cautioned against framing Rust as a mandate driven by external pressures, advocating for dialogue that emphasizes mutual benefits. The panel agreed, suggesting that events like OxidizeConf and open-source contributions can bridge gaps between communities, fostering collaboration. By addressing technical, cultural, and managerial challenges, Rust can gain traction in industrial settings, driving innovation without discarding legacy expertise.

Links:

• Ferrous Systems company website
• Oxide Computer Company website
• OneVariable UG company website

Continuous Integration and Continuous Delivery (CI/CD) pipelines are the backbone of modern software development, automating the process of building, testing, and deploying applications. However, as these pipelines grow in complexity, they often become difficult to maintain, debug, and port across different execution platforms, frequently relying on verbose and platform-specific YAML configurations. Jean-Christophe Sirot, in his presentation, introduced Dagger as a revolutionary approach to CI/CD, allowing pipelines to be written as code, executable locally, testable, and portable. He explored Dagger Functions and Dagger Modules as key concepts for creating and sharing reusable, language-agnostic components for CI/CD workflows, positioning Dagger as a versatile “Swiss Army knife” for modernizing these critical pipelines.

The Pain Points of Traditional CI/CD

Jean-Christophe began by outlining the common frustrations associated with traditional CI/CD pipelines. Relying heavily on YAML or other declarative formats for defining pipelines can lead to complex, repetitive, and hard-to-read configurations, especially for intricate workflows. Debugging failures within these pipelines is often challenging, requiring pushing changes to a remote CI server and waiting for the pipeline to run. Furthermore, pipelines written for one CI platform (like GitHub Actions or GitLab CI) are often not easily transferable to another, creating vendor lock-in and hindering flexibility. This dependency on specific platforms and the difficulty in managing complex workflows manually are significant pain points for development and DevOps teams.

Dagger: CI/CD as Code

Dagger offers a fundamentally different approach by treating CI/CD pipelines as code. It allows developers to write their pipeline logic using familiar programming languages (like Go, Python, Java, or TypeScript) instead of platform-specific configuration languages. This brings the benefits of software development practices – such as code reusability, modularity, testing, and versioning – to CI/CD. Jean-Christophe explained that Dagger executes these pipelines using containers, ensuring consistency and portability across different environments. The Dagger engine runs the pipeline logic, orchestrates the necessary container operations, and manages dependencies. This allows developers to run and debug their CI/CD pipelines locally using the same code that will execute on the remote CI platform, significantly accelerating the debugging cycle.

Dagger Functions and Modules

Key to Dagger’s power are Dagger Functions and Dagger Modules. Jean-Christophe described Dagger Functions as the basic building blocks of a pipeline – functions written in a programming language that perform specific CI/CD tasks (e.g., building a Docker image, running tests, deploying an application). These functions interact with the Dagger engine to perform container operations. Dagger Modules are collections of related Dagger Functions that can be packaged and shared. Modules allow teams to create reusable components for common CI/CD patterns or specific technologies, effectively creating a library of CI/CD capabilities. For example, a team could create a “Java Build Module” containing functions for compiling Java code, running Maven or Gradle tasks, and building JAR or WAR files. These modules can be easily imported and used in different projects, promoting standardization and reducing duplication across an organization’s CI/CD workflows. Jean-Christophe demonstrated how to create and use Dagger Modules, illustrating their potential for building composable and maintainable pipelines. He highlighted that Dagger’s language independence means that modules can be written in one language (e.g., Python) and used in a pipeline defined in another (e.g., Java), fostering collaboration between teams with different language preferences.

The Benefits: Composable, Maintainable, Portable

By adopting Dagger, teams can create CI/CD pipelines that are:
– Composable: Pipelines can be built by combining smaller, reusable Dagger Modules and Functions.
– Maintainable: Pipelines written as code are easier to read, understand, and refactor using standard development tools and practices.
– Portable: Pipelines can run on any platform that supports Dagger and containers, eliminating vendor lock-in.
– Testable: Individual Dagger Functions and modules can be unit tested, and the entire pipeline can be run and debugged locally.

Jean-Christophe’s presentation positioned Dagger as a versatile tool that modernizes CI/CD by bringing the best practices of software development to pipeline automation. The ability to write pipelines in code, leverage reusable modules, and execute locally makes Dagger a powerful “Swiss Army knife” for developers and DevOps engineers seeking more efficient, reliable, and maintainable CI/CD workflows.

Links:

• Jean-Christophe Sirot: https://www.linkedin.com/in/jcsirot/
• Decathlon: https://www.decathlon.com/
• Dagger: https://dagger.io/
• Devoxx France LinkedIn: https://www.linkedin.com/company/devoxx-france/
• Devoxx France Bluesky: https://bsky.app/profile/devoxx.fr
• Devoxx France Website: https://www.devoxx.fr/

Michael Orlitzky, a multifaceted security researcher and mathematician, captivated the DEF CON 32 audience with a provocative presentation on bypassing payment mechanisms in CSC ServiceWorks’ pay-to-play laundry machines. By exploiting physical vulnerabilities in Speed Queen washers and dryers, Michael demonstrated how to run these machines without payment, framing his actions as a response to CSC’s exploitative practices. His talk, rich with technical detail and humor, shed light on the intersection of physical security and consumer frustration, urging attendees to question predatory business models.

Uncovering CSC’s Predatory Practices

Michael began by introducing CSC ServiceWorks, a major provider of coin- and app-operated laundry machines in residential buildings. He detailed their business model, which charges tenants for laundry despite rent covering utilities, often trapping users with non-refundable prepaid cards or unreliable apps like CSC GO. Michael recounted personal grievances, such as machines eating quarters or failing to deliver services, supported by widespread customer complaints citing CSC’s poor maintenance and refund processes. His narrative positioned CSC as a corporate antagonist, justifying his exploration of hardware bypasses as a form of reclaiming fairness.

Bypassing Coin Slots with Hardware Hacks

Delving into the technical core, Michael explained how to access the service panels of CSC-branded Speed Queen machines, which use standardized keys available online. By short-circuiting red and black wires in the coin-drop mechanism, he tricked the machine into registering payment, enabling free cycles without damage. His live demonstration, complete with safety warnings about grounding and electrical risks, showcased the simplicity of the bypass—achievable in seconds with minimal tools. Michael’s approach, detailed on his personal website, emphasized accessibility, requiring only determination and basic equipment.

Addressing CSC’s Security Upgrades

Michael also addressed CSC’s response to his findings, noting that days before DEF CON 32, the company upgraded his building’s machines with new tubular locks and security Torx screws. Undeterred, he demonstrated how to bypass these using a tubular lockpick or a flathead screwdriver, highlighting CSC’s superficial fixes. His candid tone and humorous defiance—acknowledging the machines’ internet-connected logs—underscored the low risk of repercussions, as CSC’s focus on profit over maintenance left such vulnerabilities unaddressed. This segment reinforced the talk’s theme of exploiting systemic flaws in poorly secured systems.

Ethical Implications and Community Call

Concluding, Michael framed his work as a protest against CSC’s exploitative practices, encouraging attendees to consider the ethics of bypassing systems that exploit consumers. He shared resources, including manuals and his write-up, to empower others while cautioning about legal risks. His talk sparked reflection on the balance between technical ingenuity and corporate accountability, urging the DEF CON community to challenge predatory systems through informed action.

Links:

• Michael Orlitzky’s website
• CSC ServiceWorks website
• Alliance Laundry Systems website

Maxim Zaks, polymath programmer from IDEs to data ducts, and FlatBuffers’ fleet-footed forger, interrogated Mojo’s mettle at DotAI 2024. As Mojo’s communal curator—contributing to its canon sans corporate crest—Zaks, unyoked to Modular, affirmed its ascent: not ephemeral éclat, but enduring edifice for AI artisans and systems smiths alike.

Echoes of Eras: From Procedural Progenitors to Pythonic Prodigies

Zaks zested with zeitgeist: Married… with Children’s clan conjuring C’s centrality, Smalltalk’s sparkle, BASIC’s benevolence—80s archetypes amid enterprise esoterica. Fast-forward: Java’s juggernaut, Python’s pliant poise—yet performance’s plaint persists, Python’s pyrotechnics paling in precision’s precinct.

Mojo manifests as meld: Python’s patois, systems’ sinew—superset sans schism, scripting’s suavity fused with C’s celerity. Zaks zinged its zygote: 2023’s stealthy spawn, Howard’s herald as “decades’ dawn”—now TIOBE’s 48th, browser-bound for barrierless baptism.

Empowering Engineers: From Syntax to SIMD

Zaks zoomed to zealots: high-performance heralds harnessing SIMD sorcery, data designs deftly dispatched—SIMD intrinsics summoning speedups sans syntax strain. Mojo’s mantle: multithreading’s mastery, inline ML’s alchemy—CPUs as canvases, GPUs on horizon.

For non-natives, Zaks zapped a prefix-sum parable: prosaic Python plodding, Mojo’s baseline brisk, SIMD’s spike surging eightfold—arcane accessible, sans secondary syntaxes like Zig’s ziggurats or Rust’s runes.

Community’s crucible: inclusive incubus, tools transcendent—VS Code’s vassal, REPL’s rapture. Zaks’ zest: Mojo’s mirthful meld, where whimsy weds wattage, inviting idiomatic idioms.

In finale, Zaks flung a flourish: browser beckons at mojo.modular.com—forge futures, unfettered.

Links:

• Modular Website
• Maxim Zaks on LinkedIn

I recently started migrating my WordPress site from Free.fr to OVHcloud hosting. The migration is still in progress, but along the way I needed to enable and validate
programmatic publishing through the WordPress REST API (RPC/API calls). This post documents the full process end-to-end, including OVH-specific gotchas and troubleshooting.

My last migration was many years ago, from DotClear 2 to WordPress…

Why move from Free.fr to OVH?

• Performance: More CPU/RAM and faster PHP execution make WordPress snappier.
• Modern PHP: Current PHP versions and extensions are available and easy to select.
• HTTPS (SSL): Essential for secure logins and required for Application Passwords.
• Better control: You can tweak .htaccess, install custom/mu-plugins, and adjust config.
• Scalability: Easier to upgrade plans and resources as your site grows.

What is the WordPress REST API?

WordPress ships with a built-in REST API at /wp-json/. It lets you read and write content, upload media, and automate publishing from scripts or external systems (curl, Python, Node.js, CI, etc.).

Step 1 — Confirm the API is reachable

1. Open https://yourdomain.com/wp-json/ in a browser. You should see a JSON index of routes.
2. Optional: check https://yourdomain.com/wp-json/wp/v2 or
   https://yourdomain.com/wp-json/wp/v2/types/post to view available endpoints and fields.

Step 2 — Enable authentication with Application Passwords

1. Sign in to /wp-admin/ with a user that can create/publish posts.
2. Go to Users → Profile (your profile page).
3. In Application Passwords, add a new password (e.g., “API access from laptop”). It should look like ABCD EFgh IjKl M123 n951 (including spaces)
4. Copy the generated password (you’ll only see it once). Keep it secure.

You will authenticate via HTTP Basic Auth using username:application-password over HTTPS.

Step 3 — Test authentication (curl)

Replace the placeholders before running:

curl -i -u 'USERNAME:APP_PASSWORD' \
  https://yourdomain.com/wp-json/wp/v2/users/me

Expected result: 200 OK with your user JSON. If you get 401 or 403, see Troubleshooting below.

Important on OVH — The Authorization header may be stripped

On some OVH hosting configurations, the HTTP Authorization header isn’t passed to PHP.
If that happens, WordPress cannot see your Application Password and responds with:

{"code":"rest_not_logged_in","message":"You are not currently logged in.","data":{"status":401}}

To confirm you’re sending the header, try explicitly setting it:

curl -i -H "Authorization: Basic $(echo -n 'USERNAME:APP_PASSWORD' | base64)" \
  https://yourdomain.com/wp-json/wp/v2/users/me

If you still get 401, fix the server so PHP receives the header.

Step 4 — Fixing Authorization headers on OVH

Option A — Add rules to .htaccess

Connect in FTP, browse to “www” folder, edit the .htaccess file. Add these lines above the “BEGIN WordPress” block:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
</IfModule>

<IfModule mod_setenvif.c>
    SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
</IfModule>

Option B — Tiny must-use plugin

Create wp-content/mu-plugins/ if missing, then add fix-authorization.php:

<?php
/**
 * Plugin Name: Fix Authorization Header
 * Description: Ensures HTTP Authorization header is passed to WordPress for Application Passwords.
 */
add_action('init', function () {
    if (!isset($_SERVER['HTTP_AUTHORIZATION'])) {
        if (isset($_SERVER['REDIRECT_HTTP_AUTHORIZATION'])) {
            $_SERVER['HTTP_AUTHORIZATION'] = $_SERVER['REDIRECT_HTTP_AUTHORIZATION'];
        } elseif (function_exists('apache_request_headers')) {
            $headers = apache_request_headers();
            if (isset($headers['Authorization'])) {
                $_SERVER['HTTP_AUTHORIZATION'] = $headers['Authorization'];
            }
        }
    }
});

Upload and reload: authentication should now succeed.

Step 5 — Create and publish a complete post via API

Optional: create a category and a tag

# Create a category
curl -i -X POST \
  -u 'USERNAME:APP_PASSWORD' \
  -H "Content-Type: application/json" \
  -d '{ "name": "Tech" }' \
  https://yourdomain.com/wp-json/wp/v2/categories

# Create a tag
curl -i -X POST \
  -u 'USERNAME:APP_PASSWORD' \
  -H "Content-Type: application/json" \
  -d '{ "name": "API" }' \
  https://yourdomain.com/wp-json/wp/v2/tags

Upload a featured image

curl -i -X POST \
  -u 'USERNAME:APP_PASSWORD' \
  -H "Content-Disposition: attachment; filename=header.jpg" \
  -H "Content-Type: image/jpeg" \
  --data-binary @/full/path/to/header.jpg \
  https://yourdomain.com/wp-json/wp/v2/media

Note the returned MEDIA_ID.

Create and publish the post

curl -i -X POST \
  -u 'USERNAME:APP_PASSWORD' \
  -H "Content-Type: application/json" \
  -d '{
        "title": "Hello from the API",
        "content": "<p>Created automatically 🚀</p>",
        "status": "publish",
        "categories": [CAT_ID],
        "tags": [TAG_ID],
        "featured_media": MEDIA_ID
      }' \
  https://yourdomain.com/wp-json/wp/v2/posts

Optionally update excerpt or slug

POST_ID=REPLACE_WITH_ID

curl -i -X POST \
  -u 'USERNAME:APP_PASSWORD' \
  -H "Content-Type: application/json" \
  -d '{ "excerpt": "Short summary", "slug": "hello-from-the-api" }' \
  https://yourdomain.com/wp-json/wp/v2/posts/$POST_ID

Troubleshooting

• 401 Unauthorized / rest_not_logged_inThe Authorization header isn’t reaching PHP. Add the .htaccess rules or the mu-plugin above. Re-test with
  -H "Authorization: Basic …".
• 403 ForbiddenThe user lacks capabilities (e.g., Authors can’t publish globally). Use "status":"draft" or run publishing as an Editor/Admin.
• Media upload failsCheck upload_max_filesize, post_max_size, and file permissions. Try a smaller file to isolate the issue.
• Categories/Tags not appliedUse numeric IDs, not names. Fetch with /wp-json/wp/v2/categories and /wp-json/wp/v2/tags.
• PermalinksPrefer non-Plain permalinks. If using Plain, you can call endpoints with the fallback:
  https://yourdomain.com/?rest_route=/wp/v2/posts.

Conclusion

Moving from Free.fr to OVH brings better performance, modern PHP, and full HTTPS, which is perfect for automation and scheduling.
After ensuring the Authorization header reaches WordPress (via .htaccess or a tiny mu-plugin), the REST API works smoothly for creating posts, uploading media, and managing taxonomy.
My migration is still ongoing, but having a reliable API in place is already a big win.