Very little beyond what you already know. Keep in mind that every Model or CBV you create is a subclass of a parent class that you are modifying for your own purposes.
As the scope of what you’re looking to do for this is what I would refer to as "narrow and well-defined’, I’d probably take a direct approach.
- Create a model to contain the indicator of whether logins are required or not.
- Create your admin page to allow for that indicator to be changed
- Create the subclass for LoginRequiredMixin (Start by reviewing the source for it in django.contrib.auth.mixins - the mixin is only about 7 lines long.)
- Change the
dispatch method to have the check for
is_authenticated to only be performed if your indicator defined above is set to do so
- Alternative to the above - don’t subclass it, since this mixin only contains one function, and you’re replacing it. Just create a new class inheriting from AccessMixin with your new
- Change all your views to use your new mixin
A change of terminology is necessary here.
This example isn’t “passing”
UserPassesTestMixin here, it’s defining a new class, inheriting from both
view. It’s then overriding the
test_func method within that class. And it’s not a classmethod - it’s not tagged as such and it’s accepting self as the first argument. (This, in general, is actually a pretty good example of what needs to be done for the
As an example, don’t take what’s being done in the
test_func literally. That function needs to return a True/False value, where True will allow the view to be executed.
Not at all.
First, this is performed on a per-view basis, exactly like the
LoginRequiredMixin as described in my first response. So this would only apply to those views in which it’s being used.
Second, this specific implementation still requires that the user be logged in. They still needed to provide a valid username/password combination. That’s the only way that
request.user is going to be populated with an object having an email address.
While I referenced just a specific section of that page in the docs, understanding how authentication works does require an understanding of that entire page with some other pages in the docs - along with a pretty good understanding of Python classes.
“Attack” is precisely the right word here. If any of those vulnerabilities are discovered and subsequently exploited, then they’re usually able to gain root access to that system.
Are they interested in your content? Probably not.
But what they are interested in is using your computer for their own purposes -
- Crypto mining
- Distribution of illegal materials
- As another bot to be used for DDoS attacks against different hosts
- As another bot to be used to continue to sniff for vulnerable targets
- As a base for making attacks against specific targets
Depending upon how/where you host your server, this could end up
- Costing you some significant amount of money (e.g. AWS),
- Or legal fees if your host was discovered as part of an attack against a different host. You might be “not guilty”, but you’re still going to need to pay your lawyer.
- Causing your host to be shut down due to violations of your Terms and Conditions,
- Having your host blocked by any number of other sites
Most of these attacks are not against Django-related URLs, other than “/admin”. They’re typically against basic PHP-related urls or a small handful of specific frameworks such as Wordpress.
They’re also regularly probing for standard ports such as ssh, smtp (imap, pop3), and other services typically exposed to the world. (If you have ssh access to your host, are you checking those logs for attacks?)
I aggressively use fail2ban to block access to hosts attempting to access any of those known urls or ports - my ban list is sitting just less than 500 ip addresses. The point is, securing a host exposed to the internet requires a lot more than just protecting Django.
Yep - I see that. Seems reasonable for this specific situation.
But, to round this out -
Depending upon the context, I do it with groups of 15 - 20 on an occasional basis. (I used to do some teaching on a fairly regular basis. I’d have to create student accounts that would need to be good for a week.) If not hand-written, I’ll print the information either on the back of business cards or on an index card. Takes what - 5 minutes? Usernames can follow a simple pattern, and depending upon the expected life for these accounts, the password doesn’t need to be all that secure.