PasswordResetConfirmView doesn't work through redirect in newest Safari
Hi all, Recently we've upgraded a project from Django 2.x to 2.1, which meant upgrading our old reset password functions based views to the newer class based models. However, since the change we're experiencing issues with PasswordResetConfirmView. What we experiencing, in short, is that when we send our mails through Mandrill (the SMTP service from Mailchimp), and the user presses the reset password link, they get an error saying the link is invalid/expired. This happens only if the customer goes through the Mandrill redirect link AND uses the newest stable version of Safari shipping with macOS Mojave or the newest iOS versions. I've been digging through the code, and it seems that the session framework/cookie framework simply isn't working when going through that particular redirect link. When the user lands on the first page in the confirmation view (which includes the full token), they get "None" as their sessionid. Just before the redirect (where the token is put into session, and replaced with "set password"), they get an actual sessionid - but when they're redirected to the "set-password" page, they now have a new sessionid, which of course means PasswordResetConfirmView cannot find their token in session storage, leading to the error message. While I realise this might not be an issue with Django, and rather the way Mandrill deals with their redirection of links/some weird inner-workings in Safari, I'm wondering how other people have dealt with this issue. Any help appreciated :) -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6e017023-1fbd-4f22-8a03-53499c05497b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: PasswordResetConfirmView doesn't work through redirect in newest Safari
Ah darn it - I didn't even think of checking the bug tracker first. Usually when we're experiencing things like this it's because we've messed up somehow :) I guess for now we'll see if we can backport the old function based view which didn't do that redirect straight after landing on the page with the reset token, in order for the tracking prevention to not kick in. Thanks! tirsdag den 29. januar 2019 kl. 21.49.12 UTC+1 skrev Jason: > > You're not the only one with this issue. > > django-developer discussion at > https://groups.google.com/forum/#!topic/django-developers/RyDdt1TcH0c > There's an open ticket on the django bug tracker at > https://code.djangoproject.com/ticket/29975 > and related on webkit: https://bugs.webkit.org/show_bug.cgi?id=193502 > > Unfortunately, doesn't seem to be much action on this. It really is a > breaking change with Safari. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/b99f7cab-f4a0-456d-977c-4234b1b11994%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
How to remove a model definition completely in Django when it previously had foreign keys
We're trying to remove a model completely from one of our apps - an operation I think we've done many times without issues, but this time it's causing us some headache. Consider we have two apps: An app called a with a model A An app called b with a model B, and this model B has a foreign key to A. This means the initial Django migration file for app b contains an entry for a foreign key to the string 'a.A'. Let's call this step 1. Now later, we remove the foreign key on model B. This of course creates a new migration, but the initial migration still has the 'a.A' foreign key definition in it (obviously). Let's call this step 2. Now the tricky part: we want to remove the whole model A. This in itself creates a migration for app a to that deletes the model, but poses a new problem; when running the full migration history (for example during tests), the initial migration of app b will fail, because it can no longer resolve 'a.A'. Let's call this step 3. How are people coping with the issue the best? One solution I can think of involves doing a migration squash (and would be sort of easy in our case, since we're actually going to remove the whole app a as well), but it seems a bit extreme. Is there anyone out there with a better and less intrusive solution? Regards, Henrik Ossipoff Hansen -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/162da80d-ca64-48d1-b555-4ce44d6040aa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to remove a model definition completely in Django when it previously had foreign keys
Yes, when running tests (which happen on a clean database), the migration history is run all from the initial migrations (by Django itself). At this point, app b's initial migration (which have a reference to a.A) will fail because it cannot find such model: ValueError: Related model 'a.A' cannot be resolved fredag den 8. marts 2019 kl. 15.23.51 UTC+1 skrev Clara Daia: > > Are you getting an error? I think migration dependencies should solve that > by themselves, running "step 2" before "step 3". Doesn't Django complain if > you try to migrate "step 3" before "step 2"? > > Em sex, 8 de mar de 2019 às 11:07, Henrik Ossipoff Hansen < > henrik@gmail.com > escreveu: > >> We're trying to remove a model completely from one of our apps - an >> operation I think we've done many times without issues, but this time it's >> causing us some headache. Consider we have two apps: >> >> An app called a with a model A >> An app called b with a model B, and this model B has a foreign key to A. >> >> This means the initial Django migration file for app b contains an entry >> for a foreign key to the string 'a.A'. Let's call this step 1. >> >> Now later, we remove the foreign key on model B. This of course creates a >> new migration, but the initial migration still has the 'a.A' foreign key >> definition in it (obviously). Let's call this step 2. >> >> Now the tricky part: we want to remove the whole model A. This in itself >> creates a migration for app a to that deletes the model, but poses a new >> problem; when running the full migration history (for example during >> tests), the initial migration of app b will fail, because it can no longer >> resolve 'a.A'. Let's call this step 3. >> >> How are people coping with the issue the best? One solution I can think >> of involves doing a migration squash (and would be sort of easy in our >> case, since we're actually going to remove the whole app a as well), but it >> seems a bit extreme. Is there anyone out there with a better and less >> intrusive solution? >> >> Regards, >> Henrik Ossipoff Hansen >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-users...@googlegroups.com . >> To post to this group, send email to django...@googlegroups.com >> . >> Visit this group at https://groups.google.com/group/django-users. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/162da80d-ca64-48d1-b555-4ce44d6040aa%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-users/162da80d-ca64-48d1-b555-4ce44d6040aa%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/236407fc-b903-4504-b31b-952fb9f0c47b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
