sql >> Database >  >> RDS >> Mysql

lavaral 5 FOUT{ (SQLSTATE [HY000] [1045] Toegang geweigerd voor gebruiker 'root'@'localhost' (met wachtwoord:JA)}

Laravel gaat er standaard van uit dat je verschillende configuraties wilt hebben voor verschillende omgevingen. bijv. in een testomgeving wil je misschien een andere gebruikersnaam en wachtwoord en in een productieomgeving anders. Omdat laravel zoveel configuratiebestanden heeft, wordt het al snel een nachtmerrie om al die bestanden te beheren. Daarom maakt laravel gebruik van PHP's omgevingsvariabelen.

Bekijk de documenten hier.

Wat er in feite staat, is dat als je de "omgevings"-variabelen wilt gebruiken, die laravel standaard gebruikt, je al je configuraties in de env() moet plaatsen methode zoals reeds vermeld.

Als u dit niet wilt doen, b.v. voor eenvoudige projecten, verwijder gewoon de env uit je code, zoals deze.

'mysql' => [
        'driver'    => 'mysql',
        'host'      => 'localhost',
        'database'  => 'laravel',
        'username'  => 'root',
        'password'  => 'password',
        'charset'   => 'utf8',
        'collation' => 'utf8_unicode_ci',
        'prefix'    => '',
        'strict'    => false,
    ],

Let op:je kunt mixen en matchen. d.w.z. u kunt sommige variabelen in env hebben en sommige stand-alone.

Dus waarom gebruik je env helemaal niet?

Stel dat uw toepassing 100 testers heeft die allemaal op verschillende locaties zijn geplaatst. In laravel moet je ongeveer 8-10 configuratiebestanden coderen. Ook moet u version-control die bestanden. U heeft dus twee problemen:

  1. Je wilt niet alle 100 gebruikers dezelfde inloggegevens sturen. Ze kunnen ook verschillende databases, cacheservers, enz. Gebruiken, wat betekent dat ze verschillende configuraties hebben. Dus elke gebruiker moet die 8-10 configuratiebestanden met de hand onderhouden.
  2. U wilt deze configuratiebestanden niet naar versiebeheer sturen. Want als je dat doet, zal de hele wereld je API-geheimen kennen en daar mogelijk misbruik van maken (net als wachtwoord). Ook als je naar laravel conf-bestanden kijkt, zul je merken dat er andere informatie is, zoals tijdzone, debug-eigenschap, enz. die zich ook in conf-bestanden bevinden, en je wilt ze wel versiebeheer. Dus hoe beheert u versiebeheer van dergelijke configuratiebestanden en verbergt u toch uw gevoelige informatie.

Het antwoord is env variabelen. Laravel gebruikt dotenv wiens documentatie hier te vinden is . In principe zijn dit variabelen die in één bestand leven met de naam .env in een sleutelwaardepaar. Bijv.

Voorbeeld van inhoud van .env-bestand

APP_DEBUG=false
APP_KEY=ABCDEFGH
...

Zodra u uw .env-bestand als volgt definieert, kunt u de waarde verkrijgen met de sleutel als zodanig env('APP_DEBUG') .

Dus dit lost het bovengenoemde probleem op de volgende manieren op:

  1. je behoudt de .env bestand voor jezelf. En je declareert ook een ander bestand genaamd .env.example wat een exacte replica is van het originele bestand, behalve het feit dat het voorbeeldwaarden bevat, niet uw gevoelige waarden. Dan geef je dit nieuwe voorbeeldbestand aan iedereen door. Ze zullen de voorbeeldgegevens vervangen door hun eigen gevoelige informatie.
  2. Omdat je het voorbeeldbestand versiebeheert, kun je al je configuratiebestanden versiebeheer omdat ze het geheim niet bevatten. Het geheim zit in .env-bestanden. Al die conf-bestanden bevatten waarden zoals deze env('APP_KEY') en de werkelijke waarde wordt tijdens runtime vervangen met behulp van uw .env-bestand.


  1. Oracle leest bestand uit directory met uitzondering

  2. 6 manieren om de grootte van een database in SQL Server te controleren met T-SQL

  3. Mytop – Een handig hulpmiddel voor het bewaken van MySQL/MariaDB-prestaties in Linux

  4. Vervang null-waarden in sql met behulp van de select-instructie in mysql?