naviserver-devel — Developer discussion

Re: [naviserver-devel] scheduler thread getting stuck

[Andrew P. <at...@pi...>]

On Mon, Jun 01, 2020 at 11:08:48AM -0400, Andrew Piskorski wrote:

> ==== encoding-1.1 Send body with ns_return and charset utf-8 FAILED

> ---- errorInfo: select failed: no such file or directory
> invoked from within
> "nstest::http-0.9 -encoding utf-8 -getbody 1 -getheaders {Content-Type Content-Length} GET "/encoding""

There are 7 different versions of the encoding.* page present.  If I
start up the test server and then ask it for the FULL URL of any one
of those files, like "encoding.utf2iso_adp", it works fine!  But if I
just ask for "encoding" without the extension it fails.

So hitting this URL works fine:
  http://localhost:8000/encoding.utf_adp
But this fails with 404 Not Found:
  http://localhost:8000/encoding

I see that test.nscfg has what look like appropriate "ns/mimetypes"
and "ns/encodings" sections, and of course that same config file works
fine on Linux.  So what could be going wrong on my Windows box to
break the mapping of "/encoding" to "/encoding.utf_adp"?

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] scheduler thread getting stuck

[Andrew P. <at...@pi...>]

On Fri, May 15, 2020 at 10:37:15AM +0200, Gustaf Neumann wrote:
> does the regression test run ok?

Good question.  Unfortunately, I'd never run the regression tests on
Windows before.  I now have them set up to run, however, I get LOTS of
failures, and I don't know if these are real problems with NaviServer,
or something wrong with my testing setup.  Either way, I would like to
track it down so I can rely on running these same regression tests on
Windows as on Linux.

Are the tests in "naviserver/tests/all.tcl" supposed to work correctly
on Windows too?  Is anyone else successfully running these tests there?

On Windows, I always get immediate failures due to return codes of 1.
The first such failure is "encoding-1.1", output shown below.

More concerning, is that once it gets to "http_persistent.test", the
whole NaviServer process locks up and never gets any farther.  So any
tests that come AFTER that one are not being run at all.  I've left
the test NaviServer running overnight just to be sure, and after that
point there's never any more output until I hit Ctrl-c to shut it down.

So far I've tested the nearly latest NaviServer head code on Windows 7
(no Windows 10 yet), with both the old 2010 and newer 2019 Microsoft
compilers.  The behavior of the regression tests appears identical in
both cases.  I have not yet tested older versions of NaviServer.  On
Linux these tests all run fine, of course.

On Windows, I can invoke "tests/all.tcl" either before or after
installing NaviServer.  Test behavior appears to be the same in both
cases.  Before installing, I start the tests like this:

  nmake -f Makefile.win32 _test

For that to work, you need these small patches to Makefile.win32:

  https://bitbucket.org/apiskors/naviserver/commits/7d7e245f8451419de3ac9b1d6202e5f26c883fdd


## First test to fail on Windows:

==== encoding-1.1 Send body with ns_return and charset utf-8 FAILED
==== Contents of test case:

nstest::http-0.9 -encoding utf-8 -getbody 1 -getheaders {Content-Type Content-Length} GET "/encoding"

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: select failed: no such file or directory
invoked from within
"nstest::http-0.9 -encoding utf-8 -getbody 1 -getheaders {Content-Type Content-Length} GET "/encoding""
("uplevel" body line 2)
invoked from within
"uplevel 1 $script"
---- errorCode: NONE
==== encoding-1.1 FAILED


## Last test that runs on Windows, it locks up forever:

http_persistent.test
ns_sockioctl failed: no such file or directory
while executing
"ns_socknread $s"
(procedure "client_readable" line 2)
invoked from within
"client_readable 1000 $s"
(procedure "tcltest::client_receive" line 2)
invoked from within
"tcltest::client_receive sock0000000005DA6CE0"

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] Verifying HMAC signature [ns_crypto::hmac ...]

[Iuri de A. S. <iu...@iu...>]

Thanks Gustaf,
Yes, it works fine!
I was not capable to understand the verification part. I was trying to learn it by repeating the method of base64* with encode/decode. Then, after decrypting, to verify if secret and data were both the same from the original request 
Best wishes,
I



On May 26, 2020, at 13:05, IU...@iu... <IU...@IU...> wrote:

Thanks Gustaf,
It works now.

p.s. I don't understand why the subject of this thread got replaced with a previous thread that I opened.
The original email that I sent has the subject: "Verifying HMAC signature [ns_crypto::hmac ...]"

-------- Original Message --------
Subject: Re: [naviserver-devel] What to do when [ns_base64encode]
doesn't encrypt properly after the 63rd char?
From: Gustaf Neumann <ne...@wu... <mailto:ne...@wu...>>
Date: Tue, May 26, 2020 12:27 am
To: nav...@li... <mailto:nav...@li...>

Iuri, 
The nsc_crypto::hmac performs the HMAC  (Keyed-Hashing for 
Message Authentication) as specified in RFC 2104, using a symmetric 
key provided via argument.

The HMAC can be verified the same way as a plain digest (without a secret):
If a received HMAC (or digest) should be verified, it must be recomputed.
In the case of the HMAC, the receiver has to know the secret. 

I see no need for an extra API call:
=========================================================================== set secret_key "foobar1234" set data "This is my data" set HMAC [ns_crypto::hmac string -digest sha256 $secret_key $data] # # To verify a received HMAC , one needs the key and the data as well # if { $HMAC eq [ns_crypto::hmac string -digest sha256 $secret_key $data] } { ns_log notice "Data verified" } ===========================================================================
The ns_crypto interface provides as well the interface based on key files
(PEM files) provided for "ns_crypto::md". In the case of the pem 
files, it is more effort to extract keys, since there exists several 
algorithms, key types etc., which are in specified inside the PEM 
files. Therefore, this interface works for multiple key types, 
include RSA and elliptic curves.

In this variant,  the message key can be signed with 

   set sig [::ns_crypto::md string ... -sign PEM ...] 
and verified with 

   ::ns_crypto::md string ... -verify PEM -signature $sig ... 
Below is the example from the man page.

all the best
-gn
=========================================================================== % set sig [::ns_crypto::md string \ -digest sha1 \ -encoding binary \ -sign /usr/local/src/naviserver/myprivate.pem \ "abcdefghijklmnopqrstuxvwxyz\n"] % set vfy [::ns_crypto::md string \ -digest sha1 \ -verify /usr/local/src/naviserver/myprivate.pem \ -signature $sig \ "abcdefghijklmnopqrstuxvwxyz\n"] 1 ===========================================================================



_______________________________________________
naviserver-devel mailing list
nav...@li... <mailto:nav...@li...>
https://lists.sourceforge.net/lists/listinfo/naviserver-devel <https://lists.sourceforge.net/lists/listinfo/naviserver-devel>
_______________________________________________
naviserver-devel mailing list
nav...@li...
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] What to do when [ns_base64encode] doesn't encrypt properly after the 63rd char?

[<iu...@iu...>]

<html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;"><div>Thanks Gustaf,</div><div>It works now.</div><div><br></div><div>p.s. I don't understand why the subject of this thread got replaced with a previous thread that I opened.</div><div class="p1" style="">The original email that I sent has the subject:&nbsp;<span style="font-size: 10pt;">"Verifying HMAC signature [ns_crypto::hmac ...]"</span></div><div><br></div>
<blockquote id="replyBlockquote" webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:10pt; color:black; font-family:verdana;">
<div id="wmQuoteWrapper">
-------- Original Message --------<br>
Subject: Re: [naviserver-devel] What to do when [ns_base64encode]<br>
doesn't encrypt properly after the 63rd char?<br>
From: Gustaf Neumann &lt;<a href="mailto:ne...@wu...">ne...@wu...</a>&gt;<br>
Date: Tue, May 26, 2020 12:27 am<br>
To: <a href="mailto:nav...@li...">nav...@li...</a><br>
<br>
     <div>Iuri, <br> </div> <div>The nsc_crypto::hmac performs the HMAC&nbsp; (Keyed-Hashing for <br> Message Authentication) as specified in RFC 2104, using a symmetric <br> key provided via argument.<br> <br> The HMAC can be verified the same way as a plain digest (without a secret):<br> If a received HMAC (or digest) should be verified, it must be recomputed.<br> In the case of the HMAC, the receiver has to know the secret. <br> <br> I see no need for an extra API call:<br> </div> <divre>===========================================================================
set secret_key "foobar1234"
set data "This is my data"

set HMAC [ns_crypto::hmac string -digest sha256 $secret_key $data]

#
# To verify a received HMAC , one needs the key and the data as well
#
if { $HMAC eq [ns_crypto::hmac string -digest sha256 $secret_key $data] } {
   ns_log notice "Data verified"
}
===========================================================================
</pre> <p>The ns_crypto interface provides as well the interface based on key files<br> (PEM files) provided for "ns_crypto::md". In the case of the pem <br> files, it is more effort to extract keys, since there exists several <br> algorithms, key types etc., which are in specified inside the PEM <br> files. Therefore, this interface works for multiple key types, <br> include RSA and elliptic curves.<br> <br> In this variant,&nbsp; the message key can be signed with <br> </div> <divre>&nbsp;&nbsp; set sig [::ns_crypto::md string ... -sign PEM ...]</pre> <p>and verified with <br> </div> <divre>&nbsp;&nbsp; ::ns_crypto::md string ... -verify PEM -signature $sig ...</pre> <p>Below is the example from the man page.<br> </div> <div>all the best<br> -gn<br> </div> <divre>===========================================================================
% set sig [::ns_crypto::md string \
	     -digest sha1 \
	     -encoding binary \
	     -sign /usr/local/src/naviserver/myprivate.pem \
	     "abcdefghijklmnopqrstuxvwxyz\n"]
  
% set vfy [::ns_crypto::md string \
	     -digest sha1 \
	     -verify /usr/local/src/naviserver/myprivate.pem \
	     -signature $sig \
	     "abcdefghijklmnopqrstuxvwxyz\n"]
1
===========================================================================
</pre> <p><br> </div> <div><br> </div>   <hr><hr>_______________________________________________<br>
naviserver-devel mailing list<br>
<a href="mailto:nav...@li...">nav...@li...</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/naviserver-devel">https://lists.sourceforge.net/lists/listinfo/naviserver-devel</a><br>

</div>
</blockquote></span></body></html>

Re: [naviserver-devel] What to do when [ns_base64encode] doesn't encrypt properly after the 63rd char?

[Gustaf N. <ne...@wu...>]

Iuri,

The nsc_crypto::hmac performs the HMAC  (Keyed-Hashing for
Message Authentication) as specified in RFC 2104, using a symmetric
key provided via argument.

The HMAC can be verified the same way as a plain digest (without a secret):
If a received HMAC (or digest) should be verified, it must be recomputed.
In the case of the HMAC, the receiver has to know the secret.

I see no need for an extra API call:

===========================================================================
set secret_key "foobar1234"
set data "This is my data"

set HMAC [ns_crypto::hmac string -digest sha256 $secret_key $data]

#
# To verify a received HMAC , one needs the key and the data as well
#
if { $HMAC eq [ns_crypto::hmac string -digest sha256 $secret_key $data] } {
    ns_log notice "Data verified"
}
===========================================================================

The ns_crypto interface provides as well the interface based on key files
(PEM files) provided for "ns_crypto::md". In the case of the pem
files, it is more effort to extract keys, since there exists several
algorithms, key types etc., which are in specified inside the PEM
files. Therefore, this interface works for multiple key types,
include RSA and elliptic curves.

In this variant,  the message key can be signed with

    set sig [::ns_crypto::md string ... -sign PEM ...]

and verified with

    ::ns_crypto::md string ... -verify PEM -signature $sig ...

Below is the example from the man page.

all the best
-gn

===========================================================================
% set sig [::ns_crypto::md string \
	     -digest sha1 \
	     -encoding binary \
	     -sign /usr/local/src/naviserver/myprivate.pem \
	     "abcdefghijklmnopqrstuxvwxyz\n"]
   
% set vfy [::ns_crypto::md string \
	     -digest sha1 \
	     -verify /usr/local/src/naviserver/myprivate.pem \
	     -signature $sig \
	     "abcdefghijklmnopqrstuxvwxyz\n"]
1
===========================================================================

Re: [naviserver-devel] What to do when [ns_base64encode] doesn't encrypt properly after the 63rd char?

[Gustaf N. <ne...@wu...>]

On 25.05.20 23:17, Iuri de Araujo Sampaio wrote:
> On May 25, 2020, at 08:55, Gustaf Neumann <ne...@wu... 
> <mailto:ne...@wu...>> wrote:
>>
>> NaviServer has native support for base64 and base64url encoding/decoding
>> See:
>>
>> https://naviserver.sourceforge.io/n/naviserver/files/ns_base64.html
>>
>
> Okay, and what about the wring encrypt, (i.e. within “=“) after the 
> 63rd char?

Iuri,

i think, you have mixed something up, and/or you did not read the man page.
Look into the examplein this page: The "base64url" variant performs no 
padding
with equal signs. If you have the padding, and you do not want it, use 
the right command.

- to use classical base64 encoding (RFC 2045, RFC 4648 sect 4) use,
   ns_base64encode/decode.
. to use the base64 encoding with the filename safe alphabet (RFC 4648 
sect 5) use,
   ns_base64urlencode/decode.

There is now problem with longer strings.

all the best
-gn

[naviserver-devel] Verifying HMAC signature [ns_crypto::hmac ... ]

[<IU...@IU...>]

Hi there,
How can I verify HMAC signatures, using [ns_crypto::hmac ...]?
For example, one has sent an encrypted message:

    set secret_message [ns_crypto::hmac string -digest sha256 "Abracadabra" "What is the magic word?"]

... and another wants to verify integrity and authenticity of that message in the other side


CRYPTO library has crypto::verify, as in  https://clouddocs.f5.com/api/irules/CRYPTO__verify.html <https://clouddocs.f5.com/api/irules/CRYPTO__verify.html>set secret_key "foobar1234" set data "This is my data" set signed_data [CRYPTO::sign -alg hmac-sha1 -key $secret_key $data] if { [CRYPTO::verify -alg hmac-sha1 -key $secret_key -signature $signed_data $data] } { log local0. "Data verified" }

Also, Chilkat example shows more sophisticated approaches to sign and verify. Nothing so complex. It's just using OO writing the code, to make it code readable and intuitive.  https://www.example-code.com/tcl/jws_hmac_sha_256.asp <https://www.example-code.com/tcl/jws_hmac_sha_256.asp>

Thus, I was looking for something similar in the NS Library, such as the method [ns_crypto::md ...], which contains the parameter -verify, but it seems that's not the case of [ns_crypto::hmac ...]. At least it's not in the docs.
https://naviserver.sourceforge.io/n/naviserver/files/ns_crypto.html#8 <https://naviserver.sourceforge.io/n/naviserver/files/ns_crypto.html#8>

How would I verify a message using NS library?

Best wishes,
I

Re: [naviserver-devel] What to do when [ns_base64encode] doesn't encrypt properly after the 63rd char?

[Iuri de A. S. <iu...@iu...>]

> What do you mean its not encoded correctly? 

item (2) is not encoded correctly using base64url (https://tools.ietf.org/html/rfc4648#section-5 <https://tools.ietf.org/html/rfc4648#section-5>). Note that padding ("=") must be omitted as per https://tools.ietf.org/html/rfc7515#section-2 <https://tools.ietf.org/html/rfc7515#section-2>

How would I use [ns_base64encoding], if i decide to add more content in the payload message? Is it possible?





> On May 25, 2020, at 08:55, Gustaf Neumann <ne...@wu...> wrote:
> 
> NaviServer has native support for base64 and base64url encoding/decoding
> See:
> 
>    https://naviserver.sourceforge.io/n/naviserver/files/ns_base64.html <https://naviserver.sourceforge.io/n/naviserver/files/ns_base64.html>
Okay, and what about the wring encrypt, (i.e. within “=“) after the 63rd char?





> On May 24, 2020, at 22:08, Maksym Zinchenko <siq...@gm...> wrote:
> 
> What do you mean its not encoded correctly? 
> 
> ns_base64decode eydpc3MnOiAnMjY5NzM0MTAwMDAxMDInLCAnYXVkJzogJ2l1cml4LmNvbS9SRVNUJywgJ3N1Yic
> 6ICc3MDQnLCAnaWF0JzogMTU5MDM2NTY1MH0=
> {'iss': '26973410000102', 'aud': 'iurix.com/REST <http://iurix.com/REST>', 'sub': '704', 'iat': 1590365650}
> 
> 
> On Sun, May 24, 2020 at 11:56 PM Maksym Zinchenko <siq...@gm... <mailto:siq...@gm...>> wrote:
> sourcecode/nsd/uuencode.c maybe
> 
> On Sun, May 24, 2020 at 11:23 PM Iuri de Araujo Sampaio <iu...@iu... <mailto:iu...@iu...>> wrote:
> Hi there,
> 
> It looks like [ns_base64encode] generates a wrong payload when message size contains more than 63 characters. 
> 
> https://tools.ietf.org/html/rfc4648#section-5 <https://tools.ietf.org/html/rfc4648#section-5>
> An alternative alphabet has been suggested that would use "~" as the
>    63rd character.
> 
> 
> (1) Payload, which generates a proper encryption.   
>   
> set payload [ns_base64encode "{'sub': '$user(user_id)', 'it': [ns_time]}”]
> 
> eydzdWInOiAnNzA0JywgJ2lhdCc6IDE1OTAzNjU2ODF9
> 
> (2) Payload, which generates a wrong encryption 
> 
> set payload [ns_base64encode "{'iss': '26973410000102', 'aud': 'iurix.com/REST <http://iurix.com/REST>', 'sub': '$user(user_id)', 'iat': [ns_time]}”]
>  
> eydpc3MnOiAnMjY5NzM0MTAwMDAxMDInLCAnYXVkJzogJ2l1cml4LmNvbS9SRVNUJywgJ3N1Yic6ICc3MDQnLCAnaWF0JzogMTU5MDM2NTY1MH0=
> 
> 
> item (2) is not encoded correctly using base64url (https://tools.ietf.org/html/rfc4648#section-5 <https://tools.ietf.org/html/rfc4648#section-5>). Note that padding ("=") must be omitted as per https://tools.ietf.org/html/rfc7515#section-2 <https://tools.ietf.org/html/rfc7515#section-2>
> 
> How would I use [ns_base64encoding], if i decide to add more content in the payload message? Is it possible?
> 
>  
> I was trying find where ns_base64encoding is implemented, within Naviserver source code. But I haven’t found yet. 
> Then I’d be able to go deeper into the problem to identify the actual cause and try to write a solution to it. 
> 
> Does anyone know where is the implementation of [ns_base64encode] ?
> 
> Best wishes,
> I 
> _______________________________________________
> naviserver-devel mailing list
> nav...@li... <mailto:nav...@li...>
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel <https://lists.sourceforge.net/lists/listinfo/naviserver-devel>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] Registering/Allowing request method HTTP PUT

[Iuri de A. S. <iu...@iu...>]

Right on! Thanks Gustaf!

The error was in the registration call. I had assigned the virtual OACS url as the path to the file, instead of the physical path. As you brightly described in 
> ns_register_tcl PUT /REST2/ /usr/local/oacs-5-10/openacs-4/www/



and regarding “unfriendly” behavior
> The last request leads to a "method not allowed" result, since a PUT on /shared 
> is indeed not allowed. This is the "unfriendly" behavior part. Clearly, in 
> the file-not-found case, the HTTP method should be changed to GET 
> 
I’ll handle it, using NGINX.

Thanks!



> On May 25, 2020, at 11:24, Gustaf Neumann <ne...@wu...> wrote:
> 
> On 25.05.20 01:17, Maksym Zinchenko wrote:
>> Sorry, actually I don't know about OpenACS, because Im just running NS with custom made app, so I assume it may be an OpenACS question. So I suggest  you to ask on OpenACS forum.
> The problem is here a not really OpenACS, but related to typical OpenACS configurations, 
> together with a somewhat unfriendly behavior of NaviServer (same in AOLserver).
> Consider the following three register commands:
> 
>    ns_register_tcl PUT /REST1/ test.tcl                               ;# /usr/local/oacs-5-10/openacs-4/www/test.tcl   
>    ns_register_tcl PUT /REST2/ /usr/local/oacs-5-10/openacs-4/www/
>    ns_register_tcl PUT /REST3/                                        ;# /www/REST3/test.tcl
> On the right hand side, you see, how the files are actually mapped on my
> instance for requests like:
> 
>    curl -X PUT -d 'hello world' http://localhost:8100/REST3/test.tcl <http://localhost:8100/REST3/test.tcl>
> 
> When these file exist, everything is fine, also with OpenACS installations.
> 
> However, when one points to a non-existing file, and the error 
> page mapping is configured, then the request leads to
> 
>    PageRequest </usr/local/oacs-5-10/openacs-4/www/REST3/test.tcl> FILE NOT FOUND
>    Interal redirect due to error page mapping to PUT /shared/404 
> The last request leads to a "method not allowed" result, since a PUT on /shared 
> is indeed not allowed. This is the "unfriendly" behavior part. Clearly, in 
> the file-not-found case, the HTTP method should be changed to GET 
> (not sure, if this the best for all methods). 
> 
> Not sure, when i can look into this in more details.
> 
> Hope this helps
> 
> -gn
> 
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] Registering/Allowing request method HTTP PUT

[Gustaf N. <ne...@wu...>]

On 25.05.20 01:17, Maksym Zinchenko wrote:
> Sorry, actually I don't know about OpenACS, because Im just running NS 
> with custom made app, so I assume it may be an OpenACS question. So I 
> suggest  you to ask on OpenACS forum.
The problem is here a not really OpenACS, but related to typical OpenACS 
configurations,
together with a somewhat unfriendly behavior of NaviServer (same in 
AOLserver).

Consider the following three register commands:

    ns_register_tcl PUT /REST1/ test.tcl                               ;# /usr/local/oacs-5-10/openacs-4/www/test.tcl
    ns_register_tcl PUT /REST2/ /usr/local/oacs-5-10/openacs-4/www/
    ns_register_tcl PUT /REST3/                                        ;# /www/REST3/test.tcl

On the right hand side, you see, how the files are actually mapped on my
instance for requests like:

    curl -X PUT -d 'hello world' http://localhost:8100/REST3/test.tcl

When these file exist, everything is fine, also with OpenACS installations.

However, when one points to a non-existing file, and the error
page mapping is configured, then the request leads to

    PageRequest </usr/local/oacs-5-10/openacs-4/www/REST3/test.tcl> FILE NOT FOUND
    Interal redirect due to error page mapping to PUT /shared/404

The last request leads to a "method not allowed" result, since a PUT on 
/shared
is indeed not allowed. This is the "unfriendly" behavior part. Clearly, in
the file-not-found case, the HTTP method should be changed to GET
(not sure, if this the best for all methods).

Not sure, when i can look into this in more details.

Hope this helps

-gn

Re: [naviserver-devel] What to do when [ns_base64encode] doesn't encrypt properly after the 63rd char?

[Gustaf N. <ne...@wu...>]

NaviServer has native support for base64 and base64url encoding/decoding
See:

https://naviserver.sourceforge.io/n/naviserver/files/ns_base64.html

-gn
On 25.05.20 03:23, Maksym Zinchenko wrote:
> As I understood, you want to send data to your REST API in url, so you 
> cant use ns_base64encodin.
> Because its base64 not base64url.
> May be some of this will be helpful:
> https://wiki.tcl-lang.org/page/base64
> https://wiki.tcl-lang.org/page/base64url
>
> Chilkat:
> https://www.example-code.com/tcl/base64url_encoding.asp
>
> On Mon, May 25, 2020 at 12:08 AM Maksym Zinchenko <siq...@gm... 
> <mailto:siq...@gm...>> wrote:
>
>     What do you mean its not encoded correctly?
>
>     ns_base64decode
>     eydpc3MnOiAnMjY5NzM0MTAwMDAxMDInLCAnYXVkJzogJ2l1cml4LmNvbS9SRVNUJywgJ3N1Yic
>     6ICc3MDQnLCAnaWF0JzogMTU5MDM2NTY1MH0=
>     {'iss': '26973410000102', 'aud': 'iurix.com/REST
>     <http://iurix.com/REST>', 'sub': '704', 'iat': 1590365650}
>
>
>     On Sun, May 24, 2020 at 11:56 PM Maksym Zinchenko
>     <siq...@gm... <mailto:siq...@gm...>> wrote:
>
>         sourcecode/nsd/uuencode.c maybe
>
>         On Sun, May 24, 2020 at 11:23 PM Iuri de Araujo Sampaio
>         <iu...@iu... <mailto:iu...@iu...>> wrote:
>
>             Hi there,
>
>             It looks like *[ns_base64encode]* generates a wrong
>             payload when message size contains more than 63 characters.
>
>             https://tools.ietf.org/html/rfc4648#section-5
>
>             An alternative alphabet has been suggested that would use "~" as the
>                 63rd character.
>
>
>
>             (1) Payload, which generates a proper encryption.
>             setpayload [ns_base64encode "{'sub': '$user(user_id)',
>             'it': [ns_time]}”]
>
>             eydzdWInOiAnNzA0JywgJ2lhdCc6IDE1OTAzNjU2ODF9
>
>             (2) Payload, which generates a wrong encryption
>
>             setpayload [ns_base64encode "{'iss': '26973410000102',
>             'aud': 'iurix.com/REST <http://iurix.com/REST>', 'sub':
>             '$user(user_id)', 'iat': [ns_time]}”]
>             eydpc3MnOiAnMjY5NzM0MTAwMDAxMDInLCAnYXVkJzogJ2l1cml4LmNvbS9SRVNUJywgJ3N1Yic6ICc3MDQnLCAnaWF0JzogMTU5MDM2NTY1MH0=
>
>
>             item (2) is not encoded correctly using base64url
>             (https://tools.ietf.org/html/rfc4648#section-5). Note that
>             padding ("=") must be omitted as per
>             https://tools.ietf.org/html/rfc7515#section-2
>
>             How would I use [ns_base64encoding], if i decide to add
>             more content in the payload message? Is it possible?
>
>             I was trying find where ns_base64encoding is implemented,
>             within Naviserver source code. But I haven’t found yet.
>             Then I’d be able to go deeper into the problem to identify
>             the actual cause and try to write a solution to it.
>
>             Does anyone know where is the implementation of
>             [ns_base64encode] ?
>
>             Best wishes,
>             I
>

Re: [naviserver-devel] What to do when [ns_base64encode] doesn't encrypt properly after the 63rd char?

[Maksym Z. <siq...@gm...>]

As I understood, you want to send data to your REST API in url, so you cant
use ns_base64encodin.
Because its base64 not base64url.
May be some of this will be helpful:
https://wiki.tcl-lang.org/page/base64
https://wiki.tcl-lang.org/page/base64url

Chilkat:
https://www.example-code.com/tcl/base64url_encoding.asp

On Mon, May 25, 2020 at 12:08 AM Maksym Zinchenko <siq...@gm...>
wrote:

> What do you mean its not encoded correctly?
>
> ns_base64decode
> eydpc3MnOiAnMjY5NzM0MTAwMDAxMDInLCAnYXVkJzogJ2l1cml4LmNvbS9SRVNUJywgJ3N1Yic
> 6ICc3MDQnLCAnaWF0JzogMTU5MDM2NTY1MH0=
> {'iss': '26973410000102', 'aud': 'iurix.com/REST', 'sub': '704', 'iat':
> 1590365650}
>
>
> On Sun, May 24, 2020 at 11:56 PM Maksym Zinchenko <siq...@gm...>
> wrote:
>
>> sourcecode/nsd/uuencode.c maybe
>>
>> On Sun, May 24, 2020 at 11:23 PM Iuri de Araujo Sampaio <iu...@iu...>
>> wrote:
>>
>>> Hi there,
>>>
>>> It looks like *[ns_base64encode]* generates a wrong payload when
>>> message size contains more than 63 characters.
>>>
>>>
>>> https://tools.ietf.org/html/rfc4648#section-5
>>>
>>> An alternative alphabet has been suggested that would use "~" as the
>>>    63rd character.
>>>
>>>
>>>
>>> (1) Payload, which generates a proper encryption.
>>>
>>> set payload [ns_base64encode "{'sub': '$user(user_id)', 'it':
>>> [ns_time]}”]
>>>
>>> eydzdWInOiAnNzA0JywgJ2lhdCc6IDE1OTAzNjU2ODF9
>>>
>>> (2) Payload, which generates a wrong encryption
>>>
>>> set payload [ns_base64encode "{'iss': '26973410000102', 'aud': '
>>> iurix.com/REST', 'sub': '$user(user_id)', 'iat': [ns_time]}”]
>>>
>>> eydpc3MnOiAnMjY5NzM0MTAwMDAxMDInLCAnYXVkJzogJ2l1cml4LmNvbS9S
>>> RVNUJywgJ3N1Yic6ICc3MDQnLCAnaWF0JzogMTU5MDM2NTY1MH0=
>>>
>>>
>>> item (2) is not encoded correctly using base64url (
>>> https://tools.ietf.org/html/rfc4648#section-5). Note that padding ("=")
>>> must be omitted as per https://tools.ietf.org/html/rfc7515#section-2
>>>
>>> How would I use [ns_base64encoding], if i decide to add more content in
>>> the payload message? Is it possible?
>>>
>>>
>>> I was trying find where ns_base64encoding is implemented, within
>>> Naviserver source code. But I haven’t found yet.
>>> Then I’d be able to go deeper into the problem to identify the actual
>>> cause and try to write a solution to it.
>>>
>>> Does anyone know where is the implementation of [ns_base64encode] ?
>>>
>>> Best wishes,
>>> I
>>> _______________________________________________
>>> naviserver-devel mailing list
>>> nav...@li...
>>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>>
>>

Re: [naviserver-devel] What to do when [ns_base64encode] doesn't encrypt properly after the 63rd char?

[Maksym Z. <siq...@gm...>]

What do you mean its not encoded correctly?

ns_base64decode
eydpc3MnOiAnMjY5NzM0MTAwMDAxMDInLCAnYXVkJzogJ2l1cml4LmNvbS9SRVNUJywgJ3N1Yic
6ICc3MDQnLCAnaWF0JzogMTU5MDM2NTY1MH0=
{'iss': '26973410000102', 'aud': 'iurix.com/REST', 'sub': '704', 'iat':
1590365650}


On Sun, May 24, 2020 at 11:56 PM Maksym Zinchenko <siq...@gm...>
wrote:

> sourcecode/nsd/uuencode.c maybe
>
> On Sun, May 24, 2020 at 11:23 PM Iuri de Araujo Sampaio <iu...@iu...>
> wrote:
>
>> Hi there,
>>
>> It looks like *[ns_base64encode]* generates a wrong payload when message
>> size contains more than 63 characters.
>>
>>
>> https://tools.ietf.org/html/rfc4648#section-5
>>
>> An alternative alphabet has been suggested that would use "~" as the
>>    63rd character.
>>
>>
>>
>> (1) Payload, which generates a proper encryption.
>>
>> set payload [ns_base64encode "{'sub': '$user(user_id)', 'it':
>> [ns_time]}”]
>>
>> eydzdWInOiAnNzA0JywgJ2lhdCc6IDE1OTAzNjU2ODF9
>>
>> (2) Payload, which generates a wrong encryption
>>
>> set payload [ns_base64encode "{'iss': '26973410000102', 'aud': '
>> iurix.com/REST', 'sub': '$user(user_id)', 'iat': [ns_time]}”]
>>
>> eydpc3MnOiAnMjY5NzM0MTAwMDAxMDInLCAnYXVkJzogJ2l1cml4LmNvbS9S
>> RVNUJywgJ3N1Yic6ICc3MDQnLCAnaWF0JzogMTU5MDM2NTY1MH0=
>>
>>
>> item (2) is not encoded correctly using base64url (
>> https://tools.ietf.org/html/rfc4648#section-5). Note that padding ("=")
>> must be omitted as per https://tools.ietf.org/html/rfc7515#section-2
>>
>> How would I use [ns_base64encoding], if i decide to add more content in
>> the payload message? Is it possible?
>>
>>
>> I was trying find where ns_base64encoding is implemented, within
>> Naviserver source code. But I haven’t found yet.
>> Then I’d be able to go deeper into the problem to identify the actual
>> cause and try to write a solution to it.
>>
>> Does anyone know where is the implementation of [ns_base64encode] ?
>>
>> Best wishes,
>> I
>> _______________________________________________
>> naviserver-devel mailing list
>> nav...@li...
>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>
>

Re: [naviserver-devel] What to do when [ns_base64encode] doesn't encrypt properly after the 63rd char?

[Maksym Z. <siq...@gm...>]

sourcecode/nsd/uuencode.c maybe

On Sun, May 24, 2020 at 11:23 PM Iuri de Araujo Sampaio <iu...@iu...>
wrote:

> Hi there,
>
> It looks like *[ns_base64encode]* generates a wrong payload when message
> size contains more than 63 characters.
>
>
> https://tools.ietf.org/html/rfc4648#section-5
>
> An alternative alphabet has been suggested that would use "~" as the
>    63rd character.
>
>
>
> (1) Payload, which generates a proper encryption.
>
> set payload [ns_base64encode "{'sub': '$user(user_id)', 'it': [ns_time]}”]
>
> eydzdWInOiAnNzA0JywgJ2lhdCc6IDE1OTAzNjU2ODF9
>
> (2) Payload, which generates a wrong encryption
>
> set payload [ns_base64encode "{'iss': '26973410000102', 'aud': '
> iurix.com/REST', 'sub': '$user(user_id)', 'iat': [ns_time]}”]
>
> eydpc3MnOiAnMjY5NzM0MTAwMDAxMDInLCAnYXVkJzogJ2l1cml4LmNvbS9S
> RVNUJywgJ3N1Yic6ICc3MDQnLCAnaWF0JzogMTU5MDM2NTY1MH0=
>
>
> item (2) is not encoded correctly using base64url (
> https://tools.ietf.org/html/rfc4648#section-5). Note that padding ("=")
> must be omitted as per https://tools.ietf.org/html/rfc7515#section-2
>
> How would I use [ns_base64encoding], if i decide to add more content in
> the payload message? Is it possible?
>
>
> I was trying find where ns_base64encoding is implemented, within
> Naviserver source code. But I haven’t found yet.
> Then I’d be able to go deeper into the problem to identify the actual
> cause and try to write a solution to it.
>
> Does anyone know where is the implementation of [ns_base64encode] ?
>
> Best wishes,
> I
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

[naviserver-devel] What to do when [ns_base64encode] doesn't encrypt properly after the 63rd char?

[Iuri de A. S. <iu...@iu...>]

Hi there,

It looks like [ns_base64encode] generates a wrong payload when message size contains more than 63 characters. 

https://tools.ietf.org/html/rfc4648#section-5 <https://tools.ietf.org/html/rfc4648#section-5>
An alternative alphabet has been suggested that would use "~" as the
   63rd character.


(1) Payload, which generates a proper encryption.   
  
set payload [ns_base64encode "{'sub': '$user(user_id)', 'it': [ns_time]}”]

eydzdWInOiAnNzA0JywgJ2lhdCc6IDE1OTAzNjU2ODF9

(2) Payload, which generates a wrong encryption 

set payload [ns_base64encode "{'iss': '26973410000102', 'aud': 'iurix.com/REST', 'sub': '$user(user_id)', 'iat': [ns_time]}”]
 
eydpc3MnOiAnMjY5NzM0MTAwMDAxMDInLCAnYXVkJzogJ2l1cml4LmNvbS9SRVNUJywgJ3N1Yic6ICc3MDQnLCAnaWF0JzogMTU5MDM2NTY1MH0=


item (2) is not encoded correctly using base64url (https://tools.ietf.org/html/rfc4648#section-5). Note that padding ("=") must be omitted as per https://tools.ietf.org/html/rfc7515#section-2

How would I use [ns_base64encoding], if i decide to add more content in the payload message? Is it possible?

 
I was trying find where ns_base64encoding is implemented, within Naviserver source code. But I haven’t found yet. 
Then I’d be able to go deeper into the problem to identify the actual cause and try to write a solution to it. 

Does anyone know where is the implementation of [ns_base64encode] ?

Best wishes,
I 

Re: [naviserver-devel] Registering/Allowing request method HTTP PUT

[Iuri de A. S. <iu...@iu...>]

Thanks Maksym,
Be sorry for nothing.

At first, I though so too. But then, as the procedure is ns_* , OpenACS framework shouldn't interfere.  It’s just the framework running in the application level, and there should be no intermediary layer in this scenario.

I’m going to wait for more answers in this forum. Then I’ll post there.  
 

> On May 24, 2020, at 20:17, Maksym Zinchenko <siq...@gm...> wrote:
> 
> Sorry, actually I don't know about OpenACS, because Im just running NS with custom made app, so I assume it may be an OpenACS question. So I suggest  you to ask on OpenACS forum.
> 
> On Sun, May 24, 2020 at 9:00 PM Iuri de Araujo Sampaio <iu...@iu... <mailto:iu...@iu...>> wrote:
> Hello there! 
> Thanks Maksym, it’s always good to double check fundamentals. 
>   
> I’ve followed standard’s installation, using install-ns.sh script, available on GitHub. https://github.com/gustafn/install-ns/ <https://github.com/gustafn/install-ns/>
> 
> Plus,  http-handlers-init.tcl loads properly when NS starts. (logs are below)
> 
> My box runs NS and OpenACS on top of it. Nevertheless, I don’t think that would be a problem. 
> 
> You may be right, though. I don’t know.
> 
> Please, see logs bellow.
> 
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading packages/iurix-mail/tcl/iurix-mail-init.tcl...
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded packages/iurix-mail/tcl/iurix-mail-init.tcl.
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading packages/ix-currency/tcl/ix-currency-init.tcl...
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded packages/ix-currency/tcl/ix-currency-init.tcl.
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading packages/ix-restapi/tcl/httphandlers-init.tcl...
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded packages/ix-restapi/tcl/httphandlers-init.tcl.
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading packages/xml-rpc/tcl/system-init.tcl...
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded packages/xml-rpc/tcl/system-init.tcl.
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading packages/xml-rpc/tcl/validator-init.tcl...
> [
> 
> 
> 
> 
> 
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: NaviServer/4.99.18 (tar-4.99.18) starting
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: security info: uid=1002, euid=1002, gid=1002, egid=1002
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: Tcl version: 8.6.9
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: max files: soft limit 524288, hard limit 524288
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Warning: nsmain: rl_cur (524288) > FD_SETSIZE (1024), select() calls should not be used
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: pool default: queueLength 90 low water 9 high water 90
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsd/init.tcl[iurix]: booting virtual server:  Tcl system encoding: "utf-8"
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading module nslog from file /usr/local/ns/bin/nslog.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nslog: opened '/var/www/iurix/log//access.log'
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading module nsdb from file /usr/local/ns/bin/nsdb.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading module ns/db/driver/postgres from file /usr/local/ns/bin/nsdbpg.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsdbpg: version 2.3 loaded, based on PostgreSQL 9.6.15 and libbpq 90617
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: dbinit: set LogMinDuration for pool pool1 over 0.01 to 0.010000
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: dbinit: set LogMinDuration for pool pool2 over 0.01 to 0.010000
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading module nsproxy from file /usr/local/ns/bin/nsproxy.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading module nssock_v4 from file /usr/local/ns/bin/nssock.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nssock_v4:0: enable 0 spooler thread(s) 
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nssock_v4:0: enable 2 writer thread(s) for downloads >= 1024 bytes, bufsize=8192 bytes, HTML streaming 0
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading module nsssl_v4 from file /usr/local/ns/bin/nsssl.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl_v4:0: enable 0 spooler thread(s) 
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl_v4:0: enable 2 writer thread(s) for downloads >= 1024 bytes, bufsize=16384 bytes, HTML streaming 0
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: OpenSSL OpenSSL 1.1.0l  10 Sep 2019 initialized
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl: disabling SSLv2
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl: version 2.1 loaded, based on OpenSSL 1.1.0l  10 Sep 2019
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading module libthread from file /usr/local/ns/lib/thread2.8.2/libthread2.8.2.so <http://libthread2.8.2.so/>
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nx::serializer version 2.3
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: XOTcl 2.3 loaded featuring: memcount 0 profile 0 memtrace 0 assertions 1 dtrace 0 development 0
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Using ns_cache based on NX 2.3
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: adp[iurix]: mapped {GET HEAD POST} /*.adp
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Loading OpenACS, rooted at /var/www/iurix
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Sourcing /var/www/iurix/packages/acs-bootstrap-installer/bootstrap.tcl
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: bootstrap begin encoding utf-8
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Bootstrap: sourcing /var/www/iurix/packages/acs-bootstrap-installer/tcl/00-proc-procs.tcl
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Bootstrap: sourcing /var/www/iurix/packages/acs-bootstrap-installer/tcl/10-utilities-procs.tcl
> [24/
> 
> 
> 
>> On May 24, 2020, at 14:23, Maksym Zinchenko <siq...@gm... <mailto:siq...@gm...>> wrote:
>> 
>> Hello, Ive tested ns_register_tcl with my installation and its working fine:
>> In my index.adp:
>> ns_register_tcl PUT /REST/ test/test.tcl
>> 
>> My test.tcl:
>> ns_log Notice "Running TCL script users/edit"
>> 
>> In log:
>>  [0;32m[24/May/2020:16:16:47][26138.7f62510c4700][-conn:***********:default:0:12-]  [0m [0;39mNotice: Running TCL script users/edit [0m
>> 
>> Check your logs if naviserver reads /tcl/http-handlers-init.tcl. Your path to scripts etc. Its something with your installation
>> Cmpts.: Maksym Zinchenko
>> 
>> On Sat, May 23, 2020 at 7:22 PM <iu...@iu... <mailto:iu...@iu...>> wrote:
>> Hi there,
>> In attempt to register PUT in my NS instalation  ( ie. HTTP PUT method), I added the following line, within  /tcl/http-handlers-init.tcl library :
>> 
>> ns_register_tcl -options {stream stricterror} -- PUT /REST/*.tcl
>> 
>> I also try the simplest call:  ns_register_tcl PUT /REST/*.tcl
>> 
>> Then, within /REST/ directory, there's a TCL script edit.tclm and the first line is a simple log call, for testing purposes.
>> 
>> ns_log Notice "Running TCL script users/edit"
>> 
>> However, it still returns "Method not allowed:
>> 
>> Reference: https://naviserver.sourceforge.io/n/naviserver/files/ns_register.html <https://naviserver.sourceforge.io/n/naviserver/files/ns_register.html>
>> 
>> 
>> Furthermore, I've tested another variation of ns_register, which works just fine
>> 
>> ns_register_proc PUT /REST/* ::my_proc
>> 
>> What am I missing ?
>> 
>> 
>> Best wishes,
>> I
>> _______________________________________________
>> naviserver-devel mailing list
>> nav...@li... <mailto:nav...@li...>
>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel <https://lists.sourceforge.net/lists/listinfo/naviserver-devel>
>> _______________________________________________
>> naviserver-devel mailing list
>> nav...@li... <mailto:nav...@li...>
>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel <https://lists.sourceforge.net/lists/listinfo/naviserver-devel>
> 
> _______________________________________________
> naviserver-devel mailing list
> nav...@li... <mailto:nav...@li...>
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel <https://lists.sourceforge.net/lists/listinfo/naviserver-devel>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] Registering/Allowing request method HTTP PUT

[Maksym Z. <siq...@gm...>]

Sorry, actually I don't know about OpenACS, because Im just running NS with
custom made app, so I assume it may be an OpenACS question. So I suggest
you to ask on OpenACS forum.

On Sun, May 24, 2020 at 9:00 PM Iuri de Araujo Sampaio <iu...@iu...>
wrote:

> Hello there!
> Thanks Maksym, it’s always good to double check fundamentals.
>
> I’ve followed standard’s installation, using install-ns.sh script,
> available on GitHub. https://github.com/gustafn/install-ns/
>
> Plus,  http-handlers-init.tcl loads properly when NS starts. (logs are
> below)
>
> My box runs NS and OpenACS on top of it. Nevertheless, I don’t think that
> would be a problem.
>
> You may be right, though. I don’t know.
>
> Please, see logs bellow.
>
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading
> packages/iurix-mail/tcl/iurix-mail-init.tcl...
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded
> packages/iurix-mail/tcl/iurix-mail-init.tcl.
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading
> packages/ix-currency/tcl/ix-currency-init.tcl...
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded
> packages/ix-currency/tcl/ix-currency-init.tcl.
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading
> packages/ix-restapi/tcl/httphandlers-init.tcl...
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded
> packages/ix-restapi/tcl/httphandlers-init.tcl.
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading
> packages/xml-rpc/tcl/system-init.tcl...
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded
> packages/xml-rpc/tcl/system-init.tcl.
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading
> packages/xml-rpc/tcl/validator-init.tcl...
> [
>
>
>
>
>
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain:
> NaviServer/4.99.18 (tar-4.99.18) starting
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain:
> security info: uid=1002, euid=1002, gid=1002, egid=1002
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: Tcl
> version: 8.6.9
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: max
> files: soft limit 524288, hard limit 524288
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] *Warning: nsmain:
> rl_cur (524288) > FD_SETSIZE (1024), select() calls should not be used*
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: pool default:
> queueLength 90 low water 9 high water 90
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice:
> nsd/init.tcl[iurix]: booting virtual server:  Tcl system encoding: "utf-8"
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload:
> loading module nslog from file /usr/local/ns/bin/nslog.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nslog: opened
> '/var/www/iurix/log//access.log'
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload:
> loading module nsdb from file /usr/local/ns/bin/nsdb.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload:
> loading module ns/db/driver/postgres from file /usr/local/ns/bin/nsdbpg.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsdbpg:
> version 2.3 loaded, based on PostgreSQL 9.6.15 and libbpq 90617
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: dbinit: set
> LogMinDuration for pool pool1 over 0.01 to 0.010000
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: dbinit: set
> LogMinDuration for pool pool2 over 0.01 to 0.010000
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload:
> loading module nsproxy from file /usr/local/ns/bin/nsproxy.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload:
> loading module nssock_v4 from file /usr/local/ns/bin/nssock.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nssock_v4:0:
> enable 0 spooler thread(s)
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nssock_v4:0:
> enable 2 writer thread(s) for downloads >= 1024 bytes, bufsize=8192 bytes,
> HTML streaming 0
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload:
> loading module nsssl_v4 from file /usr/local/ns/bin/nsssl.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl_v4:0:
> enable 0 spooler thread(s)
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl_v4:0:
> enable 2 writer thread(s) for downloads >= 1024 bytes, bufsize=16384 bytes,
> HTML streaming 0
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: OpenSSL
> OpenSSL 1.1.0l  10 Sep 2019 initialized
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl:
> disabling SSLv2
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl: version
> 2.1 loaded, based on OpenSSL 1.1.0l  10 Sep 2019
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload:
> loading module libthread from file /usr/local/ns/lib/thread2.8.2/
> libthread2.8.2.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nx::serializer
> version 2.3
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: XOTcl 2.3
> loaded featuring: memcount 0 profile 0 memtrace 0 assertions 1 dtrace 0
> development 0
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Using ns_cache
> based on NX 2.3
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: adp[iurix]:
> mapped {GET HEAD POST} /*.adp
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Loading
> OpenACS, rooted at /var/www/iurix
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Sourcing
> /var/www/iurix/packages/acs-bootstrap-installer/bootstrap.tcl
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: bootstrap
> begin encoding utf-8
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Bootstrap:
> sourcing
> /var/www/iurix/packages/acs-bootstrap-installer/tcl/00-proc-procs.tcl
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Bootstrap:
> sourcing
> /var/www/iurix/packages/acs-bootstrap-installer/tcl/10-utilities-procs.tcl
> [24/
>
>
>
> On May 24, 2020, at 14:23, Maksym Zinchenko <siq...@gm...> wrote:
>
> Hello, Ive tested ns_register_tcl with my installation and its working
> fine:
> In my index.adp:
> ns_register_tcl PUT /REST/ test/test.tcl
>
> My test.tcl:
> ns_log Notice "Running TCL script users/edit"
>
> In log:
>
>  [0;32m[24/May/2020:16:16:47][26138.7f62510c4700][-conn:***********:default:0:12-]  [0m [0;39mNotice: Running TCL script users/edit [0m
>
> Check your logs if naviserver reads /tcl/http-handlers-init.tcl. Your path to scripts etc. Its something with your installation
> Cmpts.: Maksym Zinchenko
>
>
> On Sat, May 23, 2020 at 7:22 PM <iu...@iu...> wrote:
>
>> Hi there,
>> In attempt to register PUT in my NS instalation  ( ie. HTTP PUT method),
>> I added the following line, within  /tcl/http-handlers-init.tcl library :
>>
>> ns_register_tcl -options {stream stricterror} -- PUT /REST/*.tcl
>>
>> I also try the simplest call:  ns_register_tcl PUT /REST/*.tcl
>>
>> Then, within /REST/ directory, there's a TCL script edit.tclm and the
>> first line is a simple log call, for testing purposes.
>>
>> ns_log Notice "Running TCL script users/edit"
>>
>> However, it still returns "Method not allowed:
>>
>> Reference:
>> https://naviserver.sourceforge.io/n/naviserver/files/ns_register.html
>>
>>
>> Furthermore, I've tested another variation of ns_register, which works
>> just fine
>>
>> ns_register_proc PUT /REST/* ::my_proc
>>
>> What am I missing ?
>>
>>
>> Best wishes,
>> I
>> _______________________________________________
>> naviserver-devel mailing list
>> nav...@li...
>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] Registering/Allowing request method HTTP PUT

[Iuri de A. S. <iu...@iu...>]

Hello there! 
Thanks Maksym, it’s always good to double check fundamentals. 
  
I’ve followed standard’s installation, using install-ns.sh script, available on GitHub. https://github.com/gustafn/install-ns/ <https://github.com/gustafn/install-ns/>

Plus,  http-handlers-init.tcl loads properly when NS starts. (logs are below)

My box runs NS and OpenACS on top of it. Nevertheless, I don’t think that would be a problem. 

You may be right, though. I don’t know.

Please, see logs bellow.

[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading packages/iurix-mail/tcl/iurix-mail-init.tcl...
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded packages/iurix-mail/tcl/iurix-mail-init.tcl.
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading packages/ix-currency/tcl/ix-currency-init.tcl...
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded packages/ix-currency/tcl/ix-currency-init.tcl.
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading packages/ix-restapi/tcl/httphandlers-init.tcl...
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded packages/ix-restapi/tcl/httphandlers-init.tcl.
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading packages/xml-rpc/tcl/system-init.tcl...
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded packages/xml-rpc/tcl/system-init.tcl.
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading packages/xml-rpc/tcl/validator-init.tcl...
[





[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: NaviServer/4.99.18 (tar-4.99.18) starting
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: security info: uid=1002, euid=1002, gid=1002, egid=1002
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: Tcl version: 8.6.9
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: max files: soft limit 524288, hard limit 524288
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Warning: nsmain: rl_cur (524288) > FD_SETSIZE (1024), select() calls should not be used
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: pool default: queueLength 90 low water 9 high water 90
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsd/init.tcl[iurix]: booting virtual server:  Tcl system encoding: "utf-8"
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading module nslog from file /usr/local/ns/bin/nslog.so
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nslog: opened '/var/www/iurix/log//access.log'
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading module nsdb from file /usr/local/ns/bin/nsdb.so
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading module ns/db/driver/postgres from file /usr/local/ns/bin/nsdbpg.so
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsdbpg: version 2.3 loaded, based on PostgreSQL 9.6.15 and libbpq 90617
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: dbinit: set LogMinDuration for pool pool1 over 0.01 to 0.010000
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: dbinit: set LogMinDuration for pool pool2 over 0.01 to 0.010000
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading module nsproxy from file /usr/local/ns/bin/nsproxy.so
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading module nssock_v4 from file /usr/local/ns/bin/nssock.so
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nssock_v4:0: enable 0 spooler thread(s) 
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nssock_v4:0: enable 2 writer thread(s) for downloads >= 1024 bytes, bufsize=8192 bytes, HTML streaming 0
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading module nsssl_v4 from file /usr/local/ns/bin/nsssl.so
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl_v4:0: enable 0 spooler thread(s) 
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl_v4:0: enable 2 writer thread(s) for downloads >= 1024 bytes, bufsize=16384 bytes, HTML streaming 0
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: OpenSSL OpenSSL 1.1.0l  10 Sep 2019 initialized
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl: disabling SSLv2
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl: version 2.1 loaded, based on OpenSSL 1.1.0l  10 Sep 2019
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading module libthread from file /usr/local/ns/lib/thread2.8.2/libthread2.8.2.so
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nx::serializer version 2.3
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: XOTcl 2.3 loaded featuring: memcount 0 profile 0 memtrace 0 assertions 1 dtrace 0 development 0
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Using ns_cache based on NX 2.3
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: adp[iurix]: mapped {GET HEAD POST} /*.adp
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Loading OpenACS, rooted at /var/www/iurix
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Sourcing /var/www/iurix/packages/acs-bootstrap-installer/bootstrap.tcl
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: bootstrap begin encoding utf-8
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Bootstrap: sourcing /var/www/iurix/packages/acs-bootstrap-installer/tcl/00-proc-procs.tcl
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Bootstrap: sourcing /var/www/iurix/packages/acs-bootstrap-installer/tcl/10-utilities-procs.tcl
[24/



> On May 24, 2020, at 14:23, Maksym Zinchenko <siq...@gm...> wrote:
> 
> Hello, Ive tested ns_register_tcl with my installation and its working fine:
> In my index.adp:
> ns_register_tcl PUT /REST/ test/test.tcl
> 
> My test.tcl:
> ns_log Notice "Running TCL script users/edit"
> 
> In log:
>  [0;32m[24/May/2020:16:16:47][26138.7f62510c4700][-conn:***********:default:0:12-]  [0m [0;39mNotice: Running TCL script users/edit [0m
> 
> Check your logs if naviserver reads /tcl/http-handlers-init.tcl. Your path to scripts etc. Its something with your installation
> Cmpts.: Maksym Zinchenko
> 
> On Sat, May 23, 2020 at 7:22 PM <iu...@iu... <mailto:iu...@iu...>> wrote:
> Hi there,
> In attempt to register PUT in my NS instalation  ( ie. HTTP PUT method), I added the following line, within  /tcl/http-handlers-init.tcl library :
> 
> ns_register_tcl -options {stream stricterror} -- PUT /REST/*.tcl
> 
> I also try the simplest call:  ns_register_tcl PUT /REST/*.tcl
> 
> Then, within /REST/ directory, there's a TCL script edit.tclm and the first line is a simple log call, for testing purposes.
> 
> ns_log Notice "Running TCL script users/edit"
> 
> However, it still returns "Method not allowed:
> 
> Reference: https://naviserver.sourceforge.io/n/naviserver/files/ns_register.html <https://naviserver.sourceforge.io/n/naviserver/files/ns_register.html>
> 
> 
> Furthermore, I've tested another variation of ns_register, which works just fine
> 
> ns_register_proc PUT /REST/* ::my_proc
> 
> What am I missing ?
> 
> 
> Best wishes,
> I
> _______________________________________________
> naviserver-devel mailing list
> nav...@li... <mailto:nav...@li...>
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel <https://lists.sourceforge.net/lists/listinfo/naviserver-devel>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] Registering/Allowing request method HTTP PUT

[Maksym Z. <siq...@gm...>]

Hello, Ive tested ns_register_tcl with my installation and its working fine:
In my index.adp:
ns_register_tcl PUT /REST/ test/test.tcl

My test.tcl:
ns_log Notice "Running TCL script users/edit"

In log:

 [0;32m[24/May/2020:16:16:47][26138.7f62510c4700][-conn:***********:default:0:12-]
 [0m [0;39mNotice: Running TCL script users/edit [0m

Check your logs if naviserver reads /tcl/http-handlers-init.tcl. Your
path to scripts etc. Its something with your installation
Cmpts.: Maksym Zinchenko


On Sat, May 23, 2020 at 7:22 PM <iu...@iu...> wrote:

> Hi there,
> In attempt to register PUT in my NS instalation  ( ie. HTTP PUT method), I
> added the following line, within  /tcl/http-handlers-init.tcl library :
>
> ns_register_tcl -options {stream stricterror} -- PUT /REST/*.tcl
>
> I also try the simplest call:  ns_register_tcl PUT /REST/*.tcl
>
> Then, within /REST/ directory, there's a TCL script edit.tclm and the
> first line is a simple log call, for testing purposes.
>
> ns_log Notice "Running TCL script users/edit"
>
> However, it still returns "Method not allowed:
>
> Reference:
> https://naviserver.sourceforge.io/n/naviserver/files/ns_register.html
>
>
> Furthermore, I've tested another variation of ns_register, which works
> just fine
>
> ns_register_proc PUT /REST/* ::my_proc
>
> What am I missing ?
>
>
> Best wishes,
> I
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

[naviserver-devel] Verifying HMAC signature [ns_crypto::hmac ... ]

[<iu...@iu...>]

<html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;"><span style="font-family:Verdana; color:#000000; font-size:10pt;"><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;">Hi there,</div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;">How can I verify HMAC signatures, using <span mce_name="strong" mce_style="font-weight: bold;" style="font-weight: bold;" class="Apple-style-span" mce_fixed="1">[ns_crypto::hmac ...]</span>?</div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;">For example, one has sent an encrypted message:</div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><br></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><span style="font-size: 10pt;" mce_style="font-size: 10pt;">&nbsp;&nbsp;&nbsp;&nbsp;set secret_message [ns_crypto::hmac string -digest sha256 "Abracadabra" "What is the magic word?"]</span></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><br></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;">... and another wants to verify integrity and authenticity of that message in the other side</div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><br></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><br></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;">CRYPTO library has crypto::verify, as in&nbsp;&nbsp;<a target="_blank" href="https://clouddocs.f5.com/api/irules/CRYPTO__verify.html" style="">https://clouddocs.f5.com/api/irules/CRYPTO__verify.html</a></div><divre id="codecell1" style=""><span class="k" style="">set</span> secret_key <span class="s2" style="">"foobar1234"</span> <span class="k" style="">set</span> data <span class="s2" style="">"This is my data"</span> <span class="k" style="">set</span> signed_data <span class="k" style="">[</span><span class="nv" style="">CRYPTO</span><span class="o" style="">::</span>sign <span class="o" style="">-</span>alg hmac-sha1 <span class="o" style="">-</span>key <span class="nv" style="">$secret_key</span> <span class="nv" style="">$data</span><span class="k" style="">]</span> <span class="k" style="">if</span> <span class="k" style="">{</span> <span class="k" style="">[</span><span class="nv" style="">CRYPTO</span><span class="o" style="">::</span>verify <span class="o" style="">-</span>alg hmac-sha1 <span class="o" style="">-</span>key <span class="nv" style="">$secret_key</span> <span class="o" style="">-</span>signature <span class="nv" style="">$signed_data</span> <span class="nv" style="">$data</span><span class="k" style="">]</span> <span class="k" style="">}</span> <span class="k" style="">{</span> <span class="nv" style="">log</span> local0. <span class="s2" style="">"Data verified"</span> <span class="k" style="">}</span><divre id="codecell1" style=""><br></pre><pre id="codecell1" style=""><span class="k" style=""><br></span></pre><p style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;">Also, Chilkat example shows more sophisticated approaches to sign and verify.&nbsp;<span style="font-size: 10pt;">Nothing so complex. It's just using OO writing the code, to make it code readable and intuitive.&nbsp;</span><span style="">&nbsp;</span><a target="_blank" href="https://www.example-code.com/tcl/jws_hmac_sha_256.asp" style="">https://www.example-code.com/tcl/jws_hmac_sha_256.asp</a></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><br></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><font face="verdana, geneva" style="">Thus, I was looking for something similar in the NS Library, such as the method <b>[</b></font><b>ns_crypto::md ...]</b>,&nbsp;which contains the parameter <span mce_name="strong" mce_style="font-weight: bold;" class="Apple-style-span" mce_fixed="1" style=""><b>-verify</b></span>, but it seems that's not the case of&nbsp;<span mce_name="strong" mce_style="font-weight: bold;" class="Apple-style-span" mce_fixed="1" style=""><b>[ns_crypto::hmac ...]</b></span>. At least it's not in the docs.</div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><a target="_blank" href="https://naviserver.sourceforge.io/n/naviserver/files/ns_crypto.html#8" mce_href="https://naviserver.sourceforge.io/n/naviserver/files/ns_crypto.html#8" style="">https://naviserver.sourceforge.io/n/naviserver/files/ns_crypto.html#8</a></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><br></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;">How would I verify a message using NS library?</div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><br></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;">Best wishes,</div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;">I</div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><br></div></divre></span> </span></body></html>

[naviserver-devel] Registering/Allowing request method HTTP PUT

[<iu...@iu...>]

<html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;"><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;">Hi there,</div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;">In attempt to register PUT in my NS instalation&nbsp; ( ie. HTTP PUT method), I added the following line, within&nbsp; /tcl/http-handlers-init.tcl library :</div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><br></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><span style="font-size: 9pt;" mce_style="font-size: 9pt;">ns_register_tcl -options {stream stricterror} -- PUT /REST/*.tcl</span></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><span style="font-size: 9pt;" mce_style="font-size: 9pt;"><br></span></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><span style="font-size: 9pt;" mce_style="font-size: 9pt;">I also try the simplest call:&nbsp;&nbsp;</span><span style="">ns_register_tcl PUT /REST/*.tcl</span></div><div style=""><br></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><span style="font-size: 9pt;" mce_style="font-size: 9pt;">Then, within /REST/ directory, there's a TCL script edit.tclm and the first line is a simple log call, for testing purposes.</span></div><div style=""><br></div><div style=""><font face="verdana, geneva" style="">ns_log Notice "Running TCL script users/edit"</font></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><span style="font-size: 9pt;" mce_style="font-size: 9pt;"><br></span></div><div style="color: rgb(0, 0, 0); font-family: verdana, geneva; font-size: 10pt;" mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;"><span style="font-size: 9pt;" mce_style="font-size: 9pt;">However, it still returns "Method not allowed:</span></div><div mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;" style=""><span mce_style="font-size: 9pt;" style=""><br></span></div><div mce_style="color: #000000; font-family: verdana, geneva; font-size: 10pt;" style=""><span mce_style="font-size: 9pt;" style="">Reference:&nbsp;</span><a href="https://naviserver.sourceforge.io/n/naviserver/files/ns_register.html" mce_href="https://naviserver.sourceforge.io/n/naviserver/files/ns_register.html" style="">https://naviserver.sourceforge.io/n/naviserver/files/ns_register.html</a></div><div style=""><br style=""></div><div style=""><font face="verdana, geneva" style=""><span style=""><br></span></font></div><div style=""><font face="verdana, geneva" style=""><span style="">Furthermore, I've tested another variation of ns_register, which works just fine</span></font></div><div style=""><font face="verdana, geneva" style=""><span style=""><br></span></font></div><div style=""><font face="verdana, geneva" style=""><span style="">ns_register_proc PUT /REST/* ::my_proc</span></font></div><div style=""><font face="verdana, geneva" style=""><span style=""><br></span></font></div><div style=""><font face="verdana, geneva">What am I missing ?</font></div><div style=""><font face="verdana, geneva"><br></font></div><div style=""><br></div><div style=""><font face="verdana, geneva" style=""><span style="">Best wishes,</span></font></div><div style=""><font face="verdana, geneva" style=""><span style="">I</span></font></div></span></body></html>

Re: [naviserver-devel] scheduler thread getting stuck

[Gustaf N. <ne...@wu...>]

On 15.05.20 09:21, Andrew Piskorski wrote:
> Recently I started seeing some weird behavior from NaviServer that
> I've never seen before.  From time to time, it looks like the
> scheduler thread is getting stuck and not running anything, often for
> hours at a time.  Then, on rare occasions, it will inexplicably come
> unstuck and go back to normal.
With what exact version happens this?
does the regression test run ok?
> So far I've ONLY seen this strange behavior on Windows 7, where I
> recently upgraded to newer NaviServer code and a newer Microsoft 2019
> Visual Studio Community Edition compiler.  I suspect the problem
> doesn't happen on Linux at all, but I haven't checked for that
> thoroughly.
This is the first report of this kind. My suspicion is as well
that it has to do with Windows and the used compiler mix.
> Previously on Windows I was running NaviServer code from
> c. 2019-07 and an ancient Microsoft compiler from 2010; the problem
> did NOT happen then.
Can you try with the released version 4.99.17 ( 2018-11-04)
with your new Windows environment?

-gn

[naviserver-devel] scheduler thread getting stuck

[Andrew P. <at...@pi...>]

Recently I started seeing some weird behavior from NaviServer that
I've never seen before.  From time to time, it looks like the
scheduler thread is getting stuck and not running anything, often for
hours at a time.  Then, on rare occasions, it will inexplicably come
unstuck and go back to normal.

I never see any "scheduled proc took too long" sorts of warnings in
the log, so I don't THINK I'm running Tcl code that's tying up the
scheduler thread.  So far it seems more like the scheduler itself
silently just does nothing.

Interestingly, when the scheduler comes unstuck, any "missed"
ns_schedule_daily jobs suddenly run all at once, in one second!  In my
case that includes the ns_logroll I schedule daily at 23:59.  Just
yesterday I saw it finally come unstuck and roll the serer log at
16:45 the next day!

So far I've ONLY seen this strange behavior on Windows 7, where I
recently upgraded to newer NaviServer code and a newer Microsoft 2019
Visual Studio Community Edition compiler.  I suspect the problem
doesn't happen on Linux at all, but I haven't checked for that
thoroughly.  Previously on Windows I was running NaviServer code from
c. 2019-07 and an ancient Microsoft compiler from 2010; the problem
did NOT happen then.

Do you have any advice on how I should go about trying to debug this?
E.g., are there commands I should run to check exactly what the
scheduler thread is doing at any given time?  I've started reading
"nsd/tclsched.c" and "nsd/sched.c", but I've never looked at this code
before and have no idea what might be wrong.

Btw, the sched.c source says it's based on the 1988 paper below, but
just how useful is it for understanding things?  Those old conference
proceedings seem hard to find outside of university libraries.  The
USENIX website itself says they only have content back to 1993!

(Thanks for any help and advice!)


https://www.usenix.org/legacy/publications/bibliography/byAuthor.html

Author: Ronald E. Barkley
Author: T. Paul Lee
Title: A Heap-based Callout Implementation to Meet Real-Time Needs
Pages: 213-222
Publisher: USENIX
Proceedings: USENIX Conference Proceedings
Date: Summer 1988
Location: San Francisco
Institution: AT&T Information Systems

The table of contents (nothing else) is online here:

  http://www.gbv.de/dms/tib-ub-hannover/303823399.pdf

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] File compress larger within naviserver then standalone

[Gustaf N. <ne...@wu...>]

Dear Fox,

There is absolutely no reason why the Tcl-builtin zlib function
returns different sizes in tclsh or NaviServer. I could not
reproduce any differences in these two environments.

(i modified you script slightly, and made sure, that the
resulting compressed files is (a) binary and (b) does
not contain a newline at the end of the file).

all are the same for


=====================================
set inFile "/tmp/myImage.png"
set outFile "/tmp/myImage.png.ixz"

set myFile [open $inFile RDONLY]
fconfigure $myFile -translation binary
set content [read $myFile]
close $myFile

set binData [encoding convertto utf-8 $content]
set hexData [binary encode hex [encoding convertto utf-8 $content]]

# level 0 => 2.56 MB
# level 6 => 1.13 MB
# level not specified 1.13 MB
# level 9 => 1.11 MB

set fp [open $outFile w]
fconfigure $fp -translation binary
puts -nonewline $fp [zlib compress $hexData]
close $fp

puts [subst {
     /tmp/myImage.png:    [clock format [file mtime /tmp/myImage.png]] [file size /tmp/myImage.png]
     /tmp/myImage.png.ixz [clock format [file mtime /tmp/myImage.png.ixz]] [file size /tmp/myImage.png.ixz]
}]
=====================================

On 10.05.20 15:59, D.Fox wrote:
> Hi, I am trying to compress a image (.png) using hexadecimal and ZLIB.
> When running the below code within naviserver the created file is 
> larger then if I run standalone shell.
>
> The sample code is as follows:
> #########
> set file "/bench/myImage.png"
> set filePath "/bench/"
>
> set myFile [open $file RDONLY]
> fconfigure $ myFile -translation binary
> set content [read $myFile]
> set binData [encoding convertto utf-8 $content]
> set hexData [binary encode hex [encoding convertto utf-8 $content]]
> close $myFile
>
> set fp [open "$filePath/myCompressedHexBlobFile.ixz" w]
> puts $fp [zlib compress $hexData]
> close $fp
> #########
> Outputs:
> 846K - myImage.png
> 1.7M - myCompressedHexBlobFile.ixz - Executed within Naviserver
> 1.1M - myCompressedHexBlobFile.ixz - Executed from shell with TCLSH
> #########
> Is Navi using a different zlib compression level, why is this happening?
> If I set the compression level to nine, the created file is still at 
> 1.7mb. This is kind of a game changer, even if I source the 
> compression script the file size is still larger then if I run it via 
> terminal.
>
> Thanks
> Fox
>
>
>
>
>
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] File compress larger within naviserver then standalone

[D.Fox <un...@cr...>]

I am now getting correct results so it may of been what you suspected. 

Via Naviserver 
/tmp/myImage.png: Sat May 09 11:59:29 BST 2020 865982 
/tmp/myImage.png.ixz Mon May 11 09:44:41 BST 2020 1159064 

Via tclsh 
/tmp/myImage.png: Sat May 09 11:59:29 BST 2020 865982 
/tmp/myImage.png.ixz Mon May 11 09:46:33 BST 2020 1159064 

Thank you for the second pair of eyes, really appreciated. 
Fox 


From: "Gustaf Neumann" <ne...@wu...> 
To: "naviserver-devel" <nav...@li...> 
Sent: Monday, May 11, 2020 9:25:32 AM 
Subject: Re: [naviserver-devel] File compress larger within naviserver then standalone 



Dear Fox, 

There is absolutely no reason that the Tcl-builtin function zlib 
returns different results in tclsh and naviserver. I could 
not reproduce different results in these two environments, 
also when modifying the compression level (see comments below). 


I slightly modified your script my making sure that the resulting 
file is binary and contains no extra newline at the end. 

While correcting this, i noticed that the size of the file 
differed in the range as you reported when writing the 
file binary or not (as in your case). So, my suspicion 
is that you compared the result of binary result writing 
in tclsh with non-binary result writing in NaviServer. 


Can you report the different results with the modified script? 
-g 
==================================
set inFile "/tmp/myImage.png"
set outFile "/tmp/myImage.png.ixz"

set myFile [open $inFile RDONLY]
fconfigure $myFile -translation binary
set content [read $myFile]
close $myFile

set binData [encoding convertto utf-8 $content]
set hexData [binary encode hex [encoding convertto utf-8 $content]]

# level 0 => 2.56 MB
# level 6 => 1.13 MB
# level not specified 1.13 MB
# level 9 => 1.11 MB

set fp [open $outFile w]
fconfigure $fp -translation binary
puts -nonewline $fp [zlib compress $hexData]
close $fp

puts stderr [subst {
    /tmp/myImage.png:    [clock format [file mtime /tmp/myImage.png]] [file size /tmp/myImage.png]
    /tmp/myImage.png.ixz [clock format [file mtime /tmp/myImage.png.ixz]] [file size /tmp/myImage.png.ixz]
}] 
On 10.05.20 15:59, D.Fox wrote: 





Hi, I am trying to compress a image (.png) using hexadecimal and ZLIB. 
When running the below code within naviserver the created file is larger then if I run standalone shell. 

The sample code is as follows: 
######### 
set file "/bench/myImage.png" 
set filePath "/bench/" 

set myFile [open $file RDONLY] 
fconfigure $ myFile -translation binary 
set content [read $myFile] 
set binData [encoding convertto utf-8 $content] 
set hexData [binary encode hex [encoding convertto utf-8 $content]] 
close $myFile 

set fp [open "$filePath/myCompressedHexBlobFile.ixz" w] 
puts $fp [zlib compress $hexData] 
close $fp 
######### 
Outputs: 
846K - myImage.png 
1.7M - myCompressedHexBlobFile.ixz - Executed within Naviserver 
1.1M - myCompressedHexBlobFile.ixz - Executed from shell with TCLSH 
######### 
Is Navi using a different zlib compression level, why is this happening? 
If I set the compression level to nine, the created file is still at 1.7mb. This is kind of a game changer, even if I source the compression script the file size is still larger then if I run it via terminal. 

Thanks 
Fox 






_______________________________________________
naviserver-devel mailing list [ mailto:nav...@li... | nav...@li... ] [ https://lists.sourceforge.net/lists/listinfo/naviserver-devel | https://lists.sourceforge.net/lists/listinfo/naviserver-devel ] 


_______________________________________________ 
naviserver-devel mailing list 
nav...@li... 
https://lists.sourceforge.net/lists/listinfo/naviserver-devel