Committing Django private keys in portfolios is a problem? - django

I new at Django and created an e-commerce website just for portfolio purpose(I will not use it for sell anything real, at most i going to host it in some domain to show as a portfolio) and committed it in a public Github repository, then Github sent me an email telling me i committed the secret keys of Django, is there any problem with this? Do i need to delete the repository and generate another Secret Key?

It should be sufficient to make sure that the committed key is not used in production by exchanging the deployed key. You don't need to delete the whole repository if you want to delete a single file and remove it from the version history. You can use this guide here to do so: https://docs.github.com/en/github/authenticating-to-github/removing-sensitive-data-from-a-repository
Following some best practices (e.g., https://12factor.net/) you should not have the secret key directly inside your settings.py but rather use an environment variable for this.

Related

Django uploading to Github, any important variables besides secret_key to keep a secret/protect?

I'm new to Django just started learning it today, since I am quite proficient in express/nodejs and mongodb, I know there are some variables that one should not push to github as they can contain passwords and other identifying information. On express/node I create a .env file and add it to my .gitignore, typically containing the password to my mongodb connection.
I am about to push my first Django api project to github and want to know if there are any other information besides the "SECRET_KEY" that I should protect. Also is .env file still the best way to protect it in Django. Furthermore I have my Django project within a ll_env-virtual environment should it make a difference.
Besides SECRET_KEY there are some other variables like:
Database credentials (PASSWORD, etc)
If hosted on any cloud providers, their secret keys (AWS_SECRET_KEY)
If using Email service, there will be your mail specific password and etc.
In short every variables that you think are to be secured should be stored in a .env file.
Also for the ease of development and production you can store Debug variable.
Basically .env file contains the individual user environment variables when collaborative working. This article by djangocentral may help you know more.

Django Cookiecutter Database restore

I'm trying to restore the database with the maintenance script provided. But there is a check in the script which doesn't allow me to restore if the user is postgres.
Any reason for that ?
It is a custom to not use the postgres user in this case. Similar to the custom that when operating a linux server, you use a user account instead of the root account.
You can remove the passage from the script if you want to proceed anyway. However, cookiecutter-django should have generated a .env/.production/.postgres file with a different username than postgres.

Opencart Forbidden access after swapping to previous database

Good day,
I had created my online store on a VPS, I opted to move the store to a web hosting package. After installing opecart using softalicioucs the default installation worked fine. I then edited the config files in both admin and public_html to change the database to the original backup of my VPS.
Once I do this, "You don't have permission to access this resource. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request".
If I go back to the installed default database its all good again. I have set the necessary permissions etc for the user to access the backup database.
Anyone knows what is going on? is there some table storing access information?
After disabling MODSECURE I realised that the new installation created tables with prefixes not as my original interfaces, hence the solution was to change the prefix in the config file.

Would it be advisable to upload my Django Project to github?

I know that Django websites contain a secret key which is not to be disclosed to anyone. However, I really want to showcase my website on GitHub, as I feel it is nice. Unfortunately, I am worried about the secret key's security, and if it would be safe to upload that website to GitHub where everyone can see.
The website type is a personal portfolio website that showcases my projects and more.
So, would it be okay to upload my entire Django Project to GitHub? The only sensitive information I can think of would be my superuser information, and maybe my database, where I store all my project Models for displaying on the website. Pretty much all I know I need to guard is my superuser information
The django secret key should not be publicly available (see https://docs.djangoproject.com/en/2.0/ref/settings/#std:setting-SECRET_KEY)
Many sites use an environment variable to set the key.
So your settings file could have something like:
SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY', '')
Have a look at https://github.com/jpadilla/django-dotenv.
You can set your secret_key inside a .env file which you should add to your .gitignore. This means it will not be tracked or added to any git commit, hence, won't be shown in Github.

Using Django to Create Child Sites

I am creating a series of small sites, I'm using the django framework. The theory goes a user comes to a master site, signs up, then he gets his own child site.
Example:
navigate to example.com
user creates an account "mysite"
user then gets his own site: mysite.example.com and he can configure this all he wants
My question: * would it be better to have a "gold" version of the site that gets created for each site?
for instance: cp ~/goldsite ~/mysite and change the database pointers appropriately ** the downside is if I ever have to do maintenance on a file, I would have to change all subsites.
...or * have one host and configure the database to support multiple sites. The DB might get messy.
Any feedback would be great.
Use the same code/database for all the users, otherwise it would be a nightmare to maintain the code. Think about database migrations, backups, update the code with git...
...or * have one host and configure the database to support multiple sites. The DB might get messy.
It shouldn't be really complex, associate each website object with an user and use the permissions properly.