Managing Keys | Python for Beginners [40 of 44]


>>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.

Add a Comment

Your email address will not be published. Required fields are marked *