←  Pytania

AMXX.pl: Support AMX Mod X i SourceMod

»

Podszywanie się pod kogoś nick / kradzież...

  • +
  • -
dredek's Photo dredek 16.07.2016

Yoo

Sprawa wygląda tak, że mam np. nick dredek i mam na tym nicku założone hasło na serwerze po czym wychodzę z serwera i wchodzi typ o nicku dredEk (jedna duża litera, taki sam nick) i ten typo nie ma hasła a ponadto ma taki sam exp na klasach jak ja i po tym robi się nieprzyjemny bug i exp wchodzi na - lub cofa lvl do 1.

Tak jakby nie uwzględniało dużych liter i pasowałoby to jakoś poprawić... jakieś sugestie? :)

Quote

  • +
  • -
Linux''s Photo Linux' 16.07.2016

Do zakladania hasla korzystasz zapewne z przywilejow amxbansa?

Otworz amxbans_core i znajdz stock getAccess(id, const name[], const authid[], const ip[], const password[]). W srodku poszukaj funkcji typu equali(name cos tam cos tam, i zamien to na equal.

Quote

  • +
  • -
dredek's Photo dredek 18.07.2016

Do zakladania hasla korzystasz zapewne z przywilejow amxbansa?

Otworz amxbans_core i znajdz stock getAccess(id, const name[], const authid[], const ip[], const password[]). W srodku poszukaj funkcji typu equali(name cos tam cos tam, i zamien to na equal.

 

Właśnie chodzi o to, że nie korzystam z amxbansa.

Ten sam problem pojawia się na codmodach, csgo modach itp itd.

Czysty bug od csa 

Wziąłem na próbę i skorzystałem z pluginu amx_onename czy jakoś tak, który działa na zasadzie wejde na serwer na jednym nicku to już na innym nie pogram bo mi zmieni na stary bo zapis nvault... xD Ale nie pomogło mi to zbytnio :/

Quote

  • +
  • -
_McHappy's Photo _McHappy 24.07.2016

Zależy przez co to hasło jest sprawdzane (samego amxx'a -> setinfo, czy też jakiś plugin typu /konto), bo tego nie dopowiedziałeś :D

Jeśli chodzi o setinfo, no to rzeczywiście masz buga - w typowej konfiguracji (załóżmy flagi dostępu 'a') serwer nie zważa na wielkość znaków w nicku i kickuje graczy.

Sprawa ma się inaczej jeśli nadałeś flagę dostępową 'k' -> wtedy serwer przepuszcza owego kolegę drEdka, a silnik Diablo pobiera dane z bazy z twojego nicku.

 

Inaczej: spróbuj dokonać tego, o czym wspomniał Linux', tyle że w silniku swojej wersji Diablo. Chodzi o podmianę funkcji pobierającej twój nick z bazy na jej odpowiednik z opcją "case sensitive' -> wtedy każdy inny nick niż 'dredek' będzie osobno traktowany przez bazę...


Edited by _McHappy, 24.07.2016 17:08.
Quote

  • +
  • -
dredek's Photo dredek 25.07.2016

Zależy przez co to hasło jest sprawdzane (samego amxx'a -> setinfo, czy też jakiś plugin typu /konto), bo tego nie dopowiedziałeś :D

Jeśli chodzi o setinfo, no to rzeczywiście masz buga - w typowej konfiguracji (załóżmy flagi dostępu 'a') serwer nie zważa na wielkość znaków w nicku i kickuje graczy.

Sprawa ma się inaczej jeśli nadałeś flagę dostępową 'k' -> wtedy serwer przepuszcza owego kolegę drEdka, a silnik Diablo pobiera dane z bazy z twojego nicku.

 

Inaczej: spróbuj dokonać tego, o czym wspomniał Linux', tyle że w silniku swojej wersji Diablo. Chodzi o podmianę funkcji pobierającej twój nick z bazy na jej odpowiednik z opcją "case sensitive' -> wtedy każdy inny nick niż 'dredek' będzie osobno traktowany przez bazę...

 

Z tym zakładaniem konta to jest wbudowane w silnik diablo moda... zwykłe założenie hasła podczas gry przez menu.

Sprawdzałem wszystkie funkcje i wychodzi na to, że wszystko jest dobrze z kontami i problem leży po innej stronie.

Działa to tak, że mam nick dredek mam np. 100 lvl na klasie i nie mam hasła setinfo ani konta na serwerze po czym wchodzi typ Dredek i ma wszystkie moje lvl'e, klasy itp.

Trzeba to zrobić jakoś inaczej bo sposób linuxa jak i Twój nie działa zbytnio... Przy zakładaniu tych całych kont itp sprawdzałem wszystkie equale i powinno raczej dobrze zapisywać wszystko. Może tak poszperać przy zapisie/wczytywaniu expa?  Sugestie?

 

Spoiler
Quote

  • +
  • -
_McHappy's Photo _McHappy 25.07.2016

Myślę, że to wina SQL - klauzula 'WHERE' nie ma zaimplementowanego rozpatrywania wielkości znaków.

Jedyne co udało mi się w tym kierunku znaleźć to taką oto modyfikację komendy wysyłanej do bazy danych:

 

Z:

   formatex(q_command, 1023, "SELECT * FROM `%s` WHERE `nick`='%s' AND `klasa`='%i'", g_sqql, name, klasa);

Na:

   formatex(q_command, 1023, "SELECT * FROM `%s` WHERE `nick`='%s' COLLATE SQL_Latin1_General_CP1_CS_AS AND `klasa`='%i'", g_sqql, name, klasa);

To samo tyczy się formuły zawartej w funkcji:

public SaveXP(id)

Przestrzegam, iż nie testowałem podanego rozwiązania - jest to jedynie zastosowanie metod opisanych na tej stronie:

http://stackoverflow...sing-sql-server

 

Quote

  • +
  • -
dredek's Photo dredek 25.07.2016

Myślę, że to wina SQL - klauzula 'WHERE' nie ma zaimplementowanego rozpatrywania wielkości znaków.

Jedyne co udało mi się w tym kierunku znaleźć to taką oto modyfikację komendy wysyłanej do bazy danych:

 

Z:

   formatex(q_command, 1023, "SELECT * FROM `%s` WHERE `nick`='%s' AND `klasa`='%i'", g_sqql, name, klasa);

Na:

   formatex(q_command, 1023, "SELECT * FROM `%s` WHERE `nick`='%s' COLLATE SQL_Latin1_General_CP1_CS_AS AND `klasa`='%i'", g_sqql, name, klasa);

To samo tyczy się formuły zawartej w funkcji:

public SaveXP(id)

Przestrzegam, iż nie testowałem podanego rozwiązania - jest to jedynie zastosowanie metod opisanych na tej stronie:

http://stackoverflow...sing-sql-server

 

Zero efektów. Jak było tak jest :/

 

w tej funkcji w sumie jest już uwzględnianie wielkich liter

 

public sql_start()
{
    if(g_boolsqlOK) return;

    new host[128], user[64], pass[64], database[64];

    get_cvar_string("diablo_sql_database", database, 63);
    get_cvar_string("diablo_sql_host", host, 127);
    get_cvar_string("diablo_sql_user", user, 63);
    get_cvar_string("diablo_sql_pass", pass, 63);

    g_SqlTuple = SQL_MakeDbTuple(host, user, pass, database);

    get_cvar_string("diablo_sql_table", g_sqql, 63);
    get_cvar_string("diablo_sql_diax", g_diax, 63);
    
    
    new q_command[1024],iLen = 0;
    new q_diax[1024];

    iLen += formatex(q_command,charsmax( q_command ), "CREATE TABLE IF NOT EXISTS `%s` (`nick` VARCHAR(48),`ip` VARCHAR(32),`sid` VARCHAR(32),`klasa` INT(2),`lvl` INT(3) DEFAULT 1,`exp` INT(9) DEFAULT 0,`str` INT(3) DEFAULT 0,`int` INT(3) DEFAULT 0,`dex` INT(3) DEFAULT 0,`pak` INT(3) DEFAULT 0,`agi` INT(3) DEFAULT 0,`kas` INT(3) DEFAULT 0,",g_sqql)
    iLen += formatex(q_command[ iLen ],charsmax( q_command ) - iLen, "`dam` INT(3) DEFAULT 0,`man` INT(3) DEFAULT 0,`kam` INT(3) DEFAULT 0,`men` INT(3) DEFAULT 0,`mis` INT(3) DEFAULT 0,`art` INT(3) DEFAULT 0,`wyt` INT(3) DEFAULT 0,`grw` INT(3) DEFAULT 0) DEFAULT CHARSET `utf8` COLLATE `utf8_general_ci`");

    SQL_ThreadQuery(g_SqlTuple, "TableHandle", q_command);
    
    formatex(q_diax, charsmax ( q_diax), "CREATE TABLE IF NOT EXISTS `%s` (`nick` VARCHAR(48), `diamenty` INT(3) DEFAULT 0) DEFAULT CHARSET `utf8` COLLATE `utf8_general_ci`", g_diax)

    SQL_ThreadQuery(g_SqlTuple, "TableHandle", q_diax);
}

Quote

  • +
  • -
_McHappy's Photo _McHappy 25.07.2016

Hmmm. utf8_general_ci -> to ostatnie 'ci' oznacza Case Insensitive czyli brak rozróżniania wielkości liter https://pl.m.wikiped...ase_sensitivity
 
Spróbuj może zamiast utf8_general_ci zastosować utf8_bin
Może to wymagać zmiany kodowania tablicy. 
 
Dlatego też polecam inną metodę - jako że tylko nick musi być sprawdzany pod kątem wielkości liter, można sprawdzać jego zapis binarny:
formatex(q_command, 1023, "SELECT * FROM `%s` WHERE BINARY `nick`='%s' AND `klasa`='%i'", g_sqql, name, klasa);

 

Quote

  • +
  • -
dredek's Photo dredek 25.07.2016

 

Hmmm. utf8_general_ci -> to ostatnie 'ci' oznacza Case Insensitive czyli brak rozróżniania wielkości liter https://pl.m.wikiped...ase_sensitivity
 
Spróbuj może zamiast utf8_general_ci zastosować utf8_bin
Może to wymagać zmiany kodowania tablicy. 
 
Dlatego też polecam inną metodę - jako że tylko nick musi być sprawdzany pod kątem wielkości liter, można sprawdzać jego zapis binarny:
formatex(q_command, 1023, "SELECT * FROM `%s` WHERE BINARY `nick`='%s' AND `klasa`='%i'", g_sqql, name, klasa);

 

 

nadal nic... ;/

Quote