0
I have a Django application that registers a user, using the Django User table.
Everything of that scope is working but there have to be restrictions.
When accessing username1 account and username2 already has registration the user accesses username2 data and can edit something that should not happen.
thus:
http://localhost:8000/perfil/1/ # <=== logado
just change
http://localhost:8000/perfil/2/ #< === todos os dados podem ser editado pelo username1
Have to block if access in html something like, not tested is just a Noob question
{% if user.id == user.id %}
{{form.as_p}}
{% endif %}
I am using BCV
Here’s the code:
from django import forms
from django.contrib.auth.models import User
from django.contrib.auth.forms import UserCreationForm
class ContaForms(UserCreationForm):
class Meta:
model = User
fields = [
'username', 'first_name', 'email', 'password1', 'password2'
]
class PerfilForms(forms.ModelForm):
class Meta:
model = User
fields = ['username', 'first_name', 'email']
and the view tbm:
from django.views.generic import CreateView, TemplateView, UpdateView
from django.contrib.auth.models import User
from .forms import PerfilForms, ContaForms
from django.urls import reverse_lazy
from django.contrib.auth.mixins import LoginRequiredMixin
class ContaVIEW(CreateView):
template_name = 'registro/conta.html'
form_class = ContaForms
success_url = reverse_lazy('login')
class PerfilVIEW(LoginRequiredMixin, UpdateView):
template_name = 'registro/login.html'
model = User
form_class = PerfilForms
login_url = reverse_lazy('login')
redirect_field_name = reverse_lazy('login')
success_url = reverse_lazy('home')
class HomeVIEW(LoginRequiredMixin, TemplateView):
template_name = 'registro/home.html'
login_url = reverse_lazy('login')
redirect_field_name = reverse_lazy('login')
Does it have any mixins that does this authorization ?
in the documentation speaks of some such
The most common solution is that there is no route
/perfil/1/
, but yes only/perfil/
.. This way there is never a choice of which user is being edited, always obliging to be the logged in user. Instead of taking the user ID from the URL, just take the session withrequest.user
in the view.– fernandosavio