security: add rate limits

[msimerson]

Different routes can have varying legitimate needs, make them configurable.

Examples:

• API routes for authentication limited to X attempt(s) per second.
  • deter bruteforce attacks
• Requests with valid auth tokens might be limited to 10/sec, etc.
  • prevent poorly written clients from creating DoS attacks

[aberoham]

I was thinking this would be a good excuse for me to look closely at what run-of-the-mill api gateways offer as far as rate-limiting and then attempt to contribute a simply configurable version of that. I'd presume no shared session/state amongst distinct api instances, just in-memory or otherwise node-local. Any design leaning hints?

[msimerson]

In my thinking, this is a 3.1 or 3.2 feature.

Much more useful now is poking at the installer / configurator and imaging all the different ways someone might want to configure NicTool. Of the top of my head:

• All-In-One: a single host running NicTool locally with the in-memory DNS server (no exports)
• Split server & API: a host running the NicTool UI (server) connected to a remove host running NicTool API
  • with the API pointed at a remotely hosted DB
• instructions for installing and configuring NicTool 3.0
  • right now, most all the docs are more developer oriented. Most of it needs to move to DEVELOP.md and README.md needs to become user docs.

[aberoham]

Happy Saturday -- my clankers have a chunky set of PRs incoming!

[aberoham]

Progress report on the chunky PRs. All are open, none merged, review welcome:

• api#60 authz enforcement layer, ported from the v2 permission model
• api#61 gui-rest-transport: store-layer refactor for audit/authz/delegation (file backends included, mongo/es stubs throw loudly), plus user search, object moves, audit logging, and zone-name conflict handling
• NicTool#363 v2 verifies v3's self-describing password hashes, so one login through either stack doesn't lock out the other
• NicTool#365 REST transport bridge: the v2 GUI and the xt suites run against the v3 API
• validate#29 schemas backing all of the above

Why this before installer/docs (your 8/9 note): the xt suites were the fastest way to hunt down gaps in v3, and they've been productive — running them through the bridge flushed out a delegated-read scoping bug, serial-rule drift, and pagination mismatches, all now fixed with regression tests. It felt like the machine-assisted version of what you described on the call: building against real data and verifying the permissions actually work the same way. ~2500 tests green across the five repos at the branch heads.

Two things I'd value your read on:

1. Zone-name uniqueness. 6a0d2c7 closes create races inside v3 with a named lock, but there's no unique index on a canonical form, so v2 writers can still create case/trailing-dot duplicates. My guess is you don't want a schema change in 3.0 (going from memory on that). Lock-only + documented, or index?
2. Bridge scope in 2.x. #365 touches the perl side more than I expected when we started. You've called v2 maintenance-only, so the question: is routing the GUI through the v3 API a useful stepping stone for upgrades (the bolt-on path), or a pile 'o changes you'd rather see stay lean?

Merge order if all looks good: #363 → #344 → #365, then validate releases 0.9.3 (not 0.10.0 — the api pins ^0.9.1 and caret won't reach it).

[msimerson]

review welcome

As soon as you think the PRs are ready (no longer Drafts), begin with copilot reviews, that's exactly what I'd do first.

[aberoham]

Ok, whole set is now reviewable end to end: validate#29 → api#61 → NicTool#365

IMHO, Ox Alpha sucked compared to Sol and Fable

[aberoham]

Can I do the rate limits now?