DDMsgReader: For the sysop reading personal email addressed to 'sysop', mark the email read

See merge request !527

CTCP, user actions, and fixes

See merge request !525

DDMsgReader: Fix to bottom row help text due to behavior change in Git commit fccf1a57 - Some key codes in the help lines were causing a line break and causing scrolling

See merge request !526

Eric Oulashin authored 4 days ago and Rob Swindell committed 4 days ago

DDMsgReader: Fix to bottom row help text due to behavior change in Git commit fccf1a57 - Some key codes in the help lines were causing a line break and causing scrolling

To enable high quality/entropy password checking, set SCFG->System->Security
->Demand High Quality Password to "Yes".

This defaults to false since the "quality" standard is higher than it used to
be and that could be confusing for sysops or users.

Log a message before the regenerate loop, just in case this loops forever. :-)

We already other means to do that, allowing more visibility to caller *why*
a password may be rejected.

... with the system object and the underlying SBBS functions being called.

Leave bbs.good_password() as an alias for backward compatibility.

These are wrappers around the userdat API functions, suitable for servers
to do prospective new user string validation.

sbbs_t::chkpass() now becomes just a thin wrapper around check_pass() and it
prints the reason for the failure or calls sbbs_t::trashcan().

I also refactored the code quite a bit: no more copying and uppercasing
(we have strcasestr() now!) and supports calling with a NULL user_t* as I
expect will be a use case.

This will allow us to expose the password quality checking algorithm to other
servers (e.g. the web server) that can be used to create new user accounts
with passwords that meet our quality bar.
e.g. via a newly created JS method: system.check_password()

Yes, we have bbs.good_password() already (and that still works fine), but
can't be used by non-terminal server code.

Require that a good password contain a sequence of unique characters
(not repeating, incrementing, or decrementing in ASCII code value) of at least
half the configured minimum password length. By default, the minimum password
length is 4 chars, so this means a sequence of at least 2 unique characters
is required. If the minimum password length is increased by the sysop, so is
the minimum required unique sequence length. The "PasswordInvalid" text.dat
string is printed when passwords are rejected by this criteria.

Previously, the following would be rejected by this portion of the algo,
this logic has been replaced by the above:
- all chars the same (would print the "PasswordInvalid" text.dat string)
- first 4 chars are incrementing ("PasswordObvious" string printed)
- first 4 chars are decrementing ("PasswordObvious" string printed)

but now, a password that starts with "1234" or "abcd" is fine so long as it's
longer than that and contains the minimum unique sequence length. This will
prevent SBBS from rejecting high quality (e.g. randomly generated or
crypto-hashed) passwords that just happen to begin with an incrementing
sequence of 4 digits or alpha-characters.

Both the and the output are not prettier.

This fixes issue #901

Also, always use clearabort() to clear SS_ABORT now, and move the
method body into con_out.cpp (where msgabort() is) since it actually
does a thing now.

Fixes issue #907

to clarify how many hex digits will be included in the returned (hex) strings

No functional change

Replace the CRLFs with direct term->newline() calls.

In some uses (depending on the list order), typing a message number didn't
take you to the intended message.

Reported by Nelgin in IRC.

DD Area Choosers: Fix for altName missing (reported by nelgin) and start of name collapsing enhancement (no empty names)

See merge request !524

DD Area Choosers: Fix for altName missing (reported by nelgin) and start of name collapsing enhancement (no empty names)

e.g. '-hSEVERNAME'

This allows server-unique hashing so that if one BBS auto-registers
/authenticates its users with *multiple* Rlogin servers, the credentials
stored on of the rlogin servers may not be used to authenticate on the others.

Should fix issue where extra pauses occur on connection.

Like the -p option, except the server won't get a copy of the client BBS
user's password or be able to decode it.

The user's password, user number and account creation date are used to generate
the password hash (along with the salt), so changing any of these will change
the resulting hashed password sent (and presumably logged/stored) on the
server. The resulting SHA-1 hash is sent as 40 hexadecimal digits.

The default salt is the system's QWK-ID, but the sysop can specify their own
salt (e.g. random number or secret passphrase) via the "salt" key in the
[rlogin] section of modopts.ini or root section of ctrl/modopts/rlogin.ini

Bug introduced in commit 49053f31

the 'mode' value was by default, undefined.
the 'timeout' value is by default, 10.

When mode value/flags was not provided on the command-line, undefined
was passed to bbs.rlogin_gate() as the 5th parameter, but the number 10
is passed as the 6th parameter (for time-out). The problem is, the first
Number parameter passed to bbs.rlogin_gate() is interpretted as the mode
value and so that becomes 10 (0x0A) which includes TG_NODESYNC thus enabling
all node messages/activity being displayed to the rlogin user and interrupting
their rlogin session (e.g. game play).

Just make the 0 the default value for mode, like we did in telgate.js.

Readfile does not log an error when the file does not exist.

In felicity.ref, `s04 and `s05 were left unchanged from whatever
they happened to be previously, displaying junk when someone looked
at the message. Now, `s04 and `s05 are explicitly set to zero-length
strings first so they just display nothing.

Fixes #906

Fixes issue #484

Vert's mail base .shd file is consistently > 0xFFFFFF bytes in size.

RIP sequences conflict with Celerity pipe codes, so don't convert them to
color codes (even when enabled in SCFG->Systems->Extra Attribute Codes...).

We *used* to disable all pipe code parsing when sending to a RIP-enabled
terminal but since we don't do that any longer, this is a better/cleaner fix.

Renegade "pipe codes" (|xx where xx are decimal digits) don't "seem" to
conflict with any RIP sequences (so leave that parsing enabled for .rip files)
but Deuce can help me to be sure about that (please).

If a message group has no sub-boards (or no sub-boards that ther user can
access) then the user cannot access the group, so don't include the group in
JS msg_area.grp_list[].

No functional change.