• Rob Swindell's avatar
    Fix access-control by terminal cap issue introduced a week ago · f5fed0b2
    Rob Swindell authored
    In commit 3f17c245, I was addressing the issue reported by Nelgin via IRC:
    <nelgin> If you login using a term that doesn't support ansi, it changes your settings - can you set 'em back when done?
    <DigitalMan> if you have auto-term enabled, it doesn't actually change your settings, just what's in use during that session
    <nelgin> I logged in using my BBC emulator which doesn't do ansi, then when I logged in through syncterm, I got the display like it was on the BBC. All my characters replaced with #'s and stuff.
    <nelgin> I had to go back into the user menu to fix it. That is going to confuse users.
    
    However, the chk_ar() function in userdat.c which is used to populate JS objects (e.g. xtrn_area.sec_list[].prog_list[]) uses the user.misc value (cannot call term_supports()), so the current user terminal flags need to be reflected in user.misc always. So the real fix for the originally reported problem is to clear the charset-related terminal settings when logging in with auto-terminal settings enabled (and before the auto-detected charset flags are OR'd in).
    
    I toyed with the idea of storing a copy of the term_supports() result in client_t, which is passed to chk_ar() when appropriate, but decided that was a bit overkill and there were issues with servers that don't have term_supports (e.g. the web server) and properly populating access-controlled areas in the JS object model (e.g. door games that require ANSI). Better to use the last-auto-detected terminal caps than assuming "no" terminal capabilities in that scenario.
    f5fed0b2
logon.cpp 22.3 KB