My web app is built on top of Pinax. My problem has two parts.
Part one
The default LoginForm does not provide a reCaptcha field. To check brute-force attempts I would like to include one, but for this I would need to supply my own sub-class of LoginForm.
From the source it seems like I can pass form_class as extra options to the included urls conf, but then this would set my version of form as the form_class for signup view too. That is unfortunate. Is there any other way?
Part two
Second part of the problem is that I want to enhance the user experience. So, I would like to present the reCaptch field only when the users fails to authenticate for the third consecutive times. For this to work, I am considering keeping a failed attempt counter in the user session. The problem is how do get reference to session object from the __init__() of the form?
Is there anyway I can achieve this without modifying Pinax code?
Related
Firstly, sorry if the question is so obviously (I'm quite newbie). I have a Django project where the user can add or remove, for example, interests to his/her profile (ManyToMany relationship). I've achieve this with 3 views. The first one where the profile's interests are rendered, the second one to add (nothing is rendered, when the user click a link, the view just update the profile and return the first view, the one with the profile's interests) and the third one to remove interest.
urls.py
path('home/overview/add/<int:interest_pk>', add_view, name="add_view"),
views.py
def add_view(request,interest_pk): #the third (the one to remove) view is similar
user = request.user
user.profile.interests.add(Category.objects.filter(pk= category_pk).get())
return redirect('overview') #Overview is the view where the interests are rendered
This works but now I'd like to improve this making it asynchronously. So here is my question, should I use Django Rest Framework to handle this kind of request (the ones related to the POST and DELETE methods) or is there any other method?
Note: I'm not using forms to send the information (I'd rather not to use it because it's simpler to send in an url the pk of the interest and handle it in a view) and I think it could be achieved using only requests. (Correct me if I'm wrong)
I have a lot of apps running on my site and I was wanting to make all the views accept a certain kwarg without having to go in and edit them all manually? Is there a way to do this?
I suppose I should add it into the django base view class somewhere, but I am unsure exactly where to add it to in that?
Any ideas?
EDIT:
What I am trying to do is have translations set in my db under a certain model and then have the site default text areas be displayed in a certain language based on the url...
/eng/some/url
/esp/some/url
those two urls would display different languages, but I have to capture the variable and put it into each and every view which is quite cumbersome
Django already has some i18n support in urls, check it out. You need to activate django.middleware.locale.LocaleMiddleware by adding it to your settings.MIDDLEWARE_CLASSES and to tune your urlconf a bit by wrapping your urls with i18n_patterns.
The complete example is given in the docs, I see no sense copying it here.
Django noob here - I was recently pointed to django-all-auth for registering/handling users, which I'm finding awesome in its near instant setup.
However I'm stumbling at trying to implement multiple user profile models. In reading other answers I've found this to be the closest answer thus far, but not really what I need.
When coding my own basic registration the user would select an account type (basic, pro, elite for example - each being their own profile model). Depending on the link selected the signup form would display both the generic User registration form as well as the profile form of the type chosen by the user.
I know I can go so far as to completely customize all-auth and make something like this work, but I'm hoping to be pointed in a direction that involves less wrecking of the original app. I've thought about having user redirected after signup to choose a profile type, but that seems to be a lot of extra steps.
Thanks for the help!
To extend the basic user class, just subclass AbstractUser. You can find that in the docs. With this you can add the fields your basic user is missing.
Now, you want several types of profiles with different fields, or perhaps the same fields but adding new fields every time.
You can create something like:
class ProfileBase(models.Model):
user=models.OneToOneField(User)
class ProfilePro(ProfileBase):
pro_field=models.SomeField(Foo)
#You can extend ProfilePro here if you want it to include the pro_field
class ProfileElite(ProfileBase):
elite_field=models.someField(Bar)
Once you have these models creating the forms should be easy.
Be aware, when you subclass this way django creates 1 table per model, including on the subclass table only the new fields. This makes necessary a join per level of inheritance so try not to abuse that.
There is a second way to use inheritance:
class ProfileBase(models.Model):
user=models.OneToOneField(User)
class Meta:
abstract=True
If you define the base class as abstract you won't have a table for it, so you can't create objects for that model, but each of your subclasses will be on it's own table. If you do it this way you may need extra logic to handle cases when user changes of type of profile (i.e. went from pro to elite).
To keep this separated from django-allauth, just finish the registration (create a form and in your settings define ACCOUNT_SIGNUP_FORM_CLASS to override all-auth default with your basic info + pick a profile type form) and once your user is logged in, redirect them to their profile to finish the process.
My situation is as follows.
I have a django app that is a CMS, and this one app generates page content and menus.
There is 'default' view that generates all the page content. One of the fields of the main model is designed to limit the visibility of pages depending on the setting:
'internal' (limited to users on our network),
'worldwide' (viewable by the www) and now, I would like to add an extra value
'secure', which would limit viewing only to those who are logged in to the site.
I dont think #login_required would work, as it only works on whole functions.
We want the author or editor to be able to set this flag, rather than code a special function; and there will be instances where a page migrates from 'internal' to 'secure' then to 'worldwide' - so ideally the urls should stay the same.
What is the best way to go about this?
thanks in advance... patrick
As you want the flag set on your object, I'm assuming that flag can't be read until you're already within the view (i.e. you won't be storing it in something accessible by the request object, like a session), so that precludes custom decorators. You could choose to go with something a bit crude but workable like this:
if (val=="internal" and inrange(request.META['REMOTE_ADDR'])) or (val=="secure" and request.user.is_authenticated()) or val=="worldwide":
return render_to_response .... etc.
else:
return HttpResponseForbidden()
Substituting your model values, and writing the inrange function, naturally.
The more sophisticated approach, though, would be to write custom middleware and use the process_view() function. See the docs for more details.
While I am studying the new django docs on class-based views, I notice this example code:
# forms.py
from django import forms
class ContactForm(forms.Form):
name = forms.CharField()
message = forms.CharField(widget=forms.Textarea)
def send_email(self):
# send email using the self.cleaned_data dictionary
pass
The fact of seeing send_email as a method of ContactForm really annoys me. I have always thought form methods should be for validation purpose and methods that consume forms (like send_email in this case) should be in the views layer. Am I missing anything here? Or should the example be corrected?
There is no correct answer for this one. It really depends on your coding style. Using a form for more than just validation is as valid as doing this method in the view.
The above example has some kind of advantage though. Lets say you have one model and you want to use different forms (with different logic) for it. Instead of putting the logic in the view and check which form is now used it probably better to put this logic on the form level.
The first time I got the same weird feeling was when I encountered the LoginForm from django.contrib.auth that also verifies that the user's browser is capable of working with cookies aside from managing the credentials passed in.
Personally, I agree with you. I'm more inclined to think that the view should be the responsible actor for performing the action of sending the email rather than the form and that send_email should be a method defined in the view.
But, then again, you can easily observe how a lot of us use Django differently or have a different approach to solving the same problems. Due to the fact that we have different concerns in mind when developing our applications, it's quite possible we have a different understanding of how certain framework components are meant to be used, which is a bit of a moot point. In the end, what's important to acknowledge is that it's possible to delegate some of the heavy-lifting from the view to the form in a manner that's well-defined.
There is nothing wrong with the example. For any but the simplest of cases, your form will contain only cleaning methods; most forms do extra validation and other actions. In the end, it is just a Python class and you can do whatever you would like in it; there is no "rule" except maybe DRY.
We have form methods that validate against external services, call other procedures and trigger workflows. For such complicated logic, it is best to embed it in to the form class as it increases reusability of the code. Developers working on the view simply use the form class as a library and don't have to worry about exotic validation requirements. In this case, it actually promotes DRY.
When we have to update the logic we only update the form class's "private" methods (those prefixed with _). This keeps the "public" interface (documented by django) intact and all view code using that form doesn't have to be updated.