Rather than check userdb for presence of the guest user ID to validate guest Auth-Key values, we will check for the ID in acctdb. If present, we know it cannot be a guest because it is a registered user. This is to remove a specific userdb as a dependency on services that serve sites using different userdbs. The biggest hole here is that someone could send an ID that is higher than the current ID sequence; then later that ID could be assigned to a new registered user. If that happens, the new registered user will "inherit" (and steal) the spoof-guest's data. Serves them right for not using a legit guest ID.
Rather than check userdb for presence of the guest user ID to validate guest Auth-Key values, we will check for the ID in acctdb. If present, we know it cannot be a guest because it is a registered user. This is to remove a specific userdb as a dependency on services that serve sites using different userdbs. The biggest hole here is that someone could send an ID that is higher than the current ID sequence; then later that ID could be assigned to a new registered user. If that happens, the new registered user will "inherit" (and steal) the spoof-guest's data. Serves them right for not using a legit guest ID.