Add instructions to host the tutorial project on Glitch.com

[bcopy]

Changes in this pull request:

• Provide cloud IDE setup instructions for Glitch.com (a user-friendly free web hosting solution with an integrated web IDE and command line access)
• Add instructions on how to protect the Django secret inside a .env file.

[bcopy]

Hello,

We will be relying on these updates for our upcoming public event at CERN

https://home.cern/news/announcement/cern/registration-open-online-programming-workshop-django-girls

and we would like to translate it also to French, and have it ready for instruction on 8th April to train our 25 coaches.
Can someone review, comment, merge as required ?

[das-g]

Hi @bcopy

Cool that you're doing an online Django Girls workshop! (I have myself been involved as coach an later as co-organizer in past Django Girls workshops in Switzerland, though all of them in the German-speaking parts of it. 👋)

and have it ready for instruction on 8th April

That's two week from now. While I hope we can make it until then, please be prepared for the case we won't manage. (The tutorial currently has only few still-active maintainers and all of them work on it only in their free time.)

In case the change won't go through till then, you could generate the rendered version of your branch with Honkit and host it yourself (or on GitHub pages or something similar). The most simple approach for that is probably to activate GitHub pages for your fork and adapt the condition

tutorial/.github/workflows/deploy.yml

Line 10 in 57bba09

if: github.repository == 'djangogirls/tutorial'

in the existing GitHub action config.

[das-g]

Concerning putting the Django secret key into a .env file not tracked in Git: That's IMO a good idea, but can we somehow implement that independent of the development environment used, i.e., not only for Glitch.com?

[das-g]

Past and current issues and PRs regarding SECRET_KEY:

• Public production key being publicized on Github #802
• Security hardening on deployment (e.g. SECRET_KEY ends up on GitHub) #1192
• Minimal security warning in deploy chapter. cf #802 #1215
• "Secure your website" extension, covering eg keeping SECRET_KEY secure, etc tutorial-extensions#101
• Warning email from GitGuardian about SECRET_KEY #1687

It looks like the consensus until now was, that having the blatant (but probably not too serious) security issue of publishing the SECRET_KEY (and that of using the same one for development and production deployment) is more acceptable than rendering the Django Girls tutorial proper more complex, and that instead the actual solution should be presented in a (yet to be written) tutorial extension.

@bcopy Does Glitch.com require that this be handled properly right from the beginning? Can the approach you take be generalized to work with all presented development environment setups, including local development?

[bcopy]

Dear Raphael,

Thank you for looking into our PR.

Regarding SECRET_KEY the Django documentation is adamant that it needs to be secured. However, this is left entirely to the end user. There are many tutorials on how to secure Django, but as far as I could see, the Django framework team do not have any open issues concerning a potential securing of the settings.py parameters. So they consider that if you version control your Django project, you must edit your ignore configuration accordingly.

https://code.djangoproject.com/query?status=closed&status=new&description=~SECRET_KEY&desc=1&order=id

I agree that the tutorial should remain simple and securing concerns can certainly go in an extension.

Does Glitch.com require that this be handled properly right from the beginning?
Can the approach you take be generalized to work with all presented development
environment setups, including local development?

Yes, in the case of Glitch, the settings.py file needs to be updated immediately, as indicated, or the Django website will not work at all. The SECRET_KEY could be left until later, but while we're at it, it makes sense to take action immediately.

Thank you for your tips concerning regenerating the documentation into our Github Pages, I will apply it.

I would like to contribute French translations via Crowdin though - but maybe you also have a suggestion on how we can make some progress without waiting for a merge to master.

[bcopy]

Dear @das-g,
Thank you very much for your thorough review, I applied all your recommendations I believe, let me know what you think.

[das-g]

Thanks for making the adaptions and changes. Reading the result again, I've noticed some more things, most of them minor:

[bcopy]

Dear @das-g, applied the latest batch of changes, let me know if you can see more corrections.

[das-g]

Looks good to me now.

[das-g]

These changes are now already reflected in the English original on Crowdin, so translation can be done there.