You can subscribe to this list here.
2005 |
Jan
|
Feb
(53) |
Mar
(62) |
Apr
(88) |
May
(55) |
Jun
(204) |
Jul
(52) |
Aug
|
Sep
(1) |
Oct
(94) |
Nov
(15) |
Dec
(68) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(130) |
Feb
(105) |
Mar
(34) |
Apr
(61) |
May
(41) |
Jun
(92) |
Jul
(176) |
Aug
(102) |
Sep
(247) |
Oct
(69) |
Nov
(32) |
Dec
(140) |
2007 |
Jan
(58) |
Feb
(51) |
Mar
(11) |
Apr
(20) |
May
(34) |
Jun
(37) |
Jul
(18) |
Aug
(60) |
Sep
(41) |
Oct
(105) |
Nov
(19) |
Dec
(14) |
2008 |
Jan
(3) |
Feb
|
Mar
(7) |
Apr
(5) |
May
(123) |
Jun
(5) |
Jul
(1) |
Aug
(29) |
Sep
(15) |
Oct
(21) |
Nov
(51) |
Dec
(3) |
2009 |
Jan
|
Feb
(36) |
Mar
(29) |
Apr
|
May
|
Jun
(7) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(13) |
Dec
|
2010 |
Jan
|
Feb
|
Mar
(9) |
Apr
(11) |
May
(16) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(92) |
Nov
(28) |
Dec
(16) |
2013 |
Jan
(9) |
Feb
(2) |
Mar
|
Apr
(4) |
May
(4) |
Jun
(6) |
Jul
(14) |
Aug
(12) |
Sep
(4) |
Oct
(13) |
Nov
(1) |
Dec
(6) |
2014 |
Jan
(23) |
Feb
(19) |
Mar
(10) |
Apr
(14) |
May
(11) |
Jun
(6) |
Jul
(11) |
Aug
(15) |
Sep
(41) |
Oct
(95) |
Nov
(23) |
Dec
(11) |
2015 |
Jan
(3) |
Feb
(9) |
Mar
(19) |
Apr
(3) |
May
(1) |
Jun
(3) |
Jul
(11) |
Aug
(1) |
Sep
(15) |
Oct
(5) |
Nov
(2) |
Dec
|
2016 |
Jan
(7) |
Feb
(11) |
Mar
(8) |
Apr
(1) |
May
(3) |
Jun
(17) |
Jul
(12) |
Aug
(3) |
Sep
(5) |
Oct
(19) |
Nov
(12) |
Dec
(6) |
2017 |
Jan
(30) |
Feb
(23) |
Mar
(12) |
Apr
(32) |
May
(27) |
Jun
(7) |
Jul
(13) |
Aug
(16) |
Sep
(6) |
Oct
(11) |
Nov
|
Dec
(12) |
2018 |
Jan
(1) |
Feb
(5) |
Mar
(6) |
Apr
(7) |
May
(23) |
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
(6) |
Oct
(6) |
Nov
(10) |
Dec
(3) |
2019 |
Jan
(26) |
Feb
(15) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(14) |
Jul
(10) |
Aug
(10) |
Sep
(4) |
Oct
(2) |
Nov
(20) |
Dec
(10) |
2020 |
Jan
(10) |
Feb
(14) |
Mar
(29) |
Apr
(11) |
May
(25) |
Jun
(21) |
Jul
(23) |
Aug
(12) |
Sep
(19) |
Oct
(6) |
Nov
(8) |
Dec
(12) |
2021 |
Jan
(29) |
Feb
(9) |
Mar
(8) |
Apr
(8) |
May
(2) |
Jun
(2) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(4) |
Nov
(12) |
Dec
(13) |
2022 |
Jan
(4) |
Feb
|
Mar
(4) |
Apr
(12) |
May
(15) |
Jun
(7) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(8) |
Dec
|
2023 |
Jan
(15) |
Feb
|
Mar
(23) |
Apr
(1) |
May
(2) |
Jun
(10) |
Jul
|
Aug
(22) |
Sep
(19) |
Oct
(2) |
Nov
(20) |
Dec
|
2024 |
Jan
(1) |
Feb
|
Mar
(16) |
Apr
(15) |
May
(6) |
Jun
(4) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(10) |
Nov
|
Dec
|
From: Zoran V. <zv...@ar...> - 2024-10-08 15:54:51
|
On 08.10.24 17:49, Andrew Piskorski wrote: > Have you heard of anybody > who still really WANTS to stay on Tcl 8.5 for some reason? I do :-) But I am not in any way married to the server's public version so I guess I do not count. At some (later) point we will move one tick up the ladder and use Tcl 8.6 and will stay there for some years to come. Cheers Zoran |
From: Andrew P. <at...@pi...> - 2024-10-08 15:49:25
|
On Tue, Oct 08, 2024 at 04:58:11PM +0200, Gustaf Neumann (sslmail) wrote: > What speaks against using the Tcl scripted approach is that so far, we support NaviServer with tcl8.5. ???file tempfile??? was introduced in Tcl 8.6. Ah, I hadn't realized 'file tempfile' was that new. Maybe just wait until NaviServer requires Tcl 8.6 or later? Have you heard of anybody who still really WANTS to stay on Tcl 8.5 for some reason? > Furthermore, TclUnixOpenTemporaryFile() is just for Unix, and not part of the public API (starting with ???Tcl_???). Well you'd never directly call TclUnixOpenTemporaryFile() of course. That's just how TclFileTemporaryCmd() and TclpOpenTemporaryFile() are implemented underneath. The Windows implemenation uses GetTempPathW() instead of mkstemp(), but presumably works the same at the Tcl level, and in C when calling TclpOpenTemporaryFile(). > But providing this support is not a big thing, since we have in NaviServer since a while support for mkstemp() also for windows (named ns_mkstemp)), since we use this call internally on several places. I???ll cook something up which is most version and platform independent, backward compatible, providing depreciation messages, which can be turned off for ???hopeless cases??? when admins get annoyed about to many depreciation messages. That sounds great! Thanks for taking care of this so proactively. -- Andrew Piskorski <at...@pi...> |
From: Gustaf N. (sslmail) <ne...@wu...> - 2024-10-08 14:58:36
|
On 07.10.2024, at 17:59, Andrew Piskorski <at...@pi...> wrote: > > On Mon, Oct 07, 2024 at 12:54:32PM +0200, Gustaf Neumann (sslmail) wrote: > >> However, there are many cases, where existing programs use "ns_mkstemp", which cannot be replaced easily. When looking at OpenACS, I see 33 cases like >> >> - the temporary name is passed to an external program (e.g. "tar", "zip", image creation), or >> - the temporary name is passed to a Tcl function expecting a filename (e.g. "file copy"). > > Interesting. It sounds like are no 100% good solutions for this, and > in fact there CAN'T be. This is right in the sense of “there can’t be a solution free of possible race conditions unless the code is refactored” (e.g. let the NaviServer application write to the temp file rather than the external program) > > I'd lean towards turning ns_mktemp into a wrapper around Tcl's "file > tempfile". That calls TclUnixOpenTemporaryFile() and thus mkstemp() > or mkstemps(), but it looks like Tcl has already done the necessary > work What speaks against using the Tcl scripted approach is that so far, we support NaviServer with tcl8.5. “file tempfile” was introduced in Tcl 8.6. Furthermore, TclUnixOpenTemporaryFile() is just for Unix, and not part of the public API (starting with “Tcl_”). But providing this support is not a big thing, since we have in NaviServer since a while support for mkstemp() also for windows (named ns_mkstemp)), since we use this call internally on several places. I’ll cook something up which is most version and platform independent, backward compatible, providing depreciation messages, which can be turned off for “hopeless cases” when admins get annoyed about to many depreciation messages. all the best -g |
From: Wolfgang W. <wol...@di...> - 2024-10-08 13:50:15
|
I like the solution suggested by Andrew as well. This should allow an easy transition of existing code without sacrificing security. Am 07.10.24 um 17:59 schrieb Andrew Piskorski: > On Mon, Oct 07, 2024 at 12:54:32PM +0200, Gustaf Neumann (sslmail) wrote: > >> However, there are many cases, where existing programs use "ns_mkstemp", which cannot be replaced easily. When looking at OpenACS, I see 33 cases like >> >> - the temporary name is passed to an external program (e.g. "tar", "zip", image creation), or >> - the temporary name is passed to a Tcl function expecting a filename (e.g. "file copy"). > Interesting. It sounds like are no 100% good solutions for this, and > in fact there CAN'T be. > >> - Call the safe function (e.g. mkstemp()) and delete the file, while >> producing a depreciation message? This could also be done on the Tcl-level. > I guess so. Probably with a switch to control whether the file is > created and remains (new-style behavior), or gets quickly deleted > (more fully backward compatible). > > I'd lean towards turning ns_mktemp into a wrapper around Tcl's "file > tempfile". That calls TclUnixOpenTemporaryFile() and thus mkstemp() > or mkstemps(), but it looks like Tcl has already done the necessary > work to easily make the wrapper backwards compatible with the > old-style ns_mktemp. And having the compatibility wrapper in Tcl > instead of C makes it a lot easier for NaviServer users to adjust it > to their own needs if necessary. > |
From: Brian F. <bri...@ai...> - 2024-10-08 11:35:27
|
I agree with Andrew's suggested approach here. Brian ________________________________ From: Andrew Piskorski <at...@pi...> Sent: Monday 7 October 2024 4:59 pm To: nav...@li... <nav...@li...> Subject: Re: [naviserver-devel] ns_mktemp On Mon, Oct 07, 2024 at 12:54:32PM +0200, Gustaf Neumann (sslmail) wrote: > However, there are many cases, where existing programs use "ns_mkstemp", which cannot be replaced easily. When looking at OpenACS, I see 33 cases like > > - the temporary name is passed to an external program (e.g. "tar", "zip", image creation), or > - the temporary name is passed to a Tcl function expecting a filename (e.g. "file copy"). Interesting. It sounds like are no 100% good solutions for this, and in fact there CAN'T be. > - Call the safe function (e.g. mkstemp()) and delete the file, while > producing a depreciation message? This could also be done on the Tcl-level. I guess so. Probably with a switch to control whether the file is created and remains (new-style behavior), or gets quickly deleted (more fully backward compatible). I'd lean towards turning ns_mktemp into a wrapper around Tcl's "file tempfile". That calls TclUnixOpenTemporaryFile() and thus mkstemp() or mkstemps(), but it looks like Tcl has already done the necessary work to easily make the wrapper backwards compatible with the old-style ns_mktemp. And having the compatibility wrapper in Tcl instead of C makes it a lot easier for NaviServer users to adjust it to their own needs if necessary. -- Andrew Piskorski <at...@pi...> _______________________________________________ naviserver-devel mailing list nav...@li... https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
From: Georg L. <jor...@ma...> - 2024-10-07 17:33:53
|
On 10/7/24 12:54, Gustaf Neumann (sslmail) wrote: > Dear all. > [..] However, there are many cases, where existing programs use > "ns_mkstemp", which cannot be replaced easily. When looking at > OpenACS, I see 33 cases like - the temporary name is passed to an > external program (e.g. "tar", "zip", image creation), or - the > temporaryname is passed to a Tcl function expecting a filename (e.g. > "file copy"). So, dropping the support for "ns_mkstemp" fully is not a > good option. Also, providing a "home-cooked" version of "ns_mktemp" is > not good either (both in Tcl or in C), since technically speaking, > this will not be better than the original function having the same > problems. Ignoring the compilation warning is not good either, since > sooner or later, the deprecated function will be removed. What should > we do? - place "ns_mktemp" into an external module? NaviServer will > compile nicely, but applications like OpenACS will have to load the > module, making administration and migration to NaviServer 5 less > smooth. - Call the safe function (e.g. mkstemp()) and delete the file, > while producing a depreciation message? This could also be done on the > Tcl-level. I like this option best. It maintains backward compatibility for the application, encourages update to more secure approaches, discourages future use - especially when accompanied by respective hints in the documentation - and removes the warnings for up-to-date applications. At some time in the future, the wrapped ns_mktemp could then be deprecated and moved out into an external module, which still allows legacy operations to continue using it, while raising the bar. Best Regards, Georg > Other options? Opinions? All the best > -g [1] > https://pubs.opengroup.org/onlinepubs/009695399/functions/mktemp.html > [1] https://man.openbsd.org/OpenBSD-7.5/mkstemp.3 > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
From: Zoran V. <zv...@ar...> - 2024-10-07 16:45:51
|
On 07.10.24 12:54, Gustaf Neumann (sslmail) wrote: > So, dropping the support for "ns_mkstemp" fully is not a good option. You mean ns_mktemp? |
From: Zoran V. <zv...@ar...> - 2024-10-07 16:42:10
|
On 07.10.24 17:59, Andrew Piskorski wrote: > I'd lean towards turning ns_mktemp into a wrapper around Tcl's "file > tempfile". That calls TclUnixOpenTemporaryFile() and thus mkstemp() > or mkstemps(), but it looks like Tcl has already done the necessary > work to easily make the wrapper backwards compatible with the > old-style ns_mktemp. Well, if this is so as stated above, then it is a no-brainer! |
From: Andrew P. <at...@pi...> - 2024-10-07 16:16:09
|
On Mon, Oct 07, 2024 at 12:54:32PM +0200, Gustaf Neumann (sslmail) wrote: > However, there are many cases, where existing programs use "ns_mkstemp", which cannot be replaced easily. When looking at OpenACS, I see 33 cases like > > - the temporary name is passed to an external program (e.g. "tar", "zip", image creation), or > - the temporary name is passed to a Tcl function expecting a filename (e.g. "file copy"). Interesting. It sounds like are no 100% good solutions for this, and in fact there CAN'T be. > - Call the safe function (e.g. mkstemp()) and delete the file, while > producing a depreciation message? This could also be done on the Tcl-level. I guess so. Probably with a switch to control whether the file is created and remains (new-style behavior), or gets quickly deleted (more fully backward compatible). I'd lean towards turning ns_mktemp into a wrapper around Tcl's "file tempfile". That calls TclUnixOpenTemporaryFile() and thus mkstemp() or mkstemps(), but it looks like Tcl has already done the necessary work to easily make the wrapper backwards compatible with the old-style ns_mktemp. And having the compatibility wrapper in Tcl instead of C makes it a lot easier for NaviServer users to adjust it to their own needs if necessary. -- Andrew Piskorski <at...@pi...> |
From: Gustaf N. (sslmail) <ne...@wu...> - 2024-10-07 10:54:58
|
Dear all. Since Tcl9 is out there, it becomes time for working towards the NaviServer 5 release. The most recent version of NaviServer from the main branch works nicely with the release of Tcl9 (for trying, you might consider the docker image "gustafn/naviserver/latest-tcl9-bookworm” from https://hub.docker.com/repository/docker/gustafn/naviserver/). One of the open topics for the NaviServer 5 release is the following: The function “ns_mktemp" exists in NaviServer since ages. The function is based on the POSIX call mktemp() [1], which is unfortunately deprecated since a few years. When compiling NaviServer, one sees messages like the following: tclfile.c:255:51: warning: 'mktemp' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of mktemp(3), it is highly recommended that you use mkstemp(3) instead. [-Wdeprecated-declarations] 255 | Tcl_SetObjResult(interp, Tcl_NewStringObj(mktemp(buffer), TCL_INDEX_NONE)); | ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_stdlib.h:210:1: note: 'mktemp' has been explicitly marked deprecated here 210 | __deprecated_msg("This function is provided for compatibility reasons only. Due to security concerns inherent in the design of mktemp(3), it is highly recommended that you use mkstemp(3) instead.") | ^ Even worse, newer versions of OpenBSD produce warning messages whenever code is linked containing calls to mktemp() [2]. So, there is no future for mktemp() in NaviServer. The problem with the C-level function mktemp() is that its usage leads to a race condition, opening space to attacks. The problematic case happens when an application generates a file name with the mktemp() function and then create a file using this name. Unfortunately, this is not secure, because a different process may create a file with this name in the time between the call to mktemp() and the subsequent attempt to create the file by the first process. A malicious user can predict the name of the temporary file, resulting in other files being accessed, modified, corrupted, or deleted. The recommended way is to combine the two steps and create the file in an atomic operation (POSIX mkstemp() for files and mkdtemp() for directories). These functions are used by Tcl "file tempfile" and by Tcl9 "file tempdir" and in NaviServer 5 via "ns_mkdtemp". However, there are many cases, where existing programs use "ns_mkstemp", which cannot be replaced easily. When looking at OpenACS, I see 33 cases like - the temporary name is passed to an external program (e.g. "tar", "zip", image creation), or - the temporary name is passed to a Tcl function expecting a filename (e.g. "file copy"). So, dropping the support for "ns_mkstemp" fully is not a good option. Also, providing a "home-cooked" version of "ns_mktemp" is not good either (both in Tcl or in C), since technically speaking, this will not be better than the original function having the same problems. Ignoring the compilation warning is not good either, since sooner or later, the deprecated function will be removed. What should we do? - place "ns_mktemp" into an external module? NaviServer will compile nicely, but applications like OpenACS will have to load the module, making administration and migration to NaviServer 5 less smooth. - Call the safe function (e.g. mkstemp()) and delete the file, while producing a depreciation message? This could also be done on the Tcl-level. Other options? Opinions? All the best -g [1] https://pubs.opengroup.org/onlinepubs/009695399/functions/mktemp.html [1] https://man.openbsd.org/OpenBSD-7.5/mkstemp.3 |
From: Gustaf N. <ne...@wu...> - 2024-08-12 10:02:22
|
Dear all, I am glad to announce that the release of NaviServer 4.99.30 is available at SourceForge [1] and on GitHub [2]. In essence, this release contains a few small bugfixes and some backported features from the NaviServer 5 developement (auto SNI and Improved handling of large file uploads, portability improvements). Since we want to release NaviServer 5 after Tcl9, and Tcl9 is still not out, some of the backports become more urgent. All the best! -gustaf neumann [1] https://sourceforge.net/projects/naviserver/files/naviserver/4.99.31/ [2] https://github.com/orgs/naviserver-project/repositories ======================================= NaviServer 4.99.31, released 2024-08-11 ======================================= 71 files changed, 897 insertions(+), 303 deletions(-) New Features: ------------- - Added auto-SNI support to "ns_http" and "ns_connchan open": When opening an TLS-connection to named target, the used hostname is automatically used as a default value for the SNI-host. The automatically derived values has a lower priority than the parameter "-hostname" of "ns_http run" or "ns_connchan open". This change eases of use with cloud services and affects all packages using, e.g., "ns_http", including reverse proxies. - Introduced experimental command "ns_fseekchars": This changes Improves file-based parsing of multipart/form-data, supporting files larger than 4GB, reducing memory usage, and speeding up processing.. Bug Fixes: ---------- - Fixed invalid memory reallocation of pool descriptors array [commit 7efaafe4]. - Fixed potential issue for move operation with overlapping memory areas. This change is which was critical for ARM architecture when musl is used (Alpine Linux) [commit 20438ed4]. - Fixed potential crash in "ns_conn copy" to handle cases where an incoming request contains no content [commit 79b8cb8a]. Changes in Sample Configuration Files: -------------------------------------- - Sample configuration file updates for handling container mappings and whitelisting domain names [commits ece849ac, 9a102a97, 86a176ab]. - Backported from NaviServer 5: Includes multiple changes to configuration files and scripts [commit 0d32e5ea]. Misc Improvements: ------------------ - Improved forward compatibility to ease backports [commit ef8b4386]. - Improved spelling and documentation across multiple files to enhance readability and understanding [multiple commits e.g., a2cdaa10, 15253120]. - Improved portability by not assuming that type "char" is the same as "unsigned char", important for compatibility with different architectures [commit 7635ef00]. - Made testing more robust for docker images with partial IPv6 setups to improve reliability in varied deployment environments [commit 516ca38c]. - Removed misleading and unneeded "-encoding binary": This command was a no-op since many Tcl releases and was removed in Tcl9 at all. This change clarifies code usage [commit a36d15b1]. |
From: Matthew B. <mm...@gm...> - 2024-07-01 14:30:37
|
After doing a little digging, I tracked it down to a line in the USB library; sure enough, IOHIDDeviceOpen returns a "privilege violation" error. And just to confirm, if I run NaviServer as root, it all works fine. So thanks again Gustaf for pointing me in the right direction. Now I just need to puzzle out why there's no privilege violation when I run the code via tclsh from the command line. Hopefully that will give me some ideas for a fix since running NaviServer as root isn't really a practical option. Regards, Matt On Sat, Jun 29, 2024 at 8:48 AM < nav...@li...> wrote: > Date: Fri, 28 Jun 2024 12:41:30 -0400 > From: Matthew Burke <mm...@gm...> > To: nav...@li... > Subject: Re: [naviserver-devel] Problem with a Tcl extension and NaviServer > Message-ID: > < > CAC...@ma...> > Content-Type: text/plain; charset="utf-8" > > Hi Gustaf, > > Thanks for the reply. I'll start looking into permissions issues and see if > anything there looks promising. I should also instrument the USB library > and try to get a better sense of what, exactly, is failing. > > Regards, > > Matt > > > On Thu, Jun 27, 2024 at 9:15?AM < > nav...@li...> wrote: > > > > > Dear Mathew, > > > > The answer for your this problem is probably in the call of > > blink1_openById(devid); > > > > Without looking into this call, I would suspect first from my experience > > with NaviServer IoT projects a permission problem when accessing the > > hardware interface. > > For security reasons, NaviServer switches to a nonprivileged user ... > > > > all the best -g > > > > On 25.06.24 16:18, Matthew Burke wrote: > > > Hello! > > > > > > I am writing a Tcl extension in C to wrap a driver for a USB LED > > > status light. The extension runs fine from tclsh but there are issues > > > running it from a Tcl ?page under NaviServer. > > > > > > The extension implements one command via Tcl_CreateObjCommand. The > > > command proc implements a number of sub-commands broken into two > > > categories: device-independent functionality, e.g. count the number of > > > status lights that are plugged in, and device-dependent functionality, > > > e.g. attach to a status light, display a particular color, etc > > > > > > The device-independent sub-commands work when run in a Tcl page. For > > > example, this page runs fine when served from NaviServer: > > > > > > > > > package require blink > > > > > > set n [blink enumerate] > > > > > > ns_return 200 text/html " > > > There are <strong>$n</strong> devices plugged in. > > > " > > > > > > > > > In order to have a device display a color, etc., you first have to run > > > the "open" command. And that's not working. So here's an example Tcl > > page: > > > > > > > > > package require blink > > > > > > set d [blink open 0] > > > set q [ns_conn query] > > > set s [ns_parsequery $q] > > > > > > set red [ns_set get $s red 255] > > > set green [ns_set get $s green 0] > > > set blue [ns_set get $s blue 0] > > > > > > blink set $d $red $green $blue > > > > > > ns_return 200 text/html " > > > ? ? <p>Query: [ns_conn query]</p> > > > > > > ? ? <ul> > > > ? ? <li>Red: $red</li> > > > ? ? <li>Green: $green</li> > > > ? ? <li>Blue: $blue</li> > > > ? ? </ul> > > > " > > > > > > > > > When this page is served, I get an error in the line: set d [blink > > > open 0]. > > > > > > There is a C struct, Blinker, ?that contains data about the attached > > > device. My C code first allocates > > > memory for the struct > > > > > > > > > blinkPtr = (Blinker *)Tcl_Alloc(sizeof(Blinker)); > > > > > > > > > and this seems to work -- blinkPtr is non-NULL after the assignment. > > > Then there is a function from the driver library that actually > > > attaches to the device: > > > > > > blinkPtr->device = blink1_openById(devid); > > > > > > It should return the memory address of an allocated structure that's > > > part of the USB library. But the?function?returns NULL. (Just to > > > reiterate, this works fine when run from tclsh and returns a non-NULL > > > value.) > > > > > > I'm assuming there is some sort of memory protection or similar that I > > > need to take into account. Any suggestions on what to look at would be > > > greatly appreciated. > > > > > > Thanks, > > > > > > Matt > > > > > > P.S. This is on macOS 14.3. I'm compiling the extension as follows: > > > > > > clang -dynamiclib -DUSE_TCL_STUBS -I/usr/local/ns/include > > > -L/usr/local/ns/lib -ltclstub8.6 -o blink.dylib blink.c > > > -L/usr/local/lib -lBlink1 > > > > > > > > > > > > > > > _______________________________________________ > > > naviserver-devel mailing list > > > nav...@li... > > > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > > > > > > ------------------------------ > > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > naviserver-devel mailing list > > nav...@li... > > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > > > > ------------------------------ > > > > End of naviserver-devel Digest, Vol 162, Issue 3 > > ************************************************ > > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > ------------------------------ > > End of naviserver-devel Digest, Vol 162, Issue 4 > ************************************************ > |
From: Matthew B. <mm...@gm...> - 2024-06-28 16:41:47
|
Hi Gustaf, Thanks for the reply. I'll start looking into permissions issues and see if anything there looks promising. I should also instrument the USB library and try to get a better sense of what, exactly, is failing. Regards, Matt On Thu, Jun 27, 2024 at 9:15 AM < nav...@li...> wrote: > > Dear Mathew, > > The answer for your this problem is probably in the call of > blink1_openById(devid); > > Without looking into this call, I would suspect first from my experience > with NaviServer IoT projects a permission problem when accessing the > hardware interface. > For security reasons, NaviServer switches to a nonprivileged user ... > > all the best -g > > On 25.06.24 16:18, Matthew Burke wrote: > > Hello! > > > > I am writing a Tcl extension in C to wrap a driver for a USB LED > > status light. The extension runs fine from tclsh but there are issues > > running it from a Tcl ?page under NaviServer. > > > > The extension implements one command via Tcl_CreateObjCommand. The > > command proc implements a number of sub-commands broken into two > > categories: device-independent functionality, e.g. count the number of > > status lights that are plugged in, and device-dependent functionality, > > e.g. attach to a status light, display a particular color, etc > > > > The device-independent sub-commands work when run in a Tcl page. For > > example, this page runs fine when served from NaviServer: > > > > > > package require blink > > > > set n [blink enumerate] > > > > ns_return 200 text/html " > > There are <strong>$n</strong> devices plugged in. > > " > > > > > > In order to have a device display a color, etc., you first have to run > > the "open" command. And that's not working. So here's an example Tcl > page: > > > > > > package require blink > > > > set d [blink open 0] > > set q [ns_conn query] > > set s [ns_parsequery $q] > > > > set red [ns_set get $s red 255] > > set green [ns_set get $s green 0] > > set blue [ns_set get $s blue 0] > > > > blink set $d $red $green $blue > > > > ns_return 200 text/html " > > ? ? <p>Query: [ns_conn query]</p> > > > > ? ? <ul> > > ? ? <li>Red: $red</li> > > ? ? <li>Green: $green</li> > > ? ? <li>Blue: $blue</li> > > ? ? </ul> > > " > > > > > > When this page is served, I get an error in the line: set d [blink > > open 0]. > > > > There is a C struct, Blinker, ?that contains data about the attached > > device. My C code first allocates > > memory for the struct > > > > > > blinkPtr = (Blinker *)Tcl_Alloc(sizeof(Blinker)); > > > > > > and this seems to work -- blinkPtr is non-NULL after the assignment. > > Then there is a function from the driver library that actually > > attaches to the device: > > > > blinkPtr->device = blink1_openById(devid); > > > > It should return the memory address of an allocated structure that's > > part of the USB library. But the?function?returns NULL. (Just to > > reiterate, this works fine when run from tclsh and returns a non-NULL > > value.) > > > > I'm assuming there is some sort of memory protection or similar that I > > need to take into account. Any suggestions on what to look at would be > > greatly appreciated. > > > > Thanks, > > > > Matt > > > > P.S. This is on macOS 14.3. I'm compiling the extension as follows: > > > > clang -dynamiclib -DUSE_TCL_STUBS -I/usr/local/ns/include > > -L/usr/local/ns/lib -ltclstub8.6 -o blink.dylib blink.c > > -L/usr/local/lib -lBlink1 > > > > > > > > > > _______________________________________________ > > naviserver-devel mailing list > > nav...@li... > > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > > ------------------------------ > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > ------------------------------ > > End of naviserver-devel Digest, Vol 162, Issue 3 > ************************************************ > |
From: Gustaf N. <ne...@wu...> - 2024-06-27 08:59:28
|
Dear Mathew, The answer for your this problem is probably in the call of blink1_openById(devid); Without looking into this call, I would suspect first from my experience with NaviServer IoT projects a permission problem when accessing the hardware interface. For security reasons, NaviServer switches to a nonprivileged user ... all the best -g On 25.06.24 16:18, Matthew Burke wrote: > Hello! > > I am writing a Tcl extension in C to wrap a driver for a USB LED > status light. The extension runs fine from tclsh but there are issues > running it from a Tcl page under NaviServer. > > The extension implements one command via Tcl_CreateObjCommand. The > command proc implements a number of sub-commands broken into two > categories: device-independent functionality, e.g. count the number of > status lights that are plugged in, and device-dependent functionality, > e.g. attach to a status light, display a particular color, etc > > The device-independent sub-commands work when run in a Tcl page. For > example, this page runs fine when served from NaviServer: > > > package require blink > > set n [blink enumerate] > > ns_return 200 text/html " > There are <strong>$n</strong> devices plugged in. > " > > > In order to have a device display a color, etc., you first have to run > the "open" command. And that's not working. So here's an example Tcl page: > > > package require blink > > set d [blink open 0] > set q [ns_conn query] > set s [ns_parsequery $q] > > set red [ns_set get $s red 255] > set green [ns_set get $s green 0] > set blue [ns_set get $s blue 0] > > blink set $d $red $green $blue > > ns_return 200 text/html " > <p>Query: [ns_conn query]</p> > > <ul> > <li>Red: $red</li> > <li>Green: $green</li> > <li>Blue: $blue</li> > </ul> > " > > > When this page is served, I get an error in the line: set d [blink > open 0]. > > There is a C struct, Blinker, that contains data about the attached > device. My C code first allocates > memory for the struct > > > blinkPtr = (Blinker *)Tcl_Alloc(sizeof(Blinker)); > > > and this seems to work -- blinkPtr is non-NULL after the assignment. > Then there is a function from the driver library that actually > attaches to the device: > > blinkPtr->device = blink1_openById(devid); > > It should return the memory address of an allocated structure that's > part of the USB library. But the function returns NULL. (Just to > reiterate, this works fine when run from tclsh and returns a non-NULL > value.) > > I'm assuming there is some sort of memory protection or similar that I > need to take into account. Any suggestions on what to look at would be > greatly appreciated. > > Thanks, > > Matt > > P.S. This is on macOS 14.3. I'm compiling the extension as follows: > > clang -dynamiclib -DUSE_TCL_STUBS -I/usr/local/ns/include > -L/usr/local/ns/lib -ltclstub8.6 -o blink.dylib blink.c > -L/usr/local/lib -lBlink1 > > > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
From: Matthew B. <mm...@gm...> - 2024-06-25 14:18:42
|
Hello! I am writing a Tcl extension in C to wrap a driver for a USB LED status light. The extension runs fine from tclsh but there are issues running it from a Tcl page under NaviServer. The extension implements one command via Tcl_CreateObjCommand. The command proc implements a number of sub-commands broken into two categories: device-independent functionality, e.g. count the number of status lights that are plugged in, and device-dependent functionality, e.g. attach to a status light, display a particular color, etc The device-independent sub-commands work when run in a Tcl page. For example, this page runs fine when served from NaviServer: package require blink set n [blink enumerate] ns_return 200 text/html " There are <strong>$n</strong> devices plugged in. " In order to have a device display a color, etc., you first have to run the "open" command. And that's not working. So here's an example Tcl page: package require blink set d [blink open 0] set q [ns_conn query] set s [ns_parsequery $q] set red [ns_set get $s red 255] set green [ns_set get $s green 0] set blue [ns_set get $s blue 0] blink set $d $red $green $blue ns_return 200 text/html " <p>Query: [ns_conn query]</p> <ul> <li>Red: $red</li> <li>Green: $green</li> <li>Blue: $blue</li> </ul> " When this page is served, I get an error in the line: set d [blink open 0]. There is a C struct, Blinker, that contains data about the attached device. My C code first allocates memory for the struct blinkPtr = (Blinker *)Tcl_Alloc(sizeof(Blinker)); and this seems to work -- blinkPtr is non-NULL after the assignment. Then there is a function from the driver library that actually attaches to the device: blinkPtr->device = blink1_openById(devid); It should return the memory address of an allocated structure that's part of the USB library. But the function returns NULL. (Just to reiterate, this works fine when run from tclsh and returns a non-NULL value.) I'm assuming there is some sort of memory protection or similar that I need to take into account. Any suggestions on what to look at would be greatly appreciated. Thanks, Matt P.S. This is on macOS 14.3. I'm compiling the extension as follows: clang -dynamiclib -DUSE_TCL_STUBS -I/usr/local/ns/include -L/usr/local/ns/lib -ltclstub8.6 -o blink.dylib blink.c -L/usr/local/lib -lBlink1 |
From: Gustaf N. <ne...@wu...> - 2024-06-17 17:51:15
|
Dear all, I've committed the following change to the GitHub repository of NaviServer, that adds significant improvements for FORM uploads of large files. It makes it now possible to handle files uploads via multipart/form-data (usual format) larger than 4GB without crashing. The support is just for NaviServer, applications (e.g. OpenACS) might still try to read such large files into Tcl_Objs leading to crashes with Tcl 8. Although, loading huge data into memory is not a good practice and leads to memory bloats. However, this should work with Tcl9. The code replaces an implementation that has not changed for the last 17 years. I am planing to backport this change also to the 4.99 branch. All the best -g Added experimental command "ns_fseekchars" and use it in form.tcl for parsing multipart/form-data As a consequence, (a) the file-based parser of multipart/form-data is able to read files >4GB, (b) leads to less memory bloat and (c) is more than a factor of 10 faster file size old ns_fseekchars factor 65,517 4,471 151 29.61 124,523 1,139 94 12.12 74,006,378 682,375 54,752 12.46 2,104,408,064 18,916,496 1,564,472 12.09 3,992,977,408 35,942,768 3,061,061 11.74 5,368,709,120 3,817,896 The problem with the old file-based parser was that it was searching for boundary strings using the Tcl "gets" command: if { [string match $boundary* [string trim [gets $fp]]] } { ... } Since "gets" reads a line (i.e., all character until the next new line) Tcl can crash, when the next new line is more than 4GB away. Even with e.g. 2GB, it will temporarily create a Tcl_Obj with 2GB content, which is stripped etc. leading therefore to a potential memory bloat keeping multiple huge Tcl_Objs in memory. The new code avoids all this by performing the search for the boundary in C. TODO: add documentation page |
From: Gustaf N. (sslmail) <ne...@wu...> - 2024-05-30 17:47:20
|
Dear all, RFC 2616 requires an absolute URI in the "Location" header field. So if someone calls "ns_returnredirect /", NaviServer transforms it on the fly into an absolute URL by prefixing it with the location (e.g. https://openacs.org/). NaviServer (and OpenACS) has some complex code to compute the location value, especially when virtual servers are involved (or for "host-node mapped" subsites in OpenACS). The situation is further complicated when running behind a reverse proxy and/or in a containerized environment. In such cases, the location is computed from the "host" request header field, which must be validated, otherwise an attacker could hijack a session and redirect it to a spoofed site. The situation changed 10 years ago (June 2014) with the introduction of RFC 7231, which allows relative redirects (see https://www.rfc-editor.org/rfc/rfc7231#section-7.1.2). Using relative redirects greatly simplifies configuration and closes the attack vector using the host header field. RFC 7231 has been superseded by RFC 9110 (June 2022), which also supports relative redirects via the "location" response header field (see https://www.rfc-editor.org/rfc/rfc9110#field.location). The latest version of NaviServer (already running on OpenACS.org) now implements relative redirects as supported by the newer RFCs. Only if a location proc has been registered "ns_locationproc", the URL will be prefixed with it for better backwards compatibility. The change to support relative redirects should simplify many configurations. There have been many questions about redirects where people have struggled to set them up. I've only added this change to the main branch of NaviServer. I have no intention of backporting it to the 4.99 series at this time. If you have any objections or suggestions, please let me know. |
From: Gustaf N. (sslmail) <ne...@wu...> - 2024-05-03 12:13:40
|
There are multiple processing steps involved in your example. One thing is how to use the URLspace mappings (responsible for all kinds of requests, but not only), where the URL ordering plays a rule, and the another thing are request filters, which are fully independent of the URLspace. Given the lifecycle of requests, the resolving of the requests happens in the step “process request” below: Once a connection thread is selected, the server runs filters (pre-auth and post-auth) and then it runs the request procs.  There might be multiple of these filters, where the registration order is relevant. A filter might decide to continue to the next filter or send a reply to the client. This is singled via the result of the filter procs. A filter should return one of the three values “filter_ok”, “filter_break” or “filter_return” (for details, check the man page of ns_register) https://naviserver.sourceforge.io/n/naviserver/files/ns_register.html#3 In your case, the reverse proxy is registered via a match-all post-auth filter (/*) ending with a “filter-return” which has the consequence no request-proc (such as fastpath) will be involved. So registering additional request procs won’t make a difference. In your example, one could either register an additional filter at the beginning of the filter change that lets the static requests through (ending with filter_break),, or one could consider moving the handling of the reverse proxy to the URLspace, by registering the handlers via ns_register_proc instead of using ns_register_filter. Hope this explains, all the best -g > On 02.05.2024, at 16:33, Georg Lehner <jor...@ma...> wrote: > I am trying to configure Naviserver as reverse proxy for a Django project. > > Django features deployment of static assests like css, js etc. into a separate URL, typically /static, which can then be served directly by the webserver. Everything else has to be reverse-proxied to the wsgi server which serves the Django app via http. > > My revproxy setup is: > > ns_section ns/server/default { > ns_param enabletclpages false > ns_param minthreads 10 > } > ns_section ns/server/default/fastpath { > ns_param pagedir www > ns_param serverdir $serverroot/default > ns_param directoryproc ns_returnnotfound > ns_param directoryfile index.html > } > ns_section ns/server/default/modules { > ns_param revproxy tcl > ns_param nssock nssock > } > ns_section ns/server/default/module/revproxy { > ns_param filters { > ns_register_filter postauth GET /* ::revproxy::upstream -target http://localhost:65193 <http://localhost:65193/> > ns_register_filter postauth POST /* ::revproxy::upstream -target http://localhost:65193 <http://localhost:65193/> > } > } > ns_section ns/server/default/module/nssock { > ns_param port 0 > } > I have made several attempts to register the /static/* URL to be handled by fastpath and map it to a directory have failed. The server always sends the requests to the revproxy backend. > Is it possible to "override" this, and if yes then how? > > Best Regards, > > Georg > |
From: Georg L. <jor...@ma...> - 2024-05-02 14:33:13
|
Hello, I am trying to configure Naviserver as reverse proxy for a Django project. Django features deployment of static assests like css, js etc. into a separate URL, typically /static, which can then be served directly by the webserver. Everything else has to be reverse-proxied to the wsgi server which serves the Django app via http. My revproxy setup is: ns_section ns/server/default { ns_param enabletclpages false ns_param minthreads 10 } ns_section ns/server/default/fastpath { ns_param pagedir www ns_param serverdir $serverroot/default ns_param directoryproc ns_returnnotfound ns_param directoryfile index.html } ns_section ns/server/default/modules { ns_param revproxy tcl ns_param nssock nssock } ns_section ns/server/default/module/revproxy { ns_param filters { ns_register_filter postauth GET /* ::revproxy::upstream -targethttp://localhost:65193 ns_register_filter postauth POST /* ::revproxy::upstream -targethttp://localhost:65193 } } ns_section ns/server/default/module/nssock { ns_param port 0 } I have made several attempts to register the /static/* URL to be handled by fastpath and map it to a directory have failed. The server always sends the requests to the revproxy backend. Is it possible to "override" this, and if yes then how? Best Regards, Georg |
From: David O. <da...@qc...> - 2024-05-02 14:30:23
|
Thanks again Gustaf. I've been running some tests and it's looking good. There's one case I'm not sure this can cater for, and this is probably more of an issue in development environments... When the trusted cidr is a subnet which also contains the client. Say ns_section ns/parameters/reverseproxymode { ns_param enabled on ns_param trustedservers {192.168.0.0/16} ns_param skipnonpublic false } And Client IP = 192.168.0.10 with a proxy on 192.168.0.200 I think NaviServer will skip all addresses which appear in the trusted subnet: Do you think it would be appropriate to have this behaviour as configurable? Option 1. Strict. If the header is from a peer on the trusted list - return only the entry our trusted peer added (regardless of whether that entry is, in turn, also in the trusted subnet). ff {192.168.0.11,192.168.0.10} key 0-1 peer 192.168.0.200 forwarded {192.168.0.10} Option 2. Greedy. If the header is from a peer on the trusted list - return the first untrusted entry searching from the right ff {192.168.0.11,192.168.0.10} key 0-1 peer 192.168.0.200 forwarded {} (I think this is why Nginx introduced the "real_ip_recursive" option on their real_ip module for instance.) https://nginx.org/en/docs/http/ngx_http_realip_module.html |
From: Georg L. <jor...@ma...> - 2024-05-02 06:28:59
|
On 2024-05-01 13:56, Gustaf Neumann (sslmail) wrote: > > >> On 30.04.2024, at 20:53, Georg Lehner <jor...@ma...> wrote: >> >> Hello, >> >> I am trying to set up the revproxy module on a current naviserver git >> checkout. >> >> Upon connection to the frontend I get: >> >> Request Error >> Error during opening connection to backend >> http://localhost:65193/ failed. >> Error message: no driver for protocol 'http' found >> >> NaviServer/5.0.0a >> > > Probably, you have no nssock module installed. ns_sock uses the > network drivers installed, and in case, your configuration network > does not include it, it is not available. If you want to use a driver > module, but you do not want to listen on a port, configure the port > with the value 0 > ... Thank you, this worked out. In fact I had only configured nsssl on this server. Best Regards, Georg -- MagmaSoft e.U. (FN 601643w) Inhaber: Ing. Georg Lehner Kolpingstraße 15, A-4020 Linz https://magma-soft.at/ mailto:jo...@ma... |
From: Gustaf N. (sslmail) <ne...@wu...> - 2024-05-01 11:57:07
|
> On 30.04.2024, at 20:53, Georg Lehner <jor...@ma...> wrote: > > Hello, > > I am trying to set up the revproxy module on a current naviserver git checkout. > > Upon connection to the frontend I get: > > Request Error > Error during opening connection to backend http://localhost:65193/ failed. > Error message: no driver for protocol 'http' found > > NaviServer/5.0.0a > Probably, you have no nssock module installed. ns_sock uses the network drivers installed, and in case, your configuration network does not include it, it is not available. If you want to use a driver module, but you do not want to listen on a port, configure the port with the value 0 > The same message I get when starting 'nsd -c' and running either of > > ns_connchan open http://example.com <http://example.com/> -> no driver for protocol 'http' found > > ns_connchan open https://example.com <https://example.com/> -> no driver for protocol 'https' found > Same as above. When “nsd -c” is called, no network drivers are loaded -g |
From: Georg L. <jor...@ma...> - 2024-04-30 19:20:46
|
Hello, I am trying to set up the revproxy module on a current naviserver git checkout. Upon connection to the frontend I get: Request Error Error during opening connection to backend http://localhost:65193/ failed. Error message: no driver for protocol 'http' found NaviServer/5.0.0a The same message I get when starting 'nsd -c' and running either of ns_connchan open http://example.com -> no driver for protocol 'http' found ns_connchan open https://example.com -> no driver for protocol 'https' found I'm puzzled, because some months ago I tested revproxy successfully. Can you give me hints on how to get going? Best Regards, Georg |
From: Gustaf N. (sslmail) <ne...@wu...> - 2024-04-30 16:16:57
|
Dear David & all, i’ve committed now a version to the main branch of NaviServer on GitHub. In addition of my last writeup, i’ve further increased the configurability to make ignoring of non-public servers configurable, no matter whether trusted severs are configured or not. To ease configuration, there is now an own section (instead of use ever-growing variable names). OLD: ns_section ns/parameters { ... ns_param reverseproxymode true ... } NEW: ns_section ns/parameters/reverseproxymode { ns_param enabled on ns_param trustedservers {192.168.0.0/16 137.208.89.213} ns_param skipnonpublic true } The detailed commit message is https://github.com/naviserver-project/naviserver/commit/ab23158ece6fcbec4f740a41140592c910de64f3 "x-forwarded-for" reform (part 1) · naviserver-project/naviserver@ab23158 github.com below are the test-cases, where the key $X-$Y - X: stands for skipnonpublic, and - Y: stands for trustedservers configured (and trusted servers are "192.168.0.0/16 127.0.0.1”) documentation updates will follow. all the best -g # just one XFF entry non-trusted (must be client) lappend cases {ff {1.1.1.1} key 0-0 peer 1.1.1.1 forwarded 1.1.1.1} lappend cases {ff {1.1.1.1} key 0-1 peer 1.1.1.1 forwarded 1.1.1.1} lappend cases {ff {1.1.1.1} key 1-0 peer 1.1.1.1 forwarded 1.1.1.1} lappend cases {ff {1.1.1.1} key 1-1 peer 1.1.1.1 forwarded 1.1.1.1} # just one entry trusted (i.e. must be proxy server) lappend cases {ff {192.168.1.10} key 0-0 peer 192.168.1.10 forwarded 192.168.1.10} lappend cases {ff {192.168.1.10} key 0-1 peer 127.0.0.1 forwarded {}} lappend cases {ff {192.168.1.10} key 1-0 peer 127.0.0.1 forwarded {}} lappend cases {ff {192.168.1.10} key 1-1 peer 127.0.0.1 forwarded {}} # just one entry local lappend cases {ff {127.0.0.3} key 0-0 peer 127.0.0.3 forwarded 127.0.0.3} lappend cases {ff {127.0.0.3} key 0-1 peer 127.0.0.3 forwarded 127.0.0.3} lappend cases {ff {127.0.0.3} key 1-0 peer 127.0.0.1 forwarded {}} lappend cases {ff {127.0.0.3} key 1-1 peer 127.0.0.1 forwarded {}} # two entries, both untrusted lappend cases {ff {1.1.1.1, 2.2.2.2} key 0-0 peer 1.1.1.1 forwarded 1.1.1.1} lappend cases {ff {1.1.1.1, 2.2.2.2} key 0-1 peer 2.2.2.2 forwarded 2.2.2.2} lappend cases {ff {1.1.1.1, 2.2.2.2} key 1-0 peer 1.1.1.1 forwarded 1.1.1.1} lappend cases {ff {1.1.1.1, 2.2.2.2} key 1-1 peer 2.2.2.2 forwarded 2.2.2.2} # two entries, second trusted lappend cases {ff {1.1.1.1, 192.168.1.10} key 0-0 peer 1.1.1.1 forwarded 1.1.1.1} lappend cases {ff {1.1.1.1, 192.168.1.10} key 0-1 peer 1.1.1.1 forwarded 1.1.1.1} lappend cases {ff {1.1.1.1, 192.168.1.10} key 1-0 peer 1.1.1.1 forwarded 1.1.1.1} lappend cases {ff {1.1.1.1, 192.168.1.10} key 1-1 peer 1.1.1.1 forwarded 1.1.1.1} # two entries, both trusted lappend cases {ff {192.168.1.11, 192.168.1.10} key 0-0 peer 192.168.1.11 forwarded 192.168.1.11} lappend cases {ff {192.168.1.11, 192.168.1.10} key 0-1 peer 127.0.0.1 forwarded {}} lappend cases {ff {192.168.1.11, 192.168.1.10} key 1-0 peer 127.0.0.1 forwarded {}} lappend cases {ff {192.168.1.11, 192.168.1.10} key 1-1 peer 127.0.0.1 forwarded {}} # two entries, both local lappend cases {ff {127.0.0.2, 127.0.0.3} key 0-0 peer 127.0.0.2 forwarded 127.0.0.2} lappend cases {ff {127.0.0.2, 127.0.0.3} key 0-1 peer 127.0.0.3 forwarded 127.0.0.3} lappend cases {ff {127.0.0.2, 127.0.0.3} key 1-0 peer 127.0.0.1 forwarded {}} lappend cases {ff {127.0.0.2, 127.0.0.3} key 1-1 peer 127.0.0.1 forwarded {}} # empty entry lappend cases {ff {} key 0-0 peer 127.0.0.1 forwarded {}} lappend cases {ff {} key 0-1 peer 127.0.0.1 forwarded {}} lappend cases {ff {} key 1-0 peer 127.0.0.1 forwarded {}} lappend cases {ff {} key 1-1 peer 127.0.0.1 forwarded {}} # wrong entry lappend cases {ff {x} key 0-0 peer 127.0.0.1 forwarded {}} lappend cases {ff {x} key 0-1 peer 127.0.0.1 forwarded {}} lappend cases {ff {x} key 1-0 peer 127.0.0.1 forwarded {}} lappend cases {ff {x} key 1-1 peer 127.0.0.1 forwarded {}} # wrong entry on the right lappend cases {ff {137.208.116.31, x} key 0-0 peer 137.208.116.31 forwarded 137.208.116.31} lappend cases {ff {137.208.116.31, x} key 0-1 peer 127.0.0.1 forwarded {}} lappend cases {ff {137.208.116.31, x} key 1-0 peer 137.208.116.31 forwarded 137.208.116.31} lappend cases {ff {137.208.116.31, x} key 1-1 peer 127.0.0.1 forwarded {}} # wrong entry on the left lappend cases {ff {y, 137.208.116.31} key 0-0 peer 127.0.0.1 forwarded {}} lappend cases {ff {y, 137.208.116.31} key 0-1 peer 137.208.116.31 forwarded 137.208.116.31} lappend cases {ff {y, 137.208.116.31} key 1-0 peer 127.0.0.1 forwarded {}} lappend cases {ff {y, 137.208.116.31} key 1-1 peer 137.208.116.31 forwarded 137.208.116.31} > On 29.04.2024, at 10:47, David Osborne <da...@qc...> wrote: > > Hi Gustaf, > > From your description it sounds like we could certainly work round our issue using the ReverseProxyTrustedServers config. > Thank you very much for your time on this. > > On Fri, 26 Apr 2024 at 14:09, Gustaf Neumann (sslmail) <ne...@wu... <mailto:ne...@wu...>> wrote: >> Hi David, >> >> I have now implemented the following (but not yet committed, >> since i was side-tracked by some tcl9 issues and i am running out of >> time. >> >> From my understanding, this should address your problems now, >> and when “proxy 2” is removed. >> >> An easy extension of this would be to let the site-admin configure >> an alternative header field (like x-real-ip), which could bypass >> the search through the list of candidate addresses. >> >> all the best >> -gn >> > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
From: David O. <da...@qc...> - 2024-04-29 08:55:31
|
Hi Gustaf, >From your description it sounds like we could certainly work round our issue using the ReverseProxyTrustedServers config. Thank you very much for your time on this. On Fri, 26 Apr 2024 at 14:09, Gustaf Neumann (sslmail) <ne...@wu...> wrote: > Hi David, > > I have now implemented the following (but not yet committed, > since i was side-tracked by some tcl9 issues and i am running out of > time. > > From my understanding, this should address your problems now, > and when “proxy 2” is removed. > > An easy extension of this would be to let the site-admin configure > an alternative header field (like x-real-ip), which could bypass > the search through the list of candidate addresses. > > all the best > -gn > > |