date:20181109

Updating date field using signals

2018-11-09 Thread pastrufazio

Hi all,

I have a very simple Profile class:

class Profile(models.Model):
  user = models.OneToOneField(User, on_delete=models.CASCADE)
  location = models.CharField(max_length=30, blank=True)
  birth_date = models.DateTimeField(null=True, blank=True)
  date_activation = models.DateTimeField(null=True, blank=True)


I want to set date_activation = datetime.now the first time the user login.
I tried using "user_logged_id" signal, without success:

@receiver(user_logged_in, sender=User)
  def user_logged_in_callback(sender, user, request, **kwargs):

Profile.objects.filter(get_user(request)).update(date_activation=datetime.now)



Testing it I get this errore message below.
Any help or suggestions would be greatly appreciated!


TypeError at /admin/login/ 

int() argument must be a string, a bytes-like object or a number, not 
'ModelBase'

Request Method: POST 
Request URL: http://localhost:4000/admin/login/?next=/admin/ 
Django Version: 1.11.16 
Exception Type: TypeError 
Exception Value: 

int() argument must be a string, a bytes-like object or a number, not 
'ModelBase'

Exception Location: 
/usr/local/lib/python3.6/site-packages/django/db/models/fields/__init__.py 
in get_prep_value, line 966 
Python Executable: /usr/sbin/uwsgi 
Python Version: 3.6.5 
Python Path: 

['.',
 '',
 '/code',
 '/usr/local/lib/python3.6/site-packages',
 '/usr/lib/python3.6/site-packages',
 '/usr/lib/python36.zip',
 '/usr/lib/python3.6',
 '/usr/lib/python3.6/lib-dynload']





-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fd7793b7-305a-4916-bae8-e8de687be346%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating date field using signals

2018-11-09 Thread Michael Manfre

This mailing list is for the development of the Django Framework. Questions
related to its usage should be posted to the django-users mailing list.

Regards,
Michael Manfre

On Fri, Nov 9, 2018 at 6:51 AM  wrote:

> Hi all,
>
> I have a very simple Profile class:
>
> class Profile(models.Model):
>   user = models.OneToOneField(User, on_delete=models.CASCADE)
>   location = models.CharField(max_length=30, blank=True)
>   birth_date = models.DateTimeField(null=True, blank=True)
>   date_activation = models.DateTimeField(null=True, blank=True)
>
>
> I want to set date_activation = datetime.now the first time the user login.
> I tried using "user_logged_id" signal, without success:
>
> @receiver(user_logged_in, sender=User)
>   def user_logged_in_callback(sender, user, request, **kwargs):
>
> Profile.objects.filter(get_user(request)).update(date_activation=datetime.now)
>
>
>
> Testing it I get this errore message below.
> Any help or suggestions would be greatly appreciated!
>
>
> TypeError at /admin/login/
>
> int() argument must be a string, a bytes-like object or a number, not 
> 'ModelBase'
>
> Request Method: POST
> Request URL: http://localhost:4000/admin/login/?next=/admin/
> Django Version: 1.11.16
> Exception Type: TypeError
> Exception Value:
>
> int() argument must be a string, a bytes-like object or a number, not 
> 'ModelBase'
>
> Exception Location: 
> /usr/local/lib/python3.6/site-packages/django/db/models/fields/__init__.py
> in get_prep_value, line 966
> Python Executable: /usr/sbin/uwsgi
> Python Version: 3.6.5
> Python Path:
>
> ['.',
>  '',
>  '/code',
>  '/usr/local/lib/python3.6/site-packages',
>  '/usr/lib/python3.6/site-packages',
>  '/usr/lib/python36.zip',
>  '/usr/lib/python3.6',
>  '/usr/lib/python3.6/lib-dynload']
>
>
>
>
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/fd7793b7-305a-4916-bae8-e8de687be346%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBuHP_w%3Do0d2kVd9YSLeFC3g2xfPozCRWtG6m2N%2BonssDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

skipping elidable migrations

2018-11-09 Thread Dan Watson

Hi All,

I was wondering if anyone had any thoughts on an option to the "migrate"
command (--skip-elidable?) that would skip running elidable migrations. The
use case here is that data migrations that build up over time may act on
certain assumptions (existing tables/data) that may not be true when
migrating a new database. It seems that since they were explicitly marked
as able to be deleted when squashing, they would be safe to not run when
creating a new database. Maybe we don't go so far as to make this the
default behavior when migrating a fresh database, but an option would be
nice. I realize you could simply squash your migrations, but that's not
without penalty of code churn, testing, etc. especially when your existing
migration graph is otherwise fine (and performant).

If there's some consensus about this being worthwhile, or at least no
strong objections to it, I can take a stab at the implementation.

Regards,
Dan

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/fba7a58a-444b-4c90-b139-151580423366%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Allow skipping CSRF check for Referer header

2018-11-09 Thread Aaron Hill

Currently, Django's CSRF middleware will reject any 'non-safe' HTTPS
request that lacks a Referer header:
https://github.com/django/django/blob/22e8ab02863819093832de9f771bf40a62a6bd4a/django/middleware/
csrf.py#L242

However, some users may prevent their browsers from sending the Referer
header, due to privacy concerns. These users are unable to submit
'non-safe' requests (e.g. POST requests) on HTTPS-enabled Django-powered
website that use CSRF protection.

For some websites, checking the Referer header may provide no added
security benefit. For example, an HSTS-preloaded website which controls all
of its subdomains has nothing to gain from this check - there are no
untrusted subdomains which can mount an attack, and HSTS prevents an HTTP
MITM attack.

To allow these websites to provide more flexibility to their users, Django
should support disabling this CSRF Referer check. This could be done
through a new setting, e.g. ' CSRF_REFERER_CHECK' (defaulting to 'True' to
avoid breaking existing sites).

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/bcc04352-cd39-485a-83ad-49d0608d6ccd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow skipping CSRF check for Referer header

2018-11-09 Thread Adam Johnson

I also discovered a similar problem recently when deploying the
"Referrer-Policy" header using James Bennett's library:
https://django-referrer-policy.readthedocs.io/en/stable/ . Initially I
opted for 'no-referrer' as I figured it was the most secure, but since this
check is only done on HTTPS-enabled sites, it wasn't discovered that all
forms were broken until production where HTTPS is used.

I think the existence of Referrer-Policy bolsters the argument for this
option, since some users might want to use 'no-referrer'. And in fact the
current check presumes the Referrer Policy is left at the default,
no-referrer-when-downgrade , and I'm pretty sure other values than
no-referrer break it as well.

+1 from me (I wonder if it could even be automatic if HSTS is enabled?)

On Fri, 9 Nov 2018 at 21:31, Aaron Hill  wrote:

> Currently, Django's CSRF middleware will reject any 'non-safe' HTTPS
> request that lacks a Referer header: 
> https://github.com/django/django/blob/22e8ab02863819093832de9f771bf40a62a6bd4a/django/middleware/
> csrf.py#L242
>
> However, some users may prevent their browsers from sending the Referer
> header, due to privacy concerns. These users are unable to submit
> 'non-safe' requests (e.g. POST requests) on HTTPS-enabled Django-powered
> website that use CSRF protection.
>
> For some websites, checking the Referer header may provide no added
> security benefit. For example, an HSTS-preloaded website which controls all
> of its subdomains has nothing to gain from this check - there are no
> untrusted subdomains which can mount an attack, and HSTS prevents an HTTP
> MITM attack.
>
>
> To allow these websites to provide more flexibility to their users, Django
> should support disabling this CSRF Referer check. This could be done
> through a new setting, e.g. ' CSRF_REFERER_CHECK' (defaulting to 'True'
> to avoid breaking existing sites).
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/bcc04352-cd39-485a-83ad-49d0608d6ccd%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM30D7GhDuLa6JFbgMgBZC5FqmFFDf%3D%3DhFvQbXdhXdPdgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Updating date field using signals

Re: Updating date field using signals

skipping elidable migrations

Allow skipping CSRF check for Referer header

Re: Allow skipping CSRF check for Referer header

5 matches

Site Navigation

Mail list logo

Footer information