spring / uberserver

uberserver, a matchmaking/chat lobby server for the spring rts project

Home Page:https://springrts.com/wiki/Uberserver

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

bot accounts can expire

TurBoss opened this issue · comments

could this time be extended to maybe 1 year?

thanks

commented

weird, from what i read here, bots should be kept forever:

response = self.sess().query(User).filter(User.ingame_time == 0).filter(User.last_login < now - timedelta(days=28)).filter(User.bot == 0).filter(User.access == "user")

commented

are you sure the user account had the botflag set?

Hello,

this account was created with the CREATEBOTACCOUNT command

found this

# remove botflags from clients that didn't log in for 3 months:

commented

hm, not sure how cleanly solve this.

i guess there needs to be a "task" which checks which users are online and write this to db.

the cleanup / audit thing then should also take this into account to ignore users which where recently online.

commented

as springrts.com server is automaticly rebooted after a (automatic) kernel update, IMHO 365 days should be enough to never be hit.

i leave this open, as there is only a workarround active

commented

hi please remove botflags or make botflag support up to 8v8 instead of 4v4 - all community use latest engine and this policy now punishes hard working people trying to provide hosts to support Spring

commented

when i say remove botflags i dont mean "remove inactive botflags" - I mean remove the botflag code or grant 8v8 botflag by default. The botflag idea was created in 2017 to force players onto BA10 by manipulating engine devs, and every day it exists causes more harm to this community.

image

My dev envir is long gone, but imo the best way to fix this bug (which was my fault) would be to exclude logged in users from the effect of audit_access. Iirc can check if the user(name) is online within the for loops and continue if so.

commented

My dev envir is long gone, but imo the best way to fix this bug (which was my fault) would be to exclude logged in users from the effect of audit_access. Iirc can check if the user(name) is online within the for loops and continue if so.

i guess thats not enough: IMHO a correct fix would be a task which is run by timer (daily) which updates last_login (or a new attribute like last_online).

i.e. think about the server going offline, server is going up again, the audit task is run. (the risk is pretty low as long as the host of uberserver is restarted because of kernel updates)

Hm, you are right

clean_loop = task.LoopingCall(_root.scheduled_clean)
will execute the looping call the first time during boot.