[Johnson_boy]

No longer available.

[HyDrAtIc]

This is a pretty decent and good include, can be used instead of using lots of includes and keep writing and writing, very helpful. (I guess its first time I give a +REP since long time ago. )

[kristo]

You should work together with this include's creator: https://sampforum.blast.hk/showthread.php?tid=449435

Both of these includes have very nice functions but i'd like to use some from both of them.

[Thomas.]

I think I may have found an issue, but I'm not completely sure about it, so please correct me if I'm wrong.

Imagine the following scenario:

Player A joins the server, and enters his correct password. Player A now leaves the server, while the server is still processing his password (perhaps due to a high cost setting, or whatever reason). A new player, player B, now enters the server and is assigned the ID previously used by player A. The server is now finished processing the password, and sends a "Hooray, you successfully logged in!" message to player B, as the script still thinks he is player A. While in fact player A has left the server.

I'm not sure if this classifies as a race condition, I think it does.

I haven't found any checks to prevent such a situation, but I haven't actually tested yet if this could actually happen - so it's just guessing at the moment.

[Ibrahim.E]

Very nice, good job. (+REP)

[BigETI]

Quote:

Originally Posted by Thomas. I think I may have found an issue, but I'm not completely sure about it, so please correct me if I'm wrong. Imagine the following scenario: Player A joins the server, and enters his correct password. Player A now leaves the server, while the server is still processing his password (perhaps due to a high cost setting, or whatever reason). A new player, player B, now enters the server and is assigned the ID previously used by player A. The server is now finished processing the password, and sends a "Hooray, you successfully logged in!" message to player B, as the script still thinks he is player A. While in fact player A has left the server. I'm not sure if this classifies as a race condition, I think it does. I haven't found any checks to prevent such a situation, but I haven't actually tested yet if this could actually happen - so it's just guessing at the moment.

Since the thread which runs the server scripts actually won't fire a disconnect call to the scripts during expensive calculations. Which means Player A can enter a correct password, the script starts to calculate with a huge delay. The player can actually quit the server without any problems, The server still thinks that the player is still connected and continues proceeding the calculation. Player B can't actually join during the expensive calculation, because the server will just not respond to the player. After the calculation the script fires the disconnection call and allows Player B to join. Player B just won't be logged in after connecting automaticly!

[ReVo_]

This include dont use HTTP function so i dont think this can happen Thomas.

I think this is just very strange.. why use "thread" word? This makes me very confused.. "thread" let me think another thing not a timer..

[Thomas.]

Quote:

Originally Posted by BigETI Since the thread which runs the server scripts actually won't fire a disconnect call to the scripts during expensive calculations. Which means Player A can enter a correct password, the script starts to calculate with a huge delay. The player can actually quit the server without any problems, The server still thinks that the player is still connected and continues proceeding the calculation. Player B can't actually join during the expensive calculation, because the server will just not respond to the player. After the calculation the script fires the disconnection call and allows Player B to join. Player B just won't be logged in after connecting automaticly!

The script utilizes timers in order to allow the server to do other processing stuff during processing of the password, so in theory, even if the timer is only activated twice, a new player could have taken over the position.

[Johnson_boy]

Quote:

Originally Posted by Thomas. I think I may have found an issue, but I'm not completely sure about it, so please correct me if I'm wrong. Imagine the following scenario: Player A joins the server, and enters his correct password. Player A now leaves the server, while the server is still processing his password (perhaps due to a high cost setting, or whatever reason). A new player, player B, now enters the server and is assigned the ID previously used by player A. The server is now finished processing the password, and sends a "Hooray, you successfully logged in!" message to player B, as the script still thinks he is player A. While in fact player A has left the server. I'm not sure if this classifies as a race condition, I think it does. I haven't found any checks to prevent such a situation, but I haven't actually tested yet if this could actually happen - so it's just guessing at the moment.

I have never tested that, but I believe this bug could occur. There is no sense to make the cost so high that it'd take more than a second to finish, but in theory, it is possible. I could maybe add a check, which determines whether or not it's the same client based on IP address.

Quote:

Originally Posted by BigETI In computer sience the meaning of a "thread" is to define a task, a process actually performs, so the word "multi-threaded" means that a process is divided into multiple tasks, also called threads. The SA:MP server AFAIK runs in 2 independent threads, an internal one and the one which actually processes all the running plugins and AMX (compiled scripts).

I agree with you, "thread" is not the best choice of vocabulary in this case. SA-MP is single threaded and multi threading is not possible without plugins. I was, however, never able to come up with a better word. If you have any ideas what word I should use instead, feel free to suggest.

[Thomas.]

Quote:

Originally Posted by Johnson_boy I have never tested that, but I believe this bug could occur. There is no sense to make the cost so high that it'd take more than a second to finish, but in theory, it is possible. I could maybe add a check, which determines whether or not it's the same client based on IP address.

Perhaps you could add a "connection ID counter", by simply counting up everytime a new player connects, and pass this value as an extra argument:

pawn Код:

public OnPlayerConnect(playerid) // It might be better to do this on OnPlayerDisconnect, as it removes the need to check if the player is actually still connected.
{
    connectId[playerid]++;
}

public PasswordHash(playerid, checkid, iterations_left, thread, bool:verifying)
{
    if(connectId[playerid] != checkid)
    {
        return 1; // It's not the same player anymore
    }