1. Forum
  2. DOVE-Net
  3. Synchronet Programming

  • src/sbbs3/userdat.c

    From Rob Swindell@VERT to Git commit to main/sbbs/master on Thu Aug 11 12:21:54 2022
    https://gitlab.synchro.net/main/sbbs/-/commit/8ad5e191568032ec2d91c79f
    Modified Files:
    src/sbbs3/userdat.c
    Log Message:
    matchuser() now always returns 0 when passed an empty 'name'

    Also, don't match against deleted (blank) usernames in name.dat
    (e.g. when 'name' value consists of a single ETX character).

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell@VERT to Git commit to main/sbbs/master on Sat Jan 21 19:51:15 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/6c0e423a38920f64abfb7013
    Modified Files:
    src/sbbs3/userdat.c
    Log Message:
    Don't truncate a user's record if the default download protocol or gender are '\0'

    A blank download protocol field in a user.dat, when parsed, sets the 'prot' field
    of user_t to 0. When writing the record back to the user.dat, this would prematurely
    truncate all other fields off the user record (since strings in C are NUL terminated
    and we're using sprintf() to format the record and %c specifier for that field).

    The fix is to write a ' ' character instead of '\0' if the user_t.prot is '\0'. As part of this fix, I'm writing a '?' if a user_t.sex is '\0' (not sure if this
    is actually possible, but just as insurance). Those are the only 2 single-character
    user properties/fields today.

    Bug reported/debugged by Al of The Rusty Mailbox (1:153/757.2) - thank you!

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (in GitKraken)@VERT to Git commit to main/sbbs/master on Thu Mar 2 18:56:50 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/14125aa4b0aa0bf027f77361
    Modified Files:
    src/sbbs3/userdat.c
    Log Message:
    The NoAccess* text.dat strings are not appropriate 'reason' codes

    These text.dat strings require an argument (and normally used with the NOACCESS @-code which uses the noaccess_str and noaccess_val member variables), so not appropriate to use as a reason code here. Use more generic (no argument) text.dat item numbers instead.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (in GitKraken)@VERT to Git commit to main/sbbs/master on Fri Mar 10 19:59:26 2023
    https://gitlab.synchro.net/main/sbbs/-/commit/edc931be6282acafdf043532
    Modified Files:
    src/sbbs3/userdat.c
    Log Message:
    More strict login-by-user-number support (parsing logic)

    Before now, if the sysop enabled login-by-user-number and the specified login ID *started* with a decimal digit, it'd be treated as a user number and converted to a 32-bit integer. This could result in weird stuff, like this error I got today:
    SMTP ... !ERROR -2 getting data on user (7000401005.gc7gg@synchro.net)

    7,000,401,005 is clearly greater than the number of users in my user base
    on Vert, but since 7B is > 2.1B (0x7fffffff), the number would be parsed as
    a *negative* integer value and thus less than the total number of users in my userbase.

    An obvious solution would be to just turn of login-by-user-number, and for
    most systems, I suggest doing that (a system is less secure with it enabled).

    However, I want to leave the option for sysops (at least for now) and don't want this weird behavior so, a login by user number now requires that the entire login ID is just decimal numbers, nothing else, and the number is
    parsed as an unsigned integer. So yes, roll-over can happen for very high numbers (>4.2B), but in no instance will the number be parsed as negative and thus lead to an invalid user record look-up attempt.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net