We Keep Coding

How is "secret_key.txt" more secure in Django project?

I apologize if this is a duplicate question but I can't find an answer online. In Django Checklist Docs I see the following to keep secret key secure.
with open('/etc/secret_key.txt') as f:
SECRET_KEY = f.read().strip()
My project is deployed with AWS EBS.
I've created a separate file called "secret_key.txt" which holds the key. How is this more secure than keeping the key in the settings.py config file? If someone can access my projects settings.py file to access the key, would they not be able to access the "secret_key.txt" file as well? How is creating a "secret_key.txt" file more secure?
I've checked Google and Stack Overflow for reasoning but can't find an answer. Currently all sensitive information is protected using an .env file and including this file in .gitignore.

You usually add that file to the .gitignore, such that the file is not part of the (GitHub) repository. This means that you can add (other) settings in the project, and you load "sensitive" settings through environment variables, or files.
This hackernoon post for example, discusses four ways to define sensitive variables such that these are not defined in files that you add to the subversioning system.
Usually it is advisable to incude a settings.py in the project however, stripped from sensitive data. That way a peer can easily set up the project all the other (required) settings, and thus only has to define a limited number of sensitive variable to get the project running.
I think however using an environment variable might be better, since it is probably easier to specify this, and thus to manage a number of processes that all might work with different values.

Can someone explain to me (like I'm an idiot) what app.config does in Flask?

I have the following code in a Flask application
app = Flask(__name__)
app.config.from_object(app_config)
Session(app)
app_config.py is another file I have in my reposiotry with variables like CLIENT_ID, CLIENT_SECRET, AUTHORITY, and ENDPOINT. Can someone please explain to me what app.config does? And how configuration files work in general? Here is what the Flask documentation says:
class flask.Config(root_path, defaults=None)
Works exactly like a dict but provides ways to fill it from files or special dictionaries. There are two common patterns to populate the config.
Either you can fill the config from a config file:
app.config.from_pyfile('yourconfig.cfg')
Or alternatively you can define the configuration options in the module that calls from_object() or provide an import path to a module that should be loaded. It is also possible to tell it to use the same module and with that provide the configuration values just before the call:
DEBUG = True
SECRET_KEY = 'development key'
app.config.from_object(__name__)
In both cases (loading from any Python file or loading from modules), only uppercase keys are added to the config. This makes it possible to use lowercase values in the config file for temporary values that are not added to the config or to define the config keys in the same file that implements the application.
My main questions are what does it mean by "works exactly like a dict but provides ways to fill it form files or special dictionaries. Also what is the difference between a config file and a module?

For the record, if you're looking at this site, these are not the official Flask docs. Those are here.
Anyways, it's good practice to use config(uration) files (generally, overuse of config files is an anti-pattern) to keep things like user settings. Config files are not unique to Flask.
All that the text you've copied is saying is that Flask includes an app object that can be configured and hold certain variables, for things like API or database access, using app.config. You can also keep these in a config.py file. Read the last link for more clarity.

Django: closest possible to the project name

I am creating a reusable app that needs to know the name of the project from which it is being used. Getting the AppConfig (or just the app name) of the app with the settings module in it would be already sufficient. Other approaches are welcome as well.
Why would I ever want this:
Different projects will have portions of their data shared in the same db schema. I still need to figure out to which project does some of it belong. Project names are considered to be unique at this point, default app names are the same as the corresponding project names (django-admin startproject behavior).
Based on the previous experience, expecting the users of my app to specify something extra in their project settings is just not reliable enough.

You can get the project package name like this
import os
os.environ.get('DJANGO_SETTINGS_MODULE').split('.')[0]

Cache busting with Django

I'm working on a website built with Django.
When I'm doing updates on the static files, the users have to hard refresh the website to get the latest version.
I'm using a CDN server to deliver my static files so using the built-in static storage from Django.
I don't know about the best practices but my idea is to generate a random string when I redeploy the website and have something like style.css?my_random_string.
I don't know how to handle such a global variable through the project (Using Gunicorn in production).
I have a RedisDB running, I can store the random string in it and clear it on redeployment.
I was thinking to have this variable globally available in templates with a context_processors.
What are your thoughts on this ?

Django's built-in contrib.staticfiles app already does this for you; see ManifestStaticFilesStorage and CachedStaticFilesStorage.

Here's my work around :
On deployment (from a bash script), I get the shasum of my css style.
I put this variable inside the environment.
I have a context processor for the template engine that will read from the environment.

Django: Where to put helper functions?

I have a couple of functions that I wrote that I need to use in my django app. Where would I put the file with them and how would I make them callable within my views?

I usually put such app specific helper function in file utils.py and use someting like this
from myapp.utils import my_cool_func
def view_coolness(request):
data = my_cool_func(request)
return render_to_response("xxx.html")
but it depends what you helper does, may be they modify request , the could be part of middleware, so you need to tell what exactly those helper functions do

create a reusable app that include your generic functions so you can share between projects.
use for example a git repo to store this app and manage deployments and evolution (submodule)
use a public git repo so you can share with the community :)

If they are related to a specific app, I usually just put them in the related app folder and name the file, 'functions.py'.
If they're not specific to an app, I make a commons app for components (tests, models, functions, etc) that are shared across apps.

I am using new python file service.py in app folder. The file contains mostly helper queries for specific app. Also I used to create a folder inside Django application that contains global helper functions and constants.