• Re: A46 idea

    From g00r00@21:1/108 to StackFault on Sat Feb 22 07:26:03 2020
    is good for 30 days after a successful authentication. If you don't connect for 30 days, the whitelist goes. This would autoclean the whitelist in case of dynamic IP addresses.

    It would but it would also remove IP addresses that you actually want to manually whitelist too. I am not sure that would even really be a problem though if you're using automatic whitelist but if you're not it certainly would.

    It would also require me to change the format of the whitelist out of a single line text file to something that you couldn't manage easily because it'd have to be associated with (probably) a Unix time stamp value.

    --- Mystic BBS v1.12 A45 2020/02/18 (Windows/64)
    * Origin: Sector 7 (21:1/108)
  • From g00r00@21:1/108 to Avon on Sat Feb 22 07:48:21 2020
    2020.20.02 20:33:30 MYSTIC 001 Cannot write to c:\bbs\mystic\data\chat1.dat. Code=2, PID=118280

    Yeah this is really weird. Let me know if you notice this again. The code=2 means the file doesn't exist and there should never be a situation where chatx.dat is deleted while a user is still online...

    Mystic creates it on startup and removes it on close, so how it got removed in those circumstances is a mystery at the moment.

    It used to be that Mystic would just recreate it, but that was causing some potential race conditions that could cause ghost nodes when I was doing load testing on MIS. So now it doesn't and instead spits an error out.

    --- Mystic BBS v1.12 A45 2020/02/18 (Windows/64)
    * Origin: Sector 7 (21:1/108)
  • From StackFault@21:1/172 to g00r00 on Sun Feb 23 13:13:33 2020
    I'd tweak that just a bit by setting up a whitelist lease. The whitel is good for 30 days after a successful authentication. If you don't connect for 30 days, the whitelist goes. This would autoclean the whitelist in case of dynamic IP addresses.

    It would but it would also remove IP addresses that you actually want to manually whitelist too. I am not sure that would even really be a
    problem though if you're using automatic whitelist but if you're not it certainly would.

    Yes, this is certainly something to keep in mind.

    It would also require me to change the format of the whitelist out of a single line text file to something that you couldn't manage easily
    because it'd have to be associated with (probably) a Unix time stamp value.

    That value could be used for both purposes. A value of 0 would be permanent while a non-zero (epoch for example) would be the expiration. It would also require you to update the file to extend the expiration on successful BinkP connection and so on. I understand this is not a simple change but it would
    add some value.

    Cheers!

    |15 ▀ ▐ |15StackFault |08<|03.|11.|15P|11h|03EN|11o|15M|11.|03.|08>
    |11 ▌ ▀ |11The Bottomless Abyss BBS
    |03 ▀ ▌▀ |03ssh|08.|072222 |08/ |03telnet|08.|072023 |08/ |03https
    |08 ▄■▐ |08bbs|07.|08bottomlessabyss|07.|08net

    --- Mystic BBS v1.12 A44 2020/02/04 (Linux/64)
    * Origin: The Bottomless Abyss BBS * bbs.bottomlessabyss.net (21:1/172)