Level 102
Compiled js runs client side and has no access to either files on server or client (expect for upload on client side and ajax on server side). Anything else would be a security risk
Oct 5, 2020
4
Level 3
laravel mix environment variables - workflow?
I can't seem to get a clear picture of how this is supposed to work.
i want to compile my JS on 1 machine.. commit it to git and deploy it to an environment. We deploy to test, staging and production via envoyer.
But i want to use the .env to set the environment details for the pusher implementation. i can only get laravel mix to compile the environment variables down at compile time. So they are actually hardcoded in the app.js.
is the idea behind mix to compile at deployment time?
my ideal setup would be to compile it all once and getting the environment variables at runtime.
if there is no way, i will have to expose the data via a variable via html and then pick it up in js. But that seems to me like a nasty workaround.
am i missing something?
ps.. dotenv, tried.. still compiles variables down also testen on clean laravel install.
Level 3
yeah, i understand that. But then i cant really get what the intended deployment path supposed to be like.. whats the point of being able to read the environment variables, unless the code is already in that location.
It not more secure to compile the codes in js , the keys are still public? So, is it best practice to compile after deployment?
i hoped the system would auto generate a "public js" file with the needed environment details and automatic include that script in the html. Maybe i will build it like that someday. But apparently for now, the best and easiest way is to add them to the html and pick it up from there.
but thanks for the response!
Level 9
Just trying to set this up myself with the same issue. The way I see it is:
- The compiled JS runs in the browser.
- The compiled JS needfs access to an environment variable, so it asks teh browser.
- The browser needs the server-side environment variable value to give to the pusher library in the compiled JS.
- So the page layout view must be the arbitrator:L the layout template takes an environment variable and puts it into the DOM through a small amount of JS in the layout template.
I just need to work out the details of how this works, but am just putting this out there, because it seems very few tutorials or articles seem able to explain this simple flow.
Level 80
@consil If you compile your JavaScript files then yeah, the environment variable value at that time will be “baked” in to the generated file. This is why you should only be running build scripts in the environment you intend to use those files. If you compile on a staging server, but copy the file to a production server, the file is going to have the staging server’s values, because that’s where it was built.
If, for some reason, you’re unable to build files on the environment they’re going to be deployed to then as a workaround you can “inject” variables in a JavaScript object in your Blade layout:
<script>
window.app = window.app || {};
window.app.config = window.app.config || {};
window.app.config.pusher = window.app.config.pusher || {
app_id: "{{ config('broadcasting.connections.pusher.app_id') }}",
host: "{{ config('broadcasting.connections.pusher.options.host') }}",
// And so on...
};
</script>
Just obviously be wary about any sensitive configuration values, like passwords and secrets, as these will be viewable with a simple view-source. The same goes for if you do inject environment variable values in your JavaScript using Mix; those values are getting bundled in a public-accessible file, so will be viewable to all users.
Please or to participate in this conversation.