DEV Community

Cover image for Building Laneora: Shared Freight Load-Board Access on a Windows Desktop
Muhammad Afzal Kalwar
Muhammad Afzal Kalwar

Posted on

Building Laneora: Shared Freight Load-Board Access on a Windows Desktop

#python #windows #pyqt #logistics

Building Laneora: Shared Freight Load-Board Access on a Windows Desktop

Laneora is a Windows desktop application that coordinates shared freight load-board access across dispatcher PCs. Dispatchers authenticate with a Laneora Soft username. An admin Soft server checks that account and plan, returns a shared board session payload, and the desktop client opens the load search inside an embedded Qt WebEngine view—so the board password is not typed on every workstation.

This is an architecture write-up based on the public Laneora v3.0.0 repository and README. It does not claim production scale, partnerships, or verified compliance with any third-party board.

Why split Soft login from the board session

Dispatch desks often need more than one person looking at the same load search. Typing one board password on every PC is awkward to manage. Laneora documents a two-layer model:

  1. Laneora Soft credentials — usernames and passwords the admin creates for dispatchers.
  2. Shared board session — held on the Soft server and delivered to clients as an encrypted payload for the embedded browser.

The client UI is intentionally small: brand mark, fields for Soft username and password, Login, then a single control that opens the load search after a successful Soft login.

Laneora client sign-in

Original screenshot from the repo: docs/images/client-login.png.

System shape: server, admin UI, desktop client

Three cooperating pieces appear in the README:

Piece Role
Soft server Listens on port 8787; authenticates Soft users, enforces plans, serves session material and heartbeat checks
Admin dashboard Browser UI at /admin on that server for account and plan management
Laneora desktop window PyQt5 app on each dispatcher PC; embeds Qt WebEngine for the load search 
Admin host                         Dispatcher PC
-----------                        --------------
Soft server  <---- Soft login ---  Laneora window
   |                                  |
   | users, plans, session            | embedded WebEngine
   v                                  v
Admin dashboard                    Load search UI
Enter fullscreen mode Exit fullscreen mode

If the Soft server stops, new Soft logins fail while an already-open search can keep retrying the periodic check. Closing one desktop window does not take down other clients or the server.

Admin account and plan management

Admins sign in at /admin, then work from a user desk rather than a separate product screen.

Laneora admin sign-in

Original screenshot: docs/images/admin-login.png.

Documented plan lengths (durations only—no retail prices in the README):

Plan Length
Trial 1 hour
Day 1 day
Week 7 days
15 days 15 days
Month 30 days
3 months 90 days
6 months 180 days
Year 365 days

Apply from now starts that length immediately. Add onto current extends remaining time (or starts from now if the plan already ended). Accounts without a plan can still Soft-sign-in until a plan is applied; after the end time, the next Soft login is refused. The desk also supports password changes, disable, and delete. The README states there is no seat cap in this model, and that the dashboard password is separate from any Soft client user.

Laneora admin users desk

Original screenshot: docs/images/admin-users.png.

Client / server API surface

The Techniques section of the README describes a Soft-compatible HTTP API used by the desktop client:

  • GET /authenticate — validates Soft username and password, checks plan / disabled state, and returns the encrypted session payload when login succeeds.
  • GET /logger — about-once-a-minute heartbeat used for single-screen enforcement (newest Soft login for a username keeps the seat; an older Laneora window is told to exit).

Session material is described as an OpenSSL-compatible Salted__ AES blob. After decrypt, cookie expiry from the capture is written into the WebEngine cookie store and the search URL loads. A document script then keeps the embedded view on the search route and hides selected chrome (side menu, insurance banner, mailbox connect control) as listed in the README.

That is an application-level design description from the docs—not a claim that the crypto or session handling has been independently audited.

Desktop UI and packaging

  • UI toolkit: PyQt5 for the shell; Qt WebEngine for the embedded Chromium load-search view.
  • Dependencies (requirements.txt): PyQt5, PyQtWebEngine, requests, pycryptodome, psutil, pytz, Pillow.
  • Runtime target: Windows 10/11, Python 3.12+.
  • Brand assets: Laneora mark used as the Windows app id / taskbar icon before the first window.
  • Build: build.ps1 produces a PyInstaller onefile dist\Laneora.exe, typically started with a small bat that sets LANEORA_SERVER_URL.

Optional Soft proxy configuration exists via scripts/soft_admin.py in the repo; details belong in ops docs rather than this architecture overview.

Authorization and terms

Laneora is tooling around shared board access. Anyone running it needs authorization to use the underlying load board and must follow that board’s access terms. This article does not verify compliance for any deployment, does not claim partnership with any board vendor, and does not offer security guarantees.

Secrets such as Soft passwords and captured board cookies are documented as living under data/ on the server host and are gitignored—do not commit them.

Links and sources

Muhammad Afzal Kalwar — Python automation engineer and founder of INDUS Web Agency.

Top comments (0)