Hi Paulo!
If the application has only one backend we always infer it in the login
function. If it isn't, the client needs to provide one explicitly.
Why not pass the single auth backend into the login function? It makes
the design and the documentation much simpler.
--
unai
--
You receive
Hi Paulo,
On 05/22/2015 02:42 PM, Paulo Gabriel Poiati wrote:
> I completely agree with the API design, it can be improved. What I'm
> really trying here is to keep things simple.
>
> I don't see that importance in keeping the authentication backend
> information in the http session (maybe I'm mi
Tks Carls,
I completely agree with the API design, it can be improved. What I'm really
trying here is to keep things simple.
I don't see that importance in keeping the authentication backend
information in the http session (maybe I'm missing something), we can
always use some kind of audit to han
> On May 22, 2015, at 3:07 PM, Carl Meyer wrote:
>
> Hi Paulo,
>
> On 05/22/2015 01:49 PM, Paulo Gabriel Poiati wrote:
>> I understand your points Carl, but I'm more inclined to think about the
>> average django developer and the new comers. Most people don't know or
>> don't want to know what
Hi Paulo,
On 05/22/2015 01:49 PM, Paulo Gabriel Poiati wrote:
> I understand your points Carl, but I'm more inclined to think about the
> average django developer and the new comers. Most people don't know or
> don't want to know what an Authentication Backend is, they just want to
> write their a
I understand your points Carl, but I'm more inclined to think about the
average django developer and the new comers. Most people don't know or
don't want to know what an Authentication Backend is, they just want to
write their app. That is why I don't like exposing this kind of detail in
the client
On 05/22/2015 09:44 AM, Tim Graham wrote:
> Could you elaborate on what use case you are trying to solve?
>
> On Friday, May 22, 2015 at 11:36:21 AM UTC-4, poiati wrote:
>
> Hello guys,
>
> I want to discuss the current login workflow in django. As it is we
> need to call `authentica
Here is a related ticket for doing this in tests, where frankly I don't
care about authentication. https://code.djangoproject.com/ticket/20916
On 22 May 2015 at 17:30, Paulo Gabriel Poiati
wrote:
> Good point James,
>
> It make sense if you could login the user without the credentials
> (proposa
Good point James,
It make sense if you could login the user without the credentials
(proposal).
On Fri, May 22, 2015 at 1:21 PM James Brewer
wrote:
> Hey Paulo,
>
> As you mentioned, the raw password should still be present in the form,
> along with the username. You can use these as parameters
One advantage of authenticate() is that it isn't coupled to a request and
is roughly stateless. Maybe an authenticate_and_login() would be nice. :)
On Friday, May 22, 2015 at 12:21:15 PM UTC-4, James Brewer wrote:
>
> Hey Paulo,
>
> As you mentioned, the raw password should still be present in th
Hey Paulo,
As you mentioned, the raw password should still be present in the form,
along with the username. You can use these as parameters for
`authenticate()`.
More to your original point, I would be interested in knowing why
`authenticate()` and `login()` are separate methods. There is no
info
Maybe this is not the perfect example because we have the plain password in
the form. Another one is if a backoffice user can log as any user of the
system.
On Fri, May 22, 2015 at 12:53 PM Paulo Gabriel Poiati <
paulogpoi...@gmail.com> wrote:
> Of course Tim,
>
> One instance is if you need to l
Of course Tim,
One instance is if you need to login the user after registration:
class RegistrationView(CreateView):
...
def form_valid(self, form):
user = form.save()
login(self.request, user)
# redirect
I don't have the user password because it's an one way has
Could you elaborate on what use case you are trying to solve?
On Friday, May 22, 2015 at 11:36:21 AM UTC-4, poiati wrote:
>
> Hello guys,
>
> I want to discuss the current login workflow in django. As it is we need
> to call `authenticate` before `login` because we need to set the
> authenticati
Hello guys,
I want to discuss the current login workflow in django. As it is we need to
call `authenticate` before `login` because we need to set the
authentication backend in the user model. We can use login without
authenticate if we set the backend attr manually, but this need some
implementati
I do squash one app at a time:
- squash and commit
- remove old migrations, "replaces", and fixing names in dependencies - and
commit
- optimize squash: remove RunPython/RunSQL, then play with operations order
to merge all possible operations - and commit optimized version
The problem is that i
Yep, the issue I've been having is squashing more than one app. Once I've
got my head around it, i'll write it up and poss submit a documentation
ticket to help
On 22 May 2015 at 12:05, Piotr Maliński wrote:
> It should allow squash all migrations of one app without any dependencies
> issues. Sq
It should allow squash all migrations of one app without any dependencies
issues. Squashing may have problems if a model was created and later
removed or when removing RunPython/SQL operations or when reordering
operations to make the optimizer merge them into less operations (like
getting bad
Amen to 3 and 3a - that's been proving one of the fiddliest aspects when
there are lots of migrations to squash - trial-end-error checking of how
many you can get away with squashing in one go while avoiding dependency
issues from other apps
On Thursday, May 21, 2015 at 11:08:42 AM UTC+1, Piotr
19 matches
Mail list logo
