How to validate client input on authoritative server? (preventing speedhack or networtk send rate manipulation)

Well, i see two main issues here. First this does not really represent the actual Q3 network implementation. It's true that input is send out in packets and the server has to take all the input into account. However it makes no sense to drive the actual movement by each packet. An input packet should just update the input state on the server. The server movement simulation would run independently.

This implementation you've linked is not authoritative as the client actually dictates his movement. This actually has little to do with Q3. In Q3 you don't simulate anything on the client. You don't move on the client and you don't do any movement collision detection on the client. Q3 works with complete snapshots of the world state which includes the position of all "movable/changable things" in your surrounding. That includes the position of all players in view, even your own. You actually do not run on your PC, You just send you desired velocity to the server and the actual movement is done on the server. The clients just receive snapshots of the server state and then interpolate between the last two snapshots. So in general the simulation on the client simulation "lags behind". However since all commands get a timestamp the server can backtrace any actions that were raised in the past.

If a player has a slow connection it's possible that he hit and kill another player right before he goes around a corner. Due to the delay it might "feel" like the hit player was hit through the wall because he might die a few ms later. But the simulation is done on the server and the shot command might just have been late. It's never the less a legit hit since every player sees snapshots from the server.

The actual code to make that work properly is quite complicated.

ps: I once was connected to a Q3 server with a ping of 2 sec! If i press forward it takes 2 sec until i start running. So there's no clientside prediction. Q3 does extrapolation if the stream of snapshots is late / has dropped packets but only for a matter of some ms (100ms i think). If it takes longer you're actually "stuck" at the last extrapolated position. This also happens when you're connetion is interrupted.

As additional warning: He said it's

q revisited implementation of Quake 3 networking principe

This can cause trouble because the Q3 source is published under the GPL. If he really only reimplemented the "principle" without actually looking at the source it should be ok. However it's always a rist using things that might come from GPL code.