>> In a prior video,
one of the things that Susan showed off
was how to call an external API.
Now, whatever you call an external API,
you're going to need some form of
a key or a password or otherwise,
and this allows you to prove to
that external service that you're
calling that you are who you say you are,
and if there's like some form of billing or otherwise
that the service then knows who to charge,
and that's fine and dandy.
When Susan went in and she did her little demo,
she put the key that she was going to need
inside of the Python source code.
For a simple little demo,
for a simple little proof of concept,
for a file that's never going to be
published to anywhere, that's fine.
But for anything at all which is
honestly going to be
the vast majority of code that you're going to be working with,
that's potentially going to be shared with somebody else,
that's never a good practice.
That sharing a password or putting a password somewhere inside of
a clear text file that's going to be publicly
available is a bad idea for security purposes.
That's my little tip from me to you for today.
Now, you might be thinking well, dah Christopher.
Everybody knows this, and if you know this then that's fantastic.
That's wonderful.
But if you head out onto the web and you start searching around,
you'll actually find all sorts of stories,
of keys, of usernames and
passwords that have been shared out in source code
files out on GitHub publicly for the world to see.
That's bad. So as a result,
whenever we are working with any type of sensitive data,
we need to be careful about that data.
We need to ensure that that data is
going to be properly taken care of, and in particular,
that it's never going to be stored somewhere that's
publicly accessible in clear text.
So how do we do this?
Well, we do this through the use of environmental variables.
Now it might lead up to this.
I really focused in on just how to work with our secure values,
but environmental variables are not
just about things like passwords and keys.
They're actually also there for anything that might need to
change or otherwise from outside of your application.
So for example, when it comes time to connect to a database,
I'm going to need a connection string for that database.
What happens if that database moves?
What happens if that database is renamed?
I'm going to want to be able to change that value
without going back into the application to update that.
Or what happens if I need to be able
to read something from the operating system?
Maybe I need to figure out the current directory.
Maybe I need to figure out what operating system we're running on.
Who knows? Well, I don't want to hard code that in.
I want to be able to read that from
somewhere external to my application,
and that's where environmental variables come into play.
Now, your operating system
has a whole host of environmental variables.
They might be broken down into say system-level,
so it's for the operating system and user level,
so ones that are specific to you.
Might be other breakdowns from there.
Maybe you've created a couple that are specific to an application.
Who knows? But regardless,
the way that you're going to read them is going to be the same.
Now, what we'll do is we'll import
the OS library and then off of that OS library,
we're going to call little helper function called
getenv and then pass
in the name of this system
variable or environmental variable that we want.
In my case, I'm going to go grab the OS version,
and when I print this,
what this is going to do is this is going to print out Windows_NT.
Now this will read any system or
user environmental variable that has been set.
But as we mentioned previously,
there might be other things that we want to be able to
set that are external to our application.
Again, those database connection strings.
Again, those keys. Those passwords.
Those sensitive things that we want to be able to protect.
So how do we then manage those?
Well, it would technically be possible for you to go in and set
those system variables or maybe you
set it from the command line or otherwise.
For me personally, the way that I like to
manage this is through.env..env is
a package that has a version available for I think
basically every major programming environment
that if you're doing node,
if you're doing C Sharp,
if you're doing [inaudible] ,
that there's going to be a version of.env available to you.
Now what's great about.env is it gives you the opportunity
to set and store
those environmental variables inside of a text file.
So this way you never hard code anything.
This way you're not checking in
those sensitive values into your source control.
That what you do after you grab that.env package,
and we've already seen how to do packages.
You create a.env file,
and this.env file is literally nothing,
but key value pairs.
You set your key and then you set your value,
and then what you'll do inside of your code is,
you'll just simply import in that load_dotenv function from.env,
you'll then call that before you do anything and then you go
grab your environmental variables
the same way that you would normally.
Now, the one thing that I want to highlight here is
the fact that.env is really smart.
What it's going to do is it's going to look to see,
"Hey, was this set already externally?"
If it was, then it will read it from there.
If it wasn't, then it will go look at your text file.
Now, the reason that that's important
is because let's say that I'm going to take my application,
maybe it's a web app and I'm going to deploy this out to
another computer to a server and have it run up there.
On that server, I'm going to set those environmental variables.
I'm going to go in and specify what my keys are,
what my database connection string is etc.
I'm not going to do that through text files.
I'm going to do that through the settings for that server.
I leave in the exact same.env code.
So everything that you're seeing down below.
Everything that you're seeing inside of
here still remains in my deployed code.
I'm not going to deploy.env.
That.env is for local purposes only.
This for my local dev.
When I go to publish it out,
then I'm going to properly set my environmental variables.
Don't worry. I'll show you how to do that.
But my code remains the same,
and that's the great advantage to.env,
is that I can set everything
up that I'm going to need for dev purposes,
and then when I'm ready to publish my code,
my code does not change.
Again, as I mentioned before.env,
there's a version of that for
every programming language that you might be interested in using.
So to review all of this,
some final notes; don't hard code sensitive information ever.
Simplest way to handle this which will work for
most applications that you're going to be working
on is to use.env.
Then if you are going to use.env and you're using
say Git to manage your source code,
makes sure that you add that.env file to your gitignore.
Make sure that you do that so you don't
accidentally publish this out.
Now, if this is truly sensitive data where if this came out,
it would be completely catastrophic
to our application or to our business,
then you may want to consider something that's
going to be more robust than.env,
there is a solution available in Azure that's called
Azure Key Vault that you can go ahead
and check out, and that's fine.
You can go ahead and investigate that.
But like I said, for a lot of the things that you're
going to be working on,.env is
a good enough solution
and it's relatively straightforward to set up.
In fact, let's go in and take a look at that in the next module.