Forum OpenACS Q&A: Error: Filter sec_read_security_info returned error #1: can't read "val": no such variable

I'm sure it's because I was feeling self-satisfied about my
progress...

I wrestled the installation demons to the ground, installation was
semi-complete, and I was concentrating on adding content.  Numerous
restarts of AolServer were performed without incident to change
various parameters.

Off to lunch, but upon my return, there was no response from
AolServer.  I'm listening on port 80, but somehow the security filter
is not loading properly, disallowing any response to requests for a
session.

Emailed error is per the title:

Error: Filter sec_read_security_info returned error #1: can't
read "val": no such variable

Logged error is:

[20/Aug/2000:05:59:38][27620.4101][-conn0-] Error: nsd.tcl: Invalid
return code from filter proc: Critical filter sec_read_security
_info failed. (must be filter_ok, filter_return, or filter_break)

I'll keep hunting, but assistance would be appreciated.

Addendum:  Each connection attempt actually creates two logged errors:

[20/Aug/2000:06:21:43][653.4101][-conn0-] Error: Filter sec_read_security_info returned error #1: can't read "val": no such variable
[20/Aug/2000:06:21:43][653.4101][-conn0-] Error: nsd.tcl: Invalid return code from filter proc: Critical filter sec_read_security_info failed. (must be filter_ok, filter_return, or filter_break)

Update: This problem seems to be a function of ns_param EncryptPasswordsInDBP.

Running in debug mode showed this error occurring right after:

[20/Aug/2000:06:58:06][755.4101][-conn0-] Notice: Querying '
        select password
        from users
        where user_id = 10
        and user_state = 'authorized';'

[20/Aug/2000:06:58:06][755.4101][-conn0-] Notice: nsd.db: sql(localhost::myhost):
        select password
        from users
        where user_id = 10
        and user_state = 'authorized'

I had been using encrypted passwords, so I reset EncryptPasswordsInDBP to 0; I was then able to successfully log in.  More surprising was that upon resetting EncryptPasswordsInDBP to 1 and restarting, I was _still_ able to log in -- everything seemed back to normal.

Initial guess is that this is a function of interaction between the stored username/password combination in the OpenACS database and that stored in Internet Explorer 5.0.

Worth a trouble ticket?