Re: Proposal: Manually login without authenticate

[Unai Zalakain]

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 received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150522210155.GC26209%40def.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Proposal: Manually login without authenticate

[Carl Meyer]

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 missing something),

It is possible to have multiple authentication backends with overlapping
user IDs; some backends may not return User objects that exist in
Django's User table. A user (in the broader authentication backend
sense) is uniquely defined only by both the authentication backend and
the ID; using only the ID could result in the wrong user being loaded
from the wrong backend on a subsequent request.

> we can
> always use some kind of audit to handle this kind of information.

I'm not sure what this means.

> Let's think straight, we don't need to tell the Auth Backend if
> settings.AUTHENTICATION_BACKENDS has only one element.
> 
> So, I have a new proposal:
> 
> 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.

I don't have a problem with defaulting to the only backend, if there is
only one.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/555F9725.504%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Proposal: Manually login without authenticate

[Paulo Gabriel Poiati]

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 handle this kind of information.

Let's think straight, we don't need to tell the Auth Backend if
settings.AUTHENTICATION_BACKENDS has only one element.

So, I have a new proposal:

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.

On Fri, May 22, 2015 at 5: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 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 code. I mean, we can add an optional param to
> > login (backend) for people like you and me but IMO it shouldn't
> > be mandatory and we should fallback to the backend iteration if it isn't
> > specified.
>
> Logging a user in without authenticating them first is an advanced
> technique with serious security implications. If someone "doesn't know
> or doesn't want to know what an Authentication Backend is," then they
> have no business doing this, and we should absolutely make it very hard
> for them to do it without learning about authentication backends first.
>
> Which backend is persisted with the user in the session is not a minor
> implementation detail. It's critical information, because it determines
> how and from where that user will be loaded on future requests, which
> could have wide-ranging effects on their permissions and authorization.
>
> I agree with you that the current system of annotating the user object
> with an attribute that usually isn't present is bad API, and that it
> would be good to have a supported, documented API for this use case. But
> I strongly disagree with you that the backend is an implementation
> detail which should be hidden in this API. The backend should be more
> visible in this API than it is now, not less visible.
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/555F8C7A.4010507%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABqSV%3DJeg86cLRX9zq-YKdgakJUU9UieO9co0Ajzx2UL7ZdvoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Manually login without authenticate

[Ryan Hiebert]

> 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 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 code. I mean, we can add an optional param to
>> login (backend) for people like you and me but IMO it shouldn't
>> be mandatory and we should fallback to the backend iteration if it isn't
>> specified.
> 
> Logging a user in without authenticating them first is an advanced
> technique with serious security implications. If someone "doesn't know
> or doesn't want to know what an Authentication Backend is," then they
> have no business doing this, and we should absolutely make it very hard
> for them to do it without learning about authentication backends first.
> 
> Which backend is persisted with the user in the session is not a minor
> implementation detail. It's critical information, because it determines
> how and from where that user will be loaded on future requests, which
> could have wide-ranging effects on their permissions and authorization.
> 
> I agree with you that the current system of annotating the user object
> with an attribute that usually isn't present is bad API, and that it
> would be good to have a supported, documented API for this use case. But
> I strongly disagree with you that the backend is an implementation
> detail which should be hidden in this API. The backend should be more
> visible in this API than it is now, not less visible.

I agree completely.

The couple times I've found myself muddling through creating an auth backend, 
I've had a hard time figuring out what needs to go in the login view, and what 
should be in the authentication backend. I think that making it clearer what 
the distinction is between login() and authenticate() is would help that 
immensely, and making it clear that the backend need not be set by authenticate 
would also make it clearer.

Ryan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/500FF35F-4039-4BF6-B36A-5129C48235C8%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Manually login without authenticate

[Carl Meyer]

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 app. That is why I don't like exposing this kind of detail
> in the client code. I mean, we can add an optional param to
> login (backend) for people like you and me but IMO it shouldn't
> be mandatory and we should fallback to the backend iteration if it isn't
> specified.

Logging a user in without authenticating them first is an advanced
technique with serious security implications. If someone "doesn't know
or doesn't want to know what an Authentication Backend is," then they
have no business doing this, and we should absolutely make it very hard
for them to do it without learning about authentication backends first.

Which backend is persisted with the user in the session is not a minor
implementation detail. It's critical information, because it determines
how and from where that user will be loaded on future requests, which
could have wide-ranging effects on their permissions and authorization.

I agree with you that the current system of annotating the user object
with an attribute that usually isn't present is bad API, and that it
would be good to have a supported, documented API for this use case. But
I strongly disagree with you that the backend is an implementation
detail which should be hidden in this API. The backend should be more
visible in this API than it is now, not less visible.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/555F8C7A.4010507%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Proposal: Manually login without authenticate

[Paulo Gabriel Poiati]

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 code. I mean, we can add an optional param to login (backend) for
people like you and me but IMO it shouldn't be mandatory and we should
fallback to the backend iteration if it isn't specified.



On Fri, May 22, 2015 at 2:14 PM Carl Meyer  wrote:

> 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 `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 implementation knowledge of how authentication backends
> works.
>
> I've run into this more than once in an OAuth or SSO situation, where
> I've got confirmation from the identity provider of the user's identity
> and I just want to log them in, no further authentication necessary.
> Usually I just manually annotate the user with a `backend` attribute and
> then call `login`, but I agree with Paulo that login's dependence on
> that annotation is a bad API.
>
> I don't prefer Paulo's proposal of "just try all backends", though; I
> think it's best if any user persisted in the session is always persisted
> along with explicit knowledge of which auth backend should be used to
> fetch that user in future requests. Failing to do that could potentially
> result in security problems, I think, depending on details of the
> configured auth backends.
>
> What I would suggest instead is to add an optional `backend` argument to
> `login`, defaulting to `None`. If provided, that argument would always
> be used, and the `backend` annotation on the user would not be required
> or even checked.
>
> At some point, I could see possibly deprecating the `user.backend`
> annotation system entirely, in favor of having `authenticate` return a
> (user, backend) tuple, and passing the backend explicitly through the
> form back to the login view and into the `login` function. I think that
> would be better, but it would also be much more invasive and require
> deprecation paths on several APIs, so may not be worth it.
>
> In any case, adding the optional `backend` argument to `login` is a
> small step in that direction that doesn't introduce any
> backwards-incompatibility and makes the "manually log a user in" use
> case much more straightforward.
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/555F63F8.3070007%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABqSV%3DJ9pOwStSViZAn9PyuxWncEy48%2BKLT5YLJZ%2BhNwtid1VA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Manually login without authenticate

[Carl Meyer]

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 `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 implementation knowledge of how authentication backends works.

I've run into this more than once in an OAuth or SSO situation, where
I've got confirmation from the identity provider of the user's identity
and I just want to log them in, no further authentication necessary.
Usually I just manually annotate the user with a `backend` attribute and
then call `login`, but I agree with Paulo that login's dependence on
that annotation is a bad API.

I don't prefer Paulo's proposal of "just try all backends", though; I
think it's best if any user persisted in the session is always persisted
along with explicit knowledge of which auth backend should be used to
fetch that user in future requests. Failing to do that could potentially
result in security problems, I think, depending on details of the
configured auth backends.

What I would suggest instead is to add an optional `backend` argument to
`login`, defaulting to `None`. If provided, that argument would always
be used, and the `backend` annotation on the user would not be required
or even checked.

At some point, I could see possibly deprecating the `user.backend`
annotation system entirely, in favor of having `authenticate` return a
(user, backend) tuple, and passing the backend explicitly through the
form back to the login view and into the `login` function. I think that
would be better, but it would also be much more invasive and require
deprecation paths on several APIs, so may not be worth it.

In any case, adding the optional `backend` argument to `login` is a
small step in that direction that doesn't introduce any
backwards-incompatibility and makes the "manually log a user in" use
case much more straightforward.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/555F63F8.3070007%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Proposal: Manually login without authenticate

[Marc Tamlyn]

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
> (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 for
>> `authenticate()`.
>>
>> More to your original point, I would be interested in knowing why
>> `authenticate()` and `login()` are separate methods. There is no
>> information on this in the docs (that I could find). Is there a use case
>> where you want to authenticate a user without logging them in?
>>
>> On Fri, May 22, 2015 at 8:57 AM, Paulo Gabriel Poiati <
>> paulogpoi...@gmail.com> wrote:
>>
>>> 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 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 hash and thus I 
 can't call `authenticate`. The only solution I can think is hacking the 
 auth system (setting the backend manually in the user model).


 On Fri, May 22, 2015 at 12:44 PM 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 `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
>> implementation knowledge of how authentication backends works.
>>
>> *PROPOSAL*
>>
>> *django.contrib.auth.login*
>> Only set the backend in the http session if the user has the attr.
>>
>> request.session[SESSION_KEY] = user._meta.pk.value_to_string(user)
>> request.session[HASH_SESSION_KEY] = session_auth_hashif hasattr(user, 
>> 'backend'):
>> request.session[BACKEND_SESSION_KEY] = user.backend
>>
>>
>> *django.contrib.auth.get_user*
>>
>> If the backend is not set iterate over all the backends in 
>> `settings.AUTHENTICATION_BACKENDS` and return the first found.
>>
>>
>> I can think in two drawbacks of this implementation but as far as my 
>> knowledge goes neither of them is a big deal.
>>
>>
>> - Performance, in the worst case we are trying all the backends this can 
>> take some time depending on the backend provider.
>>
>>
>> - Two backends can share the same user identifier and thus we will be 
>> using the first declared in the settings.
>>
>>
>> What do you guys think?
>>
>>
>> Thanks,
>>
>> Paulo Poiati.
>>
>>
>>
>>
>>
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to
> django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/fbbd5579-a5e9-4370-8943-75204f334016%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>>
>> To view this discussion on the web visit
>>> 

Re: Proposal: Manually login without authenticate

[Paulo Gabriel Poiati]

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 for
> `authenticate()`.
>
> More to your original point, I would be interested in knowing why
> `authenticate()` and `login()` are separate methods. There is no
> information on this in the docs (that I could find). Is there a use case
> where you want to authenticate a user without logging them in?
>
> On Fri, May 22, 2015 at 8:57 AM, Paulo Gabriel Poiati <
> paulogpoi...@gmail.com> wrote:
>
>> 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 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 hash and thus I 
>>> can't call `authenticate`. The only solution I can think is hacking the 
>>> auth system (setting the backend manually in the user model).
>>>
>>>
>>> On Fri, May 22, 2015 at 12:44 PM 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 `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
> implementation knowledge of how authentication backends works.
>
> *PROPOSAL*
>
> *django.contrib.auth.login*
> Only set the backend in the http session if the user has the attr.
>
> request.session[SESSION_KEY] = user._meta.pk.value_to_string(user)
> request.session[HASH_SESSION_KEY] = session_auth_hashif hasattr(user, 
> 'backend'):
> request.session[BACKEND_SESSION_KEY] = user.backend
>
>
> *django.contrib.auth.get_user*
>
> If the backend is not set iterate over all the backends in 
> `settings.AUTHENTICATION_BACKENDS` and return the first found.
>
>
> I can think in two drawbacks of this implementation but as far as my 
> knowledge goes neither of them is a big deal.
>
>
> - Performance, in the worst case we are trying all the backends this can 
> take some time depending on the backend provider.
>
>
> - Two backends can share the same user identifier and thus we will be 
> using the first declared in the settings.
>
>
> What do you guys think?
>
>
> Thanks,
>
> Paulo Poiati.
>
>
>
>
>
>
>  --
 You received this message because you are subscribed to the Google
 Groups "Django developers (Contributions to Django itself)" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to django-developers+unsubscr...@googlegroups.com.
 To post to this group, send email to django-developers@googlegroups.com
 .
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/fbbd5579-a5e9-4370-8943-75204f334016%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CABqSV%3D%2B5Vr%2B-JC2_yXdzwUpj9Y%2B1XwNOKf3_Fhc5h%3Dw4kuK%2BpQ%40mail.gmail.com
>> 
>> .
>
>
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed 

Re: Proposal: Manually login without authenticate

[Collin Anderson]

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 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 
> information on this in the docs (that I could find). Is there a use case 
> where you want to authenticate a user without logging them in?
>
> On Fri, May 22, 2015 at 8:57 AM, Paulo Gabriel Poiati  > wrote:
>
>> 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 <
>> paulog...@gmail.com > wrote:
>>
>>> 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 hash and thus I 
>>> can't call `authenticate`. The only solution I can think is hacking the 
>>> auth system (setting the backend manually in the user model).
>>>
>>>
>>> On Fri, May 22, 2015 at 12:44 PM 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 `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 
> implementation knowledge of how authentication backends works.
>
> *PROPOSAL*
>
> *django.contrib.auth.login*
> Only set the backend in the http session if the user has the attr.
>
> request.session[SESSION_KEY] = user._meta.pk.value_to_string(user)
> request.session[HASH_SESSION_KEY] = session_auth_hashif hasattr(user, 
> 'backend'):
> request.session[BACKEND_SESSION_KEY] = user.backend
>
>
> *django.contrib.auth.get_user*
>
> If the backend is not set iterate over all the backends in 
> `settings.AUTHENTICATION_BACKENDS` and return the first found.
>
>
> I can think in two drawbacks of this implementation but as far as my 
> knowledge goes neither of them is a big deal.
>
>
> - Performance, in the worst case we are trying all the backends this can 
> take some time depending on the backend provider.
>
>
> - Two backends can share the same user identifier and thus we will be 
> using the first declared in the settings.
>
>
> What do you guys think?
>
>
> Thanks,
>
> Paulo Poiati.
>
>
>
>
>
>
>  -- 
 You received this message because you are subscribed to the Google 
 Groups "Django developers (Contributions to Django itself)" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to django-develop...@googlegroups.com .
 To post to this group, send email to django-d...@googlegroups.com 
 .
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/fbbd5579-a5e9-4370-8943-75204f334016%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CABqSV%3D%2B5Vr%2B-JC2_yXdzwUpj9Y%2B1XwNOKf3_Fhc5h%3Dw4kuK%2BpQ%40mail.gmail.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received 

Re: Proposal: Manually login without authenticate

[James Brewer]

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
information on this in the docs (that I could find). Is there a use case
where you want to authenticate a user without logging them in?

On Fri, May 22, 2015 at 8:57 AM, Paulo Gabriel Poiati <
paulogpoi...@gmail.com> wrote:

> 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 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 hash and thus I can't 
>> call `authenticate`. The only solution I can think is hacking the auth 
>> system (setting the backend manually in the user model).
>>
>>
>> On Fri, May 22, 2015 at 12:44 PM 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 `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
 implementation knowledge of how authentication backends works.

 *PROPOSAL*

 *django.contrib.auth.login*
 Only set the backend in the http session if the user has the attr.

 request.session[SESSION_KEY] = user._meta.pk.value_to_string(user)
 request.session[HASH_SESSION_KEY] = session_auth_hashif hasattr(user, 
 'backend'):
 request.session[BACKEND_SESSION_KEY] = user.backend


 *django.contrib.auth.get_user*

 If the backend is not set iterate over all the backends in 
 `settings.AUTHENTICATION_BACKENDS` and return the first found.


 I can think in two drawbacks of this implementation but as far as my 
 knowledge goes neither of them is a big deal.


 - Performance, in the worst case we are trying all the backends this can 
 take some time depending on the backend provider.


 - Two backends can share the same user identifier and thus we will be 
 using the first declared in the settings.


 What do you guys think?


 Thanks,

 Paulo Poiati.






  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/fbbd5579-a5e9-4370-8943-75204f334016%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABqSV%3D%2B5Vr%2B-JC2_yXdzwUpj9Y%2B1XwNOKf3_Fhc5h%3Dw4kuK%2BpQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at 

Re: Proposal: Manually login without authenticate

[Paulo Gabriel Poiati]

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 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 hash and thus I can't 
> call `authenticate`. The only solution I can think is hacking the auth system 
> (setting the backend manually in the user model).
>
>
> On Fri, May 22, 2015 at 12:44 PM 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 `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
>>> implementation knowledge of how authentication backends works.
>>>
>>> *PROPOSAL*
>>>
>>> *django.contrib.auth.login*
>>> Only set the backend in the http session if the user has the attr.
>>>
>>> request.session[SESSION_KEY] = user._meta.pk.value_to_string(user)
>>> request.session[HASH_SESSION_KEY] = session_auth_hashif hasattr(user, 
>>> 'backend'):
>>> request.session[BACKEND_SESSION_KEY] = user.backend
>>>
>>>
>>> *django.contrib.auth.get_user*
>>>
>>> If the backend is not set iterate over all the backends in 
>>> `settings.AUTHENTICATION_BACKENDS` and return the first found.
>>>
>>>
>>> I can think in two drawbacks of this implementation but as far as my 
>>> knowledge goes neither of them is a big deal.
>>>
>>>
>>> - Performance, in the worst case we are trying all the backends this can 
>>> take some time depending on the backend provider.
>>>
>>>
>>> - Two backends can share the same user identifier and thus we will be using 
>>> the first declared in the settings.
>>>
>>>
>>> What do you guys think?
>>>
>>>
>>> Thanks,
>>>
>>> Paulo Poiati.
>>>
>>>
>>>
>>>
>>>
>>>
>>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/fbbd5579-a5e9-4370-8943-75204f334016%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABqSV%3D%2B5Vr%2B-JC2_yXdzwUpj9Y%2B1XwNOKf3_Fhc5h%3Dw4kuK%2BpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Manually login without authenticate

[Paulo Gabriel Poiati]

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 hash and thus I
can't call `authenticate`. The only solution I can think is hacking
the auth system (setting the backend manually in the user model).


On Fri, May 22, 2015 at 12:44 PM 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 `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
>> implementation knowledge of how authentication backends works.
>>
>> *PROPOSAL*
>>
>> *django.contrib.auth.login*
>> Only set the backend in the http session if the user has the attr.
>>
>> request.session[SESSION_KEY] = user._meta.pk.value_to_string(user)
>> request.session[HASH_SESSION_KEY] = session_auth_hashif hasattr(user, 
>> 'backend'):
>> request.session[BACKEND_SESSION_KEY] = user.backend
>>
>>
>> *django.contrib.auth.get_user*
>>
>> If the backend is not set iterate over all the backends in 
>> `settings.AUTHENTICATION_BACKENDS` and return the first found.
>>
>>
>> I can think in two drawbacks of this implementation but as far as my 
>> knowledge goes neither of them is a big deal.
>>
>>
>> - Performance, in the worst case we are trying all the backends this can 
>> take some time depending on the backend provider.
>>
>>
>> - Two backends can share the same user identifier and thus we will be using 
>> the first declared in the settings.
>>
>>
>> What do you guys think?
>>
>>
>> Thanks,
>>
>> Paulo Poiati.
>>
>>
>>
>>
>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/fbbd5579-a5e9-4370-8943-75204f334016%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABqSV%3D%2BKR_-rtrjswULVN2shOnvig9YPSsSaBj%2BYi5oDog%3DpHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Manually login without authenticate

[Tim Graham]

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 
> authentication backend in the user model. We can use login without 
> authenticate if we set the backend attr manually, but this need some 
> implementation knowledge of how authentication backends works.
>
> *PROPOSAL*
>
> *django.contrib.auth.login*
> Only set the backend in the http session if the user has the attr.
>
> request.session[SESSION_KEY] = user._meta.pk.value_to_string(user)
> request.session[HASH_SESSION_KEY] = session_auth_hashif hasattr(user, 
> 'backend'):
> request.session[BACKEND_SESSION_KEY] = user.backend
>
>
> *django.contrib.auth.get_user*
>
> If the backend is not set iterate over all the backends in 
> `settings.AUTHENTICATION_BACKENDS` and return the first found.
>
>
> I can think in two drawbacks of this implementation but as far as my 
> knowledge goes neither of them is a big deal.
>
>
> - Performance, in the worst case we are trying all the backends this can take 
> some time depending on the backend provider.
>
>
> - Two backends can share the same user identifier and thus we will be using 
> the first declared in the settings.
>
>
> What do you guys think?
>
>
> Thanks,
>
> Paulo Poiati.
>
>
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fbbd5579-a5e9-4370-8943-75204f334016%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal: Manually login without authenticate

[Paulo Gabriel Poiati]

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
implementation knowledge of how authentication backends works.

*PROPOSAL*

*django.contrib.auth.login*
Only set the backend in the http session if the user has the attr.

request.session[SESSION_KEY] = user._meta.pk.value_to_string(user)
request.session[HASH_SESSION_KEY] = session_auth_hashif hasattr(user,
'backend'):
request.session[BACKEND_SESSION_KEY] = user.backend


*django.contrib.auth.get_user*

If the backend is not set iterate over all the backends in
`settings.AUTHENTICATION_BACKENDS` and return the first found.


I can think in two drawbacks of this implementation but as far as my
knowledge goes neither of them is a big deal.


- Performance, in the worst case we are trying all the backends this
can take some time depending on the backend provider.


- Two backends can share the same user identifier and thus we will be
using the first declared in the settings.


What do you guys think?


Thanks,

Paulo Poiati.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABqSV%3DLQUSa1Sv2V%2BYLibtvv7V32PxBB5%3DPP1-aOWuUa%2B14LAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ideas for migrations squashing improvements

[Piotr Maliński]

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 it works for a clean DB but for existing playing with 
dependencies names etc makes squashes not recognizable as squashes and thus 
database errors as things exist.


W dniu piątek, 22 maja 2015 13:17:49 UTC+2 użytkownik Steve Jalim napisał:
>
> 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. 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 order for FK, M2M operations).
>>
>>
>> W dniu piątek, 22 maja 2015 10:49:11 UTC+2 użytkownik Steve Jalim napisał:
>>>
>>> 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 Maliński wrote:

 I made some tricky migration squashing in few projects recently. It 
 works but still could be made better. 

 1. squashed migrations could have explicit flag indicating that it's a 
 squash-initial migration. More complex squashes or optimizing squash can 
 lead to problems when it will not fake but try to apply on existing 
 database. Global --fake isn't a handy solutions for some deployment 
 solutions. Or just fake every 0001* migration if any other 0001* migration 
 was applied for given app in the past.
 2. there could be a "resquash" option that would not make a squash of a 
 squash but just optimize operations if possible for given squash 
 (application with one migration that is a squash).
 3. there could be a "testmigrations" command/option that would try to 
 migrate everything on a test database (or just given application with 
 dependencies) - similar to running some test just to get the migrations 
 going.
 3a. As a bonus - check if database schema is the same when migrated 
 with old squash versus new optimized squash.

  -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/vtf-4II-rEo/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/31f44414-b1f6-4451-810e-6505deb1db9e%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2c104f86-4cd2-42c6-b446-2293b9631a65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ideas for migrations squashing improvements

[Steve Jalim]

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. 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 order for FK, M2M operations).
>
>
> W dniu piątek, 22 maja 2015 10:49:11 UTC+2 użytkownik Steve Jalim napisał:
>>
>> 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 Maliński wrote:
>>>
>>> I made some tricky migration squashing in few projects recently. It
>>> works but still could be made better.
>>>
>>> 1. squashed migrations could have explicit flag indicating that it's a
>>> squash-initial migration. More complex squashes or optimizing squash can
>>> lead to problems when it will not fake but try to apply on existing
>>> database. Global --fake isn't a handy solutions for some deployment
>>> solutions. Or just fake every 0001* migration if any other 0001* migration
>>> was applied for given app in the past.
>>> 2. there could be a "resquash" option that would not make a squash of a
>>> squash but just optimize operations if possible for given squash
>>> (application with one migration that is a squash).
>>> 3. there could be a "testmigrations" command/option that would try to
>>> migrate everything on a test database (or just given application with
>>> dependencies) - similar to running some test just to get the migrations
>>> going.
>>> 3a. As a bonus - check if database schema is the same when migrated with
>>> old squash versus new optimized squash.
>>>
>>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/vtf-4II-rEo/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/31f44414-b1f6-4451-810e-6505deb1db9e%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADJx9E9ySVJYvGM5rNKyeyz6ZKjbyOm_KHeJdXOzbXsvgprjwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ideas for migrations squashing improvements

[Piotr Maliński]

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 order for FK, M2M operations).

W dniu piątek, 22 maja 2015 10:49:11 UTC+2 użytkownik Steve Jalim napisał:
>
> 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 Maliński wrote:
>>
>> I made some tricky migration squashing in few projects recently. It works 
>> but still could be made better. 
>>
>> 1. squashed migrations could have explicit flag indicating that it's a 
>> squash-initial migration. More complex squashes or optimizing squash can 
>> lead to problems when it will not fake but try to apply on existing 
>> database. Global --fake isn't a handy solutions for some deployment 
>> solutions. Or just fake every 0001* migration if any other 0001* migration 
>> was applied for given app in the past.
>> 2. there could be a "resquash" option that would not make a squash of a 
>> squash but just optimize operations if possible for given squash 
>> (application with one migration that is a squash).
>> 3. there could be a "testmigrations" command/option that would try to 
>> migrate everything on a test database (or just given application with 
>> dependencies) - similar to running some test just to get the migrations 
>> going.
>> 3a. As a bonus - check if database schema is the same when migrated with 
>> old squash versus new optimized squash.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/31f44414-b1f6-4451-810e-6505deb1db9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ideas for migrations squashing improvements

[Steve Jalim]

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 Maliński wrote:
>
> I made some tricky migration squashing in few projects recently. It works 
> but still could be made better. 
>
> 1. squashed migrations could have explicit flag indicating that it's a 
> squash-initial migration. More complex squashes or optimizing squash can 
> lead to problems when it will not fake but try to apply on existing 
> database. Global --fake isn't a handy solutions for some deployment 
> solutions. Or just fake every 0001* migration if any other 0001* migration 
> was applied for given app in the past.
> 2. there could be a "resquash" option that would not make a squash of a 
> squash but just optimize operations if possible for given squash 
> (application with one migration that is a squash).
> 3. there could be a "testmigrations" command/option that would try to 
> migrate everything on a test database (or just given application with 
> dependencies) - similar to running some test just to get the migrations 
> going.
> 3a. As a bonus - check if database schema is the same when migrated with 
> old squash versus new optimized squash.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ba0832f2-51df-47e4-89e9-5c46d3ad6e29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.