Read modules: hosting (databases, FTP, samba, cronjobs, software, directory protection, ddns)

[chmmou]

Remaining read endpoints, grouped because each is small and shares the same shape.

Endpoints: get_databases, get_database, get_ftpusers, get_ftpuser, get_sambausers, get_cronjobs (+ filter variant), get_cronjob, get_softwareinstalls, get_softwareinstall, get_directoryprotections, get_directoryprotection, get_ddnsusers.

Session writes (add_session / delete_session) carved out into #60 so this issue stays pure reads.

• One package per resource under internal/.
• Mapping tests against fixtures in testdata/{database,ftpuser,sambauser,cronjob,softwareinstall,directoryprotection,ddns}/ (each folder has the matching _request.xml, _response_success.xml, and _response_failed_*.xml fixtures).
• CLI subcommands under kasapi-cli <resource> list|get.

Status (2026-05-08)

• All listed read fixtures are present, including singular detail variants (get_database, get_ftpuser, get_cronjob, get_softwareinstall, get_directoryprotection).
• Implemented and merged: databases (PR feat: databases get/list via get_databases (with database_login filter) #55), ftpusers (PR feat: ftpusers get/list via get_ftpusers (with ftp_login filter) #57), sambausers (PR feat: sambausers get/list via get_sambausers (with samba_login filter) #58), cronjobs (PR feat: cronjobs get/list via get_cronjobs (with cronjob_id filter) #59).
• Outstanding: directoryprotection, softwareinstall, ddnsusers.

[chmmou]

Clarification: add_session / delete_session vs. KasAuth

The two sit on different endpoints and serve different purposes — worth pinning down before starting:

• KasAuth.php (already implemented in KasAuth client (plain / session / 2FA) #5 as internal/auth): returns the 40-char credential token used by kas_auth_type=session requests. Triggered transparently by auth.SessionTokenSource on first KasApi call and on no_auth / unknown_session faults. No CLI surface needed; it is internal plumbing.
• KasApi.php add_session / delete_session: documented as separate operations on the KasApi endpoint. Per the KAS docs these manage administrative customer-side sessions (e.g. delegated logins) rather than the credential token KasAuth issues. To verify against the docs at https://kasapi.kasserver.com/dokumentation/phpdoc/ before scoping the CLI surface.

Decision needed

1. Are add_session / delete_session in scope for the read-phase kasapi-cli sessions subcommand, or do they belong to Write operations #13 (writes)?
2. If yes here: what is the user-facing command shape (kasapi-cli sessions add|delete)? They take parameters (session id, ttl, …), so the "treat them as reads because we need them for auth" rationale does not apply — KasAuth already covers our auth path.

Recommendation: move both to #13 and drop the "needed early for session-mode auth" line from this issue's description. The auth path is already covered by KasAuth and this issue then becomes pure reads.

[chmmou]

Status update (2026-05-03): add_session is effectively implemented via internal/auth.Client.GetCredentialToken (KasAuth flow, see PRs #29, #33). The remaining session-write to land in this batch is delete_session — also a prerequisite for the multi-profile switch in #39.