So what's the proper way?

Of course, you're simply truncating the object to a size of 0.

Intuitive design.
#Python #Coding

Fixed cancelling a thread job in #poser's #threadpool. Using a semaphore to do this seems reliable

Oh my. #Multithreading, #synchronization, async #Unix #signals, this is pure "fun" ...

https://github.com/Zirias/poser/commit/aa4e02b728a549f0e3c4687750b90749d48fcfdc

DId lots of smaller improvements to #swad ... but first, I had to hunt down a crash . Finally found it was caused by my #poser lib (to be fixed later): A connection there can resolve the hostname of a remote end and does so in a thread job to avoid blocking. If the connection dies meanwhile, the job is canceled. Seems my canceling mechanism relying on a signal to the thread is, well, not reliable (the signal can arrive delayed). Ok, for now just disabled name resolution to sidestep that.

Now, integration with #nginx is much better. I intrdoduced (optional) custom headers to transport the authentication realm and the redirect URI, plus state management in the session, so these can be passed to the "auth" endpoint. This requires to make sure nginx always passes the session #cookie, Unfortunately, I still need a "hacky" redirect configuration for login in nginx. If auth_request could just pass the response body, this would be unnecessary ....

The nginx configuration shows #swad running on "files" and another nginx running on "wwwint" serving #poudriere output there. This nginx instance helpfully adds cache hints, which I have to override, so a redirect works as expected when for example the swad session times out.

First "production test" successful ... after band-aid "deployment" (IOW, scp binaries to the prod jail).

#swad integrates with #nginx exactly as I planned it. And #PAM authentication using a child process running as root also just works (while the main process dropped privileges).

So, I guess I can say goodbye to #AI #bots hammering my poor DSL connection just to download poudriere build logs.

Still a lot to do for #swad: Make it nicer. So many ideas. Best start would probably be to implement more credentials checking modules besides PAM.

Once you have your happy path working, it's time to deal with all the "unhappy stuff" (aka proper error handling) to reach production quality ...

https://github.com/Zirias/swad/commit/a0417bbc1db4cb5ca9f99534d04d1723492107f9

This, btw, was yet another reminder of the horrible can of worms #stdio's #buffering is.

I created a little tool running as a child process to do the *actual* #PAM authentication, so it will be possible to have this run as root while the real service drops all privileges. This little tool uses a simple line-based protocol for communication on stdin/stdout. It worked well when testing directly on the terminal.

On the first real test though, my service just went hanging. I suspected a deadlock caused by pthread mutexes. Wasted quite some time looking into that. Then I finally realized communication over the pipes was stalled.

Ok, just set buffering mode to "line buffering" after fdopen'ing the #pipe. Turned out that didn't help either. I *assume* that even in the child process, the stdio streams automatically created on the pipes were somehow fully buffered. But at that point, I was really fed up with trial and error and rewrote the whole mess to do I/O using plain #POSIX APIs (read, write), sidestepping any buffering. Worked like a charm.

Result of today's #C #coding session: I can now authenticate with #PAM

https://github.com/Zirias/swad/commit/8983ae30955a407c4732c6e3e3a4aeba6db77a93

This will soon be "production-ready" at least for me

I just decided my new tool needs protection against #CSRF. It's surprisingly little code, once the generic tooling is in place

https://github.com/Zirias/swad/commit/ecfeb68f87245d621c53d7ca440f9c36d909a18a