Som standard antager laravel, at du ønsker at have forskellige konfigurationer til forskellige miljøer. For eksempel. i et testmiljø ønsker du måske at have et andet brugernavn og kodeord og i et andet produktionsmiljø. Da laravel har så mange konfigurationsfiler, bliver det hurtigt et mareridt at administrere alle disse. Derfor gør laravel brug af PHP's miljøvariabler.
Hvad der grundlæggende siger er, at hvis du ønsker at bruge "miljø"-variablerne, som laravel bruger som standard, skal du placere alle dine konfigurationer i env()
metode som allerede nævnt.
Hvis du ikke ønsker at gøre dette, f.eks. for simple projekter skal du blot fjerne env fra din kode, sådan her.
'mysql' => [
'driver' => 'mysql',
'host' => 'localhost',
'database' => 'laravel',
'username' => 'root',
'password' => 'password',
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
'strict' => false,
],
Bemærk, at du kan mikse og matche. dvs. du kan have nogle af variablerne i env og nogle enkeltstående.
Så hvorfor bruge env
overhovedet?
Lad os sige, at din ansøgning har 100 testere, der alle er placeret forskellige steder. I laravel skal du kode cirka 8-10 konfigurationsfiler. Du skal også version-control
disse filer. Så du har to problemer ved hånden:
- Du ønsker ikke at sende alle 100 brugere de samme legitimationsoplysninger. De kan også bruge forskellige databaser, cacheservere osv., hvilket betyder, at de vil have forskellige konfigurationer. Så hver bruger skal vedligeholde disse 8-10 konfigurationsfiler i hånden.
- Du ønsker ikke at sende disse konfigurationsfiler til versionskontrol. For hvis du gør det, vil hele verden kende dine API-hemmeligheder og vil muligvis drage fordel af det (ligesom password). Hvis du også ser på laravel conf-filer, vil du bemærke, at der er andre oplysninger såsom tidszone, debug-egenskaber osv., der også er i conf-filer, og du vil gerne versionskontrollere dem. Så hvordan versionskontrollerer du sådanne konfigurationsfiler og skjuler stadig dine følsomme oplysninger.
Svaret er env
variable. Laravel bruger dotenv
hvis dokumentation kan findes her
. Dybest set er disse variabler, der findes i én fil kaldet .env
i et nøgleværdi-par. F.eks.
Eksempel på indholdet af .env-fil
APP_DEBUG=false
APP_KEY=ABCDEFGH
...
Når du har defineret din .env-fil som denne, kan du få værdien ved at bruge nøglen som sådan env('APP_DEBUG')
.
Så dette løser ovennævnte problem på følgende måder:
- du beholder
.env
fil til dig selv. Og du erklærer også en anden fil kaldet.env.example
som er en nøjagtig kopi af den originale fil, bortset fra at den indeholder eksempelværdier, ikke dine følsomme værdier. Så sender du denne nye eksempelfil til alle. De vil erstatte prøvedataene med deres egne følsomme oplysninger. - Da du versionskontrollerer eksempelfilen, kan du versionskontrollere alle dine conf-filer, fordi de ikke indeholder hemmeligheden. Hemmeligheden ligger i .env-filer. Alle disse conf-filer indeholder værdier som disse
env('APP_KEY')
og den faktiske værdi erstattes ved kørsel ved hjælp af din .env-fil.