Re: CharField with Oracle Backend Null Behaviour

[vafzal]

Hi Mariusz,

Thanks for getting back to me, didn't realise that default was empty 
strings, that would work too. With regards to existing projects, migration 
should be really straightforward, just need to add a constraint to db on 
the next migration. It would generate migrations where no model changes 
have been made, but I would be comfortable with that, just need to document 
it properly. 

Is there a mecanhism by which we can propose this change in a more formal 
manner?

Many Thanks,
Vackar

On Thursday, 8 November 2018 19:14:01 UTC, Mariusz Felisiak wrote:
>
> Hi,
>
> Oracle treats empty strings and NULLs in the same way, that's why we 
> had to decide on some workaround that will cover both python's (other Dbs') 
> cases i.e. NULLs and "" (see 
> https://docs.djangoproject.com/en/2.1/ref/databases/#null-and-empty-strings). 
> I don't see much value in changing current behavior from *"empty strings 
> always"* to *"NULLs always"*, because it will be backward incompatible 
> and IMO it doesn't change anything, still non-Oracle people will be 
> surprised by this behavior.
> I agree that creating a *"NOT NULL" *constraint in case when 
> "null=False*" *(or even "blank=False") may be a helpful addition to the 
> current behavior but I'm not sure how doable it is if we take into account 
> migration of existing projects.
>
> Best,
> Mariusz
>
> W dniu czwartek, 8 listopada 2018 18:33:52 UTC+1 użytkownik 
> vaf...@exscientia.co.uk napisał:
>>
>> Hi Florian,
>>
>> Yes you are correct, backwards compatibility would break with this 
>> change. 
>> As Django already mimics the required checks in middleware for nulls, 
>> only difference I can see going forward would be that newly inserted blank 
>> strings would be read back back as None, instead of '' if nulls are 
>> allowed. And where nulls are not allowed, neither would make it into the db.
>>
>> Look forward to hearing your thoughts Felix.
>>
>> Many Thanks,
>> Vackar
>>
>> On Thursday, 8 November 2018 17:06:05 UTC, Florian Apolloner wrote:
>>>
>>> Hi Vackar,
>>>
>>> Thank you, now we are getting somewhere!
>>>
>>> On Thursday, November 8, 2018 at 5:36:53 PM UTC+1, 
>>> vaf...@exscientia.co.uk wrote:

 My main concern currently is that required fields are not enforced at 
 the db level, which makes using it with other clients difficult. I would 
 much prefer that constraints be added, and accept that empty strings 
 cannot 
 be inserted into required columns.

>>>
>>> Okay, now I get you. I have no strong feelings how our oracle backend 
>>> should behave here; other than your suggested change would be (highly?) 
>>> backwards incompatible and that alone might prevent it from getting merged. 
>>> Maybe Felix can chime in here with his oracle knowledge.
>>>
>>> FWIW, Django has quite a few places where it does stuff in the framework 
>>> itself instead of at the database level. Examples include the handling of 
>>> database default values (we don't, defaults are in the application, even 
>>> for simple integers and strings) as well as handling of cascades on 
>>> deletes. If one cannot live with those issues, it is imo currently best to 
>>> manage the database independent from Django. We are certainly open to 
>>> improving in those areas though.
>>>
>>> Cheers,
>>> Florian
>>>
>>>
>>>

-- 
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/d8bf75ba-b33d-499c-b5b6-a75b759f75a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

normalizing newlines in form fields

[Jakub Kleň]

I'm thinking if it wouldn't be nice if django automatically normalized 
newlines of data entered by the user. The implementation would be really 
simple, there's already a function for it in 
django.utils.text.normalize_newlines, and it would go into 
django.forms.fields.CharField.to_python the same as split() (maybe also 
with an ivar for controlling the behavior, although I'm not sure if it's 
needed). What do you think?

-- 
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/98af1d0e-bc56-43db-988f-9ac083fd08f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: normalizing newlines in form fields

[Tim Graham]

Here's a ticket that was closed as wontfix. If you want it reconsidered, 
you should explain why you the think the arguments there aren't valid.
https://code.djangoproject.com/ticket/19251

On Monday, November 12, 2018 at 9:58:39 AM UTC-5, Jakub Kleň wrote:
>
> I'm thinking if it wouldn't be nice if django automatically normalized 
> newlines of data entered by the user. The implementation would be really 
> simple, there's already a function for it in 
> django.utils.text.normalize_newlines, and it would go into 
> django.forms.fields.CharField.to_python the same as split() (maybe also 
> with an ivar for controlling the behavior, although I'm not sure if it's 
> needed). What do you think?
>

-- 
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/586df399-3681-485f-8ee4-69505a3f1b58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: normalizing newlines in form fields

[Jakub Kleň]

Reason: Having consistent data representation in the database is nice, and 
maybe also useful in some use-cases, e.g. using the data to train a deep 
learning model. This tweak seems it could only help, and shouldn't break 
anything. If, for some reason a developer needs to use \r\n for display, he 
cannot rely on the client to always send \r\n in the form data, because OSX 
or unix sends just \n, so it seems to me that if I would need \r\n for 
display, It would also be nice to have just \n in the database, and replace 
it using a template filter during html construction.

On Monday, November 12, 2018 at 3:58:39 PM UTC+1, Jakub Kleň wrote:
>
> I'm thinking if it wouldn't be nice if django automatically normalized 
> newlines of data entered by the user. The implementation would be really 
> simple, there's already a function for it in 
> django.utils.text.normalize_newlines, and it would go into 
> django.forms.fields.CharField.to_python the same as split() (maybe also 
> with an ivar for controlling the behavior, although I'm not sure if it's 
> needed). What do you think?
>

-- 
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/74ef4827-1088-4f22-986c-efd38b94bb78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: normalizing newlines in form fields

[Jakub Kleň]

Regarding the link you sent, I also think that the current behaviour is 
inconsistent. I'm now not sure if we should go with \n, or \r\n, but I 
think we definitely should normalize this. If you are writing to files on 
windows, all your browsers would send \r\n over post, so the files would be 
generated properly, but as soon as you deploy, and the first client enters 
some data from OSX for example, you have a problem which you couldn't even 
notice before. What I'm trying to say here is that I think it's better if 
it was consistent, and you could catch the issue during implementation.

On Monday, November 12, 2018 at 3:58:39 PM UTC+1, Jakub Kleň wrote:
>
> I'm thinking if it wouldn't be nice if django automatically normalized 
> newlines of data entered by the user. The implementation would be really 
> simple, there's already a function for it in 
> django.utils.text.normalize_newlines, and it would go into 
> django.forms.fields.CharField.to_python the same as split() (maybe also 
> with an ivar for controlling the behavior, although I'm not sure if it's 
> needed). What do you think?
>

-- 
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/3c773fc0-7049-4d66-ae14-9a322e884774%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Simplify authentication backend interface

[Collin Anderson]

> Add default implementations for get_all_permissions() and has_perm(),
either in PermissionMixin or in a new BaseBackend class.
On a first glance, I think that makes sense to me.

> Also note that the separation between user and group permissions may not
be applicable with custom backends.
That also makes sense to me. It does seems like kind of an implementation
detail as to where the permission is actually coming from, though I think
that information could be useful in some cases, so somehow making it
optional would be nice.

On Sat, Nov 10, 2018 at 3:07 AM Tobias Bengfort 
wrote:

> I feel like the interface for authentication backends is unnecessarily
> complex: Basically, you only need authenticate() and has_perm(), but
> currently the interface also includes get_group_permissions(),
> get_all_permissions(), and has_module_perms().
>
> The architecture is like this: User inherits from PermissionMixin which
> implements the methods get_group_permissions(), get_all_permissions(),
> has_perm(), has_perms(), and has_module_perms().
>
> All of these methods basically just call the corresponding methods on
> the authentication backends, if available. has_perms() is the only
> exception, as it is just a shortcut to call has_perm() multiple times.
>
> I believe that has_perm() is vastly more important than
> get_*_permissions(). Still, I can understand that the latter exist. What
> I find confusing is that there is no get_user_permissions() in this
> interface. Whithout its counterpart, get_group_permissions() seems
> pretty much useless to me. Also note that the separation between user
> and group permissions may not be applicable with custom backends.
>
> Another issue is that developers can easily end up with inconsistent
> backends: There is no guarantee that get_all_permissions() will return a
> superset of get_group_permissions(). There is also no guarantee that
> has_perm() will be equivalent to `perm in get_all_permissions()`.
>
> Then there is the issue of has_module_perms(). As far as I understand,
> this should have been called has_app_perms(). It is used in
> contrib.admin where it makes a lot of sense, but I don't really see how
> it could be useful anywhere else.
>
> I looked at some popular backends to see how they are implemented:
>
> The default ModelBackend implements get_user_permissions() and
> get_group_permissions(). get_all_permissions() joins their results and
> has_perm() and has_module_perms() call get_all_permissions(). The
> results of get_all_permissions() are cached.
>
> django-guardian works pretty much the same. However, even though the
> mechanism is the same, get_group_permissions() is not exposed in the
> interface. has_module_perms() is missing.
>
> django-rules only implements has_perm(). get_*_permissions() are
> missing. has_module_perms() exists, but it is just an alias to
> has_perm().
>
> I guess the benefits of simplifying the interface do not justify
> breaking changes for most of these issues. However, I think there are
> two changes that could significantly improve the situation:
>
> -   Either add get_user_permissions() or remove get_group_permissions()
> -   Add default implementations for get_all_permissions() and
> has_perm(), either in PermissionMixin or in a new BaseBackend class.
>
> Any thoughts?
>
> tobias
>
> --
> 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/9eb25389-d59e-1f6c-4b50-d1c7a986f923%40posteo.de
> .
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S4SKCkN3X_-Hw4gWhVd2AHd8hZN6X2phEy0RriiiuMV8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow skipping CSRF check for Referer header

[Collin Anderson]

Aas a data point, I've customized my csrf checking to skip the referrer
checking if there's a correct origin header. Though yes, it doesn't work in
some browsers. (I haven't set up Referrer-Policy so that hasn't been an
issue for me yet.)

I think it's worth mentioning too that same-site cookies are starting to
get a lot of browser support and could be an alternative csrf protection:
https://caniuse.com/#feat=same-site-cookie-attribute

>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).
I think this could make sense as long as it's well documented what the
requirements are to stay secure, and maybe a clear example of the attack
vector.



On Sat, Nov 10, 2018 at 10:47 AM Florian Apolloner 
wrote:

> Not neccessarily, one could still use the Origin header in cases where
> software strips the Referer and if you set the Referrer-Policy to
> same-origin you shouldn't have problems with firefox either.
>
> On Saturday, November 10, 2018 at 1:42:41 PM UTC+1, Adam Johnson wrote:
>>
>> I would think that feature flag rules it out for a long time?
>>
>> On Sat, 10 Nov 2018 at 09:52, Florian Apolloner 
>> wrote:
>>
>>> Wouldn't one alternative be checking the Origin header? It appears
>>> though that all browsers support it with the sad exception that it is still
>>> behind a feature flag in Firefox. :/ (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1424076)
>>>
>>> On Saturday, November 10, 2018 at 1:03:08 AM UTC+1, Adam Johnson wrote:

 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@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 (C

Re: normalizing newlines in form fields

[Collin Anderson]

Maybe the newline character could be part of the setting, something like
normalize_newlines_to='\n'. And then just do a
normalize_newlines_to.join(value.splitlines()) could work.

On Mon, Nov 12, 2018 at 10:49 AM Jakub Kleň  wrote:

> Regarding the link you sent, I also think that the current behaviour is
> inconsistent. I'm now not sure if we should go with \n, or \r\n, but I
> think we definitely should normalize this. If you are writing to files on
> windows, all your browsers would send \r\n over post, so the files would be
> generated properly, but as soon as you deploy, and the first client enters
> some data from OSX for example, you have a problem which you couldn't even
> notice before. What I'm trying to say here is that I think it's better if
> it was consistent, and you could catch the issue during implementation.
>
> On Monday, November 12, 2018 at 3:58:39 PM UTC+1, Jakub Kleň wrote:
>>
>> I'm thinking if it wouldn't be nice if django automatically normalized
>> newlines of data entered by the user. The implementation would be really
>> simple, there's already a function for it in
>> django.utils.text.normalize_newlines, and it would go into
>> django.forms.fields.CharField.to_python the same as split() (maybe also
>> with an ivar for controlling the behavior, although I'm not sure if it's
>> needed). What do you think?
>>
> --
> 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/3c773fc0-7049-4d66-ae14-9a322e884774%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S5iAmyAc%2Byf1BXgZ6X5Cr5vwxujmoPDBqaUDXhDFm%2BhGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: normalizing newlines in form fields

[Jakub Kleň]

>From what I have read so far, it would be probably better to normalize to 
'\r\n'.

On Monday, November 12, 2018 at 3:58:39 PM UTC+1, Jakub Kleň wrote:
>
> I'm thinking if it wouldn't be nice if django automatically normalized 
> newlines of data entered by the user. The implementation would be really 
> simple, there's already a function for it in 
> django.utils.text.normalize_newlines, and it would go into 
> django.forms.fields.CharField.to_python the same as split() (maybe also 
> with an ivar for controlling the behavior, although I'm not sure if it's 
> needed). What do you think?
>

-- 
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/d07a9d40-fb4e-4b47-b5b4-4a8b6d21439f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django Courier Management System Project

[sakkhar saha]

Dear All, 
I am Sakkhar form Bangladesh. Now I have a project idea. And i am a single 
man. My Project is Courier Management in Djnago. Please help for the idea. 
How i start my project. And How i Design my database table. 
My Project Feature. 

1. User Can Add Your Order and Track his order. 
2. Admin Can Add Order and Order complete and pending. 
3. Admin Approve User. 
4. When user order confirm than user give an email notification. 
5. And Finally when Admin deliver the order than user give an email 
notification. 

-- 
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/f906f3e8-841b-4fc2-a249-ee251db0b6e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.