Din FiveM-server starter, oxmysql indlæses, og så fyldes konsollen med ER_ACCESS_DENIED_ERROR: Access denied for user. Du har kopieret vært, brugernavn og adgangskode direkte fra panelet, så den oplagte konklusion er, at databasebrugeren ikke har lov til at forbinde fra din server.
Det er den næsten aldrig. I langt de fleste af disse sager er oplysningerne rigtige, og det er forbindelsesstrengen, der er problemet. Din adgangskode indeholder et tegn, som det format du brugte ikke kan bære, så oxmysql sender MySQL en anden adgangskode end den, du kopierede, og MySQL gør præcis det rigtige. Den afviser.
Hvorfor adgangskoden bliver ødelagt
oxmysql accepterer to forskellige formater i mysql_connection_string, og de går i stykker på hver sit sæt tegn.
Nøgle og værdi
set mysql_connection_string "user=s12_user;password=SECRET;host=1.2.3.4;port=3306;database=s12_economy;charset=utf8mb4"
oxmysql deler denne op på ; og derefter på = og beholder de to første stykker. Så et ; eller et = et vilkårligt sted i din adgangskode klipper den lydløst over. Ingen advarsel, ingen fejl, bare en kortere adgangskode end den, du indsatte.
URI-format
set mysql_connection_string "mysql://s12_user:[email protected]:3306/s12_economy?charset=utf8mb4"
Dette format matches med et regulært udtryk, og brugeroplysningerne deles på :. Matchet løber grådigt frem til det sidste @, hvilket betyder, at et @ i din adgangskode er helt uproblematisk her. Et :, /, ? eller # er det ikke, fordi hvert af dem afslutter sin egen del af URI'en.
Et " ødelægger begge formater, fordi hele værdien ligger inde i en citeret convar, og citationstegnet lukker den for tidligt.
Der findes altså ikke ét format, der overlever enhver adgangskode. Der findes et format, der overlever din adgangskode, og det er valget af det forkerte, der giver access denied.
Lad være med at procent-kode din adgangskode
Det er det oftest gentagne dårlige råd på området, og det gør tingene værre.
oxmysqls URI-parser laver ingen procent-afkodning. Er din adgangskode p@ss, og skriver du den hjælpsomt som p%40ss, sender oxmysql de bogstavelige tegn p%40ss til MySQL, hvilket ikke er din adgangskode, og så får du access denied af en helt ny grund. I URI-formatet skal adgangskoden ind råt, præcis som panelet viser den.
Procent-kodning er korrekt for database-URI'er i masser af anden software. Her er det forkert.
Løsningen: kopiér den linje panelet bygger
Du behøver ikke selv regne ud, hvilket format din adgangskode kræver. Åbn din server i panelet, gå til fanen Databaser, og se på kortet oxmysql forbindelsesstreng under din database.
Det kort indeholder den komplette set mysql_connection_string "..."-linje, allerede sat sammen af din vært, port, brugernavn, databasenavn og adgangskode, i det af de to formater der kan bære netop din adgangskode. Brug kopiknappen frem for at markere teksten i hånden, så den rigtige adgangskode bliver kopieret, selv mens den er skjult på skærmen.
Viser kortet en advarsel og en knap med Generér ny adgangskode i stedet for en streng, indeholder din adgangskode en kombination, som ingen af formaterne kan udtrykke, for eksempel et ", eller både et = og et :. Tryk på knappen. Du får en ny fungerende adgangskode på et sekund, og kortet viser derefter en gyldig linje.
Hvor linjen skal ind
Indsæt den i server.cfg, øverst i filen.
Den ene regel, der betyder noget, er rækkefølgen. set mysql_connection_string skal stå før ensure oxmysql. oxmysql læser convar'en, når den starter, så en forbindelsesstreng længere nede i filen bliver læst for sent, og ressourcen starter op uden noget.
Styrer txAdmin din server, så tilføj den i txAdmin-indstillingerne i stedet for at rette server.cfg i hånden. txAdmin gendanner dele af konfigurationen, og en rettelse i filen kan blive overskrevet.
Genstart serveren efter ændringen. Det er ikke nok at genindlæse ressourcen alene, fordi convar'en læses ved ressourcens start.
Bekræft at det virkede
Åbn fanen Konsol og genstart. En sund oxmysql skriver en linje, der bekræfter forbindelsen til din database og oplyser MySQL-versionen. Er oplysningerne forkerte, får du access denied-linjen igen med det samme, inden for et sekund eller to efter at ressourcen er startet.
En forbindelse, der hænger i mange sekunder og derefter fejler, er et andet problem. Så er værten eller porten uopnåelig, og det handler ikke om adgangskoden.
Fejlfinding
Access denied, og min adgangskode indeholder ; eller =. Du bruger nøgle og værdi, og din adgangskode bliver klippet over. Skift til URI-formatet, eller skift adgangskode.
Access denied, og min adgangskode indeholder :, /, ? eller #. Du bruger URI-formatet, og adgangskoden bliver klippet ved det tegn. Skift til nøgle og værdi, eller skift adgangskode.
Access denied, og min adgangskode indeholder @. I URI-formatet er det uproblematisk, og @ er ikke dit problem. Kig på brugernavnet og databasenavnet i stedet. Har du procent-kodet dit @ som %40, så lav det om igen.
Access denied for et tomt brugernavn. Linjen er misdannet snarere end forkert. Et løst citationstegn eller et manglende set gør typisk dette. Kopiér hele linjen fra panelet igen.
Unknown database. Databasenavnet og brugernavnet ligner hinanden til forveksling, fordi de bærer det samme genererede præfiks. Det er nemt at indsætte det ene, hvor det andet hører til. I panelet er brugernavnet værdien under Brugernavn, og databasenavnet er overskriften på rækken.
Connection timed out eller connect ECONNREFUSED. Det handler ikke om oplysningerne. Kontrollér, at du brugte hele værten fra panelet inklusive porten efter kolonnet, og at du ikke har erstattet den med localhost eller 127.0.0.1. Din database ligger ikke på samme maskine som din gameserver, så de adresser peger et helt andet sted hen.
Det virkede i går og stoppede i dag. Nogen har trykket Ny adgangskode på databasen, enten dig eller en anden med adgang til panelet. En ny adgangskode ugyldiggør den gamle med det samme. Kopiér den nye linje.
oxmysql siger, at der ikke blev fundet nogen forbindelsesstreng. Convar'en står under ensure oxmysql i server.cfg, eller txAdmin har overskrevet din rettelse.
Ofte stillede spørgsmål
Er databasebrugeren begrænset til bestemte værter? Nej. Databaser oprettet fra panelet tager imod forbindelser fra enhver vært, så en databasebruger spærret på vært er ikke årsagen til din access denied-fejl. Det er værd at sige rent ud, for det er det første, næsten alle mistænker.
Hvilket format skal jeg bruge? Det, panelet giver dig. Det vælger nøgle og værdi som standard og skifter til URI-formatet, når din adgangskode kræver det.
Kan jeg bare fjerne specialtegnene fra min adgangskode? I praksis ja. Trykker du Ny adgangskode, får du en frisk, og lander den på noget, begge formater kan bære, viser panelet det enklere format. Du kan ikke selv vælge din adgangskode, så en ny adgangskode er vejen til en venligere.
Gælder det også ESX og QBCore? Ja. Begge er bygget på oxmysql og læser den samme convar. Den samme linje virker til begge.
Har jeg brug for charset=utf8mb4?
Det er ikke et krav, men behold det. oxmysql bruger utf8mb4 som standard i forvejen, og det er netop det at skrive det eksplicit, der forhindrer, at bogstaver med accenter i spillernavne bliver gemt forkert på servere, hvis MySQL-standard er ældre.
Kan jeg lægge forbindelsesstrengen i en ressourcekonfiguration i stedet? Lad være. Frameworks læser den fra convar'en, og en kopi mere i en ressourcefil er endnu et sted at holde opdateret, når adgangskoden skiftes.
Skal jeg dele min forbindelsesstreng, når jeg beder om hjælp? Nej. Den indeholder adgangskoden i fuld længde. Del fejllinjen fra konsollen, og skriv hvilket format du brugte, aldrig selve strengen.
Får du stadig access denied efter at have kopieret linjen fra panelet? Kontakt support med dit servernavn og den præcise konsoludskrift uden adgangskoden, så tjekker vi databasen fra vores side. Har du ikke en server endnu? Se vores FiveM server hosting.