open https://gitlab.synchro.net/main/sbbs/-/work_items/1310

Embedded multi-user JavaScript services need to check native ARS for the user and connection making a particular request. For example, an IRC FileServ can use new User(number) for ordinary BBS permissions, but cannot supply the current IRC/DCC connection context for HOST, IP, or PROT requirements.

Current implementation:
* src/sbbs3/js_user.cpp: js_chk_ar() uses the User private client pointer; constructed User objects do not have a caller-supplied client context.
* js_can_access_dir() passes nullptr for the client to the native directory access/download/upload/operator checks.
* src/sbbs3/chk_ar.cpp: HOST, IP and PROT therefore fall back to the account's stored last-login host, IP address and connection protocol.

Please consider an optional, backward-compatible per-invocation client context, copied and lifetime-safe, for User.compare_ars() and User.can_access_dir(). For example compare_ars(requirements[, client_context]) and can_access_dir(directory[, access[, client_context]]), with the final API design left to the maintainer. The context would supply protocol, address and hostname to the existing native ARS evaluator without changing the account database or process-global state.

Suggested validation:
* Account stored last-login context A, current request context B: explicit context evaluates B; omitted context retains current behavior.
* Interleaved checks for multiple users cannot affect one another.
* Both directory visibility and download permission checks use the supplied context.
* Checking does not modify the account's stored host/IP/connection fields.

This is an API enhancement, not a claim that ordinary account ARS is broken. The planned embedded IRC FileServ will initially use existing APIs and document that connection-specific ARS uses the account's stored context; it does not depend on this enhancement. No native implementation change is included in that FileServ work.
--- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)