On 18.06.25 10:43, Gustaf Neumann (sslmail) wrote:
* .... The pre-processor macro LDAPV3 has to be defined manually
when building in order to work with current LDAP server versions.
As i see it, the macro is not necessary (i’ve replaced it with a
proper version compare, with macros provided by the standard includes.
Also without the macro being defined, nsdap compiles fine and works
(but without setting the LDAP to LDAPV3). Is this maybe Alpine specific?
Sorry for not being specific, what I meant to say is: Since the LDAP
version is hardcoded and by default is lower then LDAPV3 the module will
not work with an LDAP server expecting LDAPV3. To remedy one has to
recompile.
What is needed is a configuration option for the LDAP version to use, so
that one can adapt to the capabilities of the given server.
* Ns_ModuleInit() returns extraneously when scheduling a background
procedure: I worked around by setting maxidle to 0 in the pool
configuration.
what means "returns extraneously”? crash? Tcl exception? I would
expect, Ns_ModuleInit() to be executed during startup (when all
modules are loaded), not in a background procedure.
At the end of Ns_ModuleInit() background procedures are scheduled in a
loop with return Ns_ScheduleProcEx(...). Therefore Ns_ModuleInit() exits
at this point with the integer id of the first scheduled proc. I can see
though, that you already fixed this in the source code.
* Thorough documentation of all configuration options is missing.
ditto
I already started to complement the documentation (plus clarifying and
reformatting) in a fork of the repo. I'll be happy to include
documentation of your improvements and create a pull request.
*
* Current LDAP client library implementations encourage the use of
LDAP URI's instead of host, port and schema. This would be a
useful enhancement.
i have added this to the repository. Please test if possible, i have
no usable LDAP server installation.
I'll do! thanks for the improvements.
Controlled Creation of the auth Chain
Initially I had the idea of separating authentication and
authorization and have the admin of the server decide how and in
which order to run respective "filters". The current implementation
does not give exact control over the order of registration of auth
callbacks. I'll have to learn more on the details of Naviserver
configuration.
what do you mean by “no control”? This is exactly like for filters,
you can append at the end or at the begin,ut
It was a problem in my approach to structure the configuration sections
for the module. I already figured out a better way to do it.
Global Initialzation of a Tcl Module
The nsauthn module implements caching of credentials from passwd
files. For this I wanted to use a global initialization procedure,
run before any server is initialized. Alas I did not find if this is
even possible. Any info on this is appreciated.
In general, the global (shared) Tcl libraries are loaded before the
per-server (private) libraries.
You get the path of the global libraries via [ns_library shared] and
the per-server ones via ns_library private]
https://naviserver.sourceforge.io/5.0/manual/files/tcl-libraries.html
As I understand it, with the provided nsd-config.tcl the global
libraries are served from /usr/local/ns/tcl, as well as the private
libraries for the server default.
I created a module as a subdirectory of /usr/local/ns/tcl and put an
initialization proc into my module into the file init.tcl and also
execute it within this file. When I load the module globally, the
initialization proc is not run and the module is not loaded. When I load
the module in the default server it is loaded/executed as expected.
Code within /usr/local/ns/tcl/init.tcl is executed, but I do not want to
touch this file, since it is part of the installation of Naviserver.
...
Best Regards,
Georg
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
