Used a plain HTML form for DjangoProject login

[bmispelon]

Fixes #95, #61 and #60
Also possibly #100 and #64

The new unified login page looks like this (not the prettiest I must admit):

There's 3 things I'd like to do before merging this:

• Validate the html/css with the accessibility team
• Address the TODO about checking the redirection URL after login
• Add some tests

[knyghty]

@django/accessibility to review

Apparently I'm not allowed to request review in this repo.

[bmispelon]

@felixxm ready for review I think.

I got feedback from @knyghty on discord that it would be better to use form.as_div() but that will only become available in Django 4.1 so I'll have to come back to it then.

I started a small test suite for the new PlainLoginComponent and plugged it in to CI but my knowledge of github actions is pretty limited so if you see anything weird there it's probably ignorance on my part and you should definitely flag it.

I've split the PR into 2 commits where the first one just move files around while the second one is the actual interesting bit.

[felixxm]

I merged the first commit in 84a01a0 and pushed noshadows tests to the #172.

[bmispelon]

I'll rebase this once #172 is merged 👍🏻

[bmispelon]

Rebased and ready to review @felixxm 🕵🏻

[felixxm]

I'd use a non-blank default, e.g.

Suggested change

	SECRET_KEY = str(SECRETS.get("secret_key", ""))
	SECRET_KEY = SECRETS.get("secret_key", "django-insecure-secret")

Also, str() seems unnecessary.

[bmispelon]

My idea was to prevent accidentally running a known secret key in production which is why I used an empty default.

Isn't it the case that Django will refuse to start if it detects an empty secret key?

[felixxm]

Right, sorry I was thinking we have test settings here 😅

[felixxm]

but str() is still unnecessary

[bmispelon]

but str() is still unnecessary

Most likely yes, unless you use an integer in your secrets.json but then you had it coming 😅

[felixxm]

@bmispelon Looks great, thanks 👍