Re: Beginner in Django

[kiran baby]

Wow, Django community is really fast and Thank you Adam for your valuable 
informations. I am really gratefull for that. I'll quickly get started 
with  all that you have mentioned.


Thank you,
Kiran

On Monday, January 25, 2021 at 1:53:20 AM UTC+5:30 Adam Johnson wrote:

> Welcome!
>
> There are many different ways to contribute to Django - the forum, 
> blogging, translating, documenting, writing code, and more. Our 
> Contributing Guide can help you get started with many of these: 
> https://docs.djangoproject.com/en/stable/internals/contributing/
>
> If you’re looking to work with the code base (for documentation or code), 
> check out the “Advice for New Contributors” section: 
> https://docs.djangoproject.com/en/stable/internals/contributing/new-contributors/
>  
> . Then see if you can work through the “Writing Your First Patch” tutorial: 
> https://docs.djangoproject.com/en/stable/intro/contributing/ .
>
> If you get stuck or have questions, post back here or in the “Mentorship” 
> section on the forum: 
> https://forum.djangoproject.com/c/internals/mentorship/10
>
> Hope that helps,
>
> Adam
>
> On Sun, 24 Jan 2021 at 18:39, kiran baby  wrote:
>
>> Hello everyone,
>> 
>>  I am new to open source.  I hope to 
>> contribute to the  Django community. But i really don't know where to get 
>> started. Can someone please guide me as to how to go about contributing in 
>> django. It would be of much help in building a good foundation for me.
>>
>>
>>
>> Thanks in advance,
>>
>> Kiran Baby
>>
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/3b1e75ee-91a9-4d62-9daf-3c038f6218c7n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6c5ce1c5-5d36-4e7b-838a-5b649c4b6fa1n%40googlegroups.com.

Re: First time contribution

[Srijita Mallick]

Thanks for responding and for the above information. I'll get started then.
Thank you.
Regards,
Srijita

On Mon, Jan 25, 2021, 05:31 Adam Johnson  wrote:

> Welcome!
>
> There are many different ways to contribute to Django - the forum,
> blogging, translating, documenting, writing code, and more. Our
> Contributing Guide can help you get started with many of these:
> https://docs.djangoproject.com/en/stable/internals/contributing/
>
> If you’re looking to work with the code base (for documentation or code),
> check out the “Advice for New Contributors” section:
> https://docs.djangoproject.com/en/stable/internals/contributing/new-contributors/
> . Then see if you can work through the “Writing Your First Patch” tutorial:
> https://docs.djangoproject.com/en/stable/intro/contributing/ .
>
> If you get stuck or have questions, post back here or in the “Mentorship”
> section on the forum:
> https://forum.djangoproject.com/c/internals/mentorship/10
>
> Hope that helps,
>
> Adam
>
> On Sat, 23 Jan 2021 at 01:44, Srijita Mallick 
> wrote:
>
>> Hello,
>>
>> I’m a beginner in open source. I hope to contribute in Django community.
>> I have been working with Python and Django for a year now. Can someone
>> please guide me as to how to go about contributing. It would help me a lot.
>>
>> Thanks ,
>>
>> Srijita
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/8e583ff8-b75c-42d9-8e04-cf385315ceeen%40googlegroups.com
>> 
>> .
>>
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2Gn26vozEYw4_U8CiGNHU%2BAWH6J8UuXbgab_NMtAaSxg%40mail.gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEq3HBTDs6fGeDK06bzcTg2YwYhhMiPgEBkhvGkOnhoTT_y-jw%40mail.gmail.com.

Re: First time contribution

[Adam Johnson]

Welcome!

There are many different ways to contribute to Django - the forum,
blogging, translating, documenting, writing code, and more. Our
Contributing Guide can help you get started with many of these:
https://docs.djangoproject.com/en/stable/internals/contributing/

If you’re looking to work with the code base (for documentation or code),
check out the “Advice for New Contributors” section:
https://docs.djangoproject.com/en/stable/internals/contributing/new-contributors/
. Then see if you can work through the “Writing Your First Patch” tutorial:
https://docs.djangoproject.com/en/stable/intro/contributing/ .

If you get stuck or have questions, post back here or in the “Mentorship”
section on the forum:
https://forum.djangoproject.com/c/internals/mentorship/10

Hope that helps,

Adam

On Sat, 23 Jan 2021 at 01:44, Srijita Mallick 
wrote:

> Hello,
>
> I’m a beginner in open source. I hope to contribute in Django community. I
> have been working with Python and Django for a year now. Can someone please
> guide me as to how to go about contributing. It would help me a lot.
>
> Thanks ,
>
> Srijita
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/8e583ff8-b75c-42d9-8e04-cf385315ceeen%40googlegroups.com
> 
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2Gn26vozEYw4_U8CiGNHU%2BAWH6J8UuXbgab_NMtAaSxg%40mail.gmail.com.

Re: Rethink (?) how we handle security headers.

[Tim Graham]

If we go with something like:

SECURITY_HEADERS = {
"REFERRER_POLICY": "same-origin",
"HSTS": {
"PRELOAD": True,
"SECONDS": 1_000_000,
 },
}

should we have an empty dictionary as the default or a dictionary with 
defaults for all settings? 

A drawback of an empty dictionary is that any code that wants to retrieve a 
setting has to do something like 
settings.SECURITY_HEADERS.get('REFERRER_POLICY', '') which 
means the fallback value is duplicated every place the setting is 
consulted.  Maybe a way to mitigate that is to add a 
"get_security_header()" function that retrieves from django.conf.settings 
(user-defined settings) and falls back to some defaults.

A drawback of a fully-populated default is that overriding it either 
requires users to redefine the entire dictionary or writing code like:

from django.conf.global_settings import SECURITY_HEADERS
SECURITY_HEADERS['REFERRER_POLICY'] = '...'

If users redefine the entire dictionary, then adding new SECURITY_HEADERS 
options in future Django versions will require something like 
"get_security_header()" since we won't be able to assume the key is there 
in projects upgrading from older versions.

I'm not so sure the benefit of consolidating to a single setting is worth 
this additional complexity.
On Tuesday, January 19, 2021 at 8:27:58 AM UTC-5 Adam Johnson wrote:

> I don't see the need for adding a setting to add headers to outgoing 
> responses. A middleware to do so is a handful of lines:
>
> class SecurityHeadersMiddleware:
> def __init__(self, get_response):
> self.get_response = get_response
>
> def __call__(self, request):
> response = self.get_response(request)
> response["Cross-Origin-Embedder-Policy"] = "require-corp"
> return response
>
> Also there are many non-security related headers one might want to add, so 
> having the ability to add them in a setting called SECURITY_HEADERS could 
> be confusing for maintenance.
>
> On Tue, 19 Jan 2021 at 12:02, Tim Graham  wrote:
>
>> I guess there have been a few different proposals here, but I imagined 
>> SECURITY_HEADERS would allow setting any security-related header without 
>> making changes in Django. If the setting is more than header/value pairs, 
>> then it seems this won't be the case.
>>
>> On Tuesday, January 19, 2021 at 4:39:54 AM UTC-5 Adam Johnson wrote:
>>
>>> I'd imagined the setting would be more like a roll-up of the existing 
>>> settings, so no need for parsing:
>>>
>>> SECURITY_HEADERS = {
>>> "REFERRER_POLICY": "same-origin",
>>> "HSTS": {
>>> "PRELOAD": True,
>>> "SECONDS": 1_000_000,
>>>  },
>>> }
>>>
>>>
>>> On Tue, 19 Jan 2021 at 01:30, Tim Graham  wrote:
>>>
 The proposal seems to be a setting of the form:

 SECURITY_HEADERS = {
 'Strict-Transport-Security': 
 'max-age=60; includeSubDomains; preload',
 ...
 }

 Currently we have system checks to suggest 
 setting SECURE_HSTS_SECONDS, SECURE_HSTS_PRELOAD, etc. Do you envision 
 trying to keep these checks? It seems it'll be more complicated to parse 
 and validate arbitrary string values instead of individual settings.

 It seems some headers may still need special handling in 
 SecurityMiddleware. For example, 'Strict-Transport-Security' is only set 
 if 
 request.is_secure().
 On Friday, August 21, 2020 at 12:53:33 PM UTC-4 Adam Johnson wrote:

> A single SECURITY_HEADERS (or perhaps SECURITY) setting sounds good. 
> Would love to get CORS into core too.
>
> The Opener-Policy ticket has been marked as someday/maybe because the 
> header is still not widely supported.
>
> On Thu, 20 Aug 2020 at 00:02, James Bennett  
> wrote:
>
>> While I think Adam's right that adding one or two new settings
>> wouldn't be a problem, I do worry about the ongoing proliferation, and
>> it's a thing that I keep wanting to try to find the time to work on
>> but never actually succeed at.
>>
>> Separate from the suggestion of a generic way to add headers on every
>> response, I've been leaning for a while toward the idea of
>> consolidating the security-header settings the way we've already
>> consolidated database and template settings. We can paint the bikeshed
>> whatever color, but suppose for sake of an example name we add a
>> SECURITY_HEADERS setting, with each one configured under its own key.
>> That would allow X-Frame-Options, content sniffing, HSTS,
>> Referrer-Policy, opener policy, and future stuff like CSP, built-in
>> CORS, etc. to all be defined in a single place that doesn't
>> proliferate a huge number of new settings, or require adding and
>> supporting a new setting every time a new one comes along (which, with
>> security headers, is about twice a week these days).
>>
>> For now I think the best thing would be to accept the 

Re: Beginner in Django

[Dhruval Gandhi]

Thanx Adam, It'll be helpful for me too.

On Mon, 25 Jan 2021 at 01:53, Adam Johnson  wrote:

> Welcome!
>
> There are many different ways to contribute to Django - the forum,
> blogging, translating, documenting, writing code, and more. Our
> Contributing Guide can help you get started with many of these:
> https://docs.djangoproject.com/en/stable/internals/contributing/
>
> If you’re looking to work with the code base (for documentation or code),
> check out the “Advice for New Contributors” section:
> https://docs.djangoproject.com/en/stable/internals/contributing/new-contributors/
> . Then see if you can work through the “Writing Your First Patch” tutorial:
> https://docs.djangoproject.com/en/stable/intro/contributing/ .
>
> If you get stuck or have questions, post back here or in the “Mentorship”
> section on the forum:
> https://forum.djangoproject.com/c/internals/mentorship/10
>
> Hope that helps,
>
> Adam
>
> On Sun, 24 Jan 2021 at 18:39, kiran baby  wrote:
>
>> Hello everyone,
>>
>>  I am new to open source.  I hope to
>> contribute to the  Django community. But i really don't know where to get
>> started. Can someone please guide me as to how to go about contributing in
>> django. It would be of much help in building a good foundation for me.
>>
>>
>>
>> Thanks in advance,
>>
>> Kiran Baby
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/3b1e75ee-91a9-4d62-9daf-3c038f6218c7n%40googlegroups.com
>> 
>> .
>>
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM0sqP1F0xX_fceCLGBYVr3JZh1k06hBRiK5_g3%2Bs2bYjw%40mail.gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAOKtU_h6UgBpLD5s9kR5uUF7sGzUSBGX98TkvKfqWnzs8%3D1Xtw%40mail.gmail.com.

Re: Beginner in Django

[Adam Johnson]

Welcome!

There are many different ways to contribute to Django - the forum,
blogging, translating, documenting, writing code, and more. Our
Contributing Guide can help you get started with many of these:
https://docs.djangoproject.com/en/stable/internals/contributing/

If you’re looking to work with the code base (for documentation or code),
check out the “Advice for New Contributors” section:
https://docs.djangoproject.com/en/stable/internals/contributing/new-contributors/
. Then see if you can work through the “Writing Your First Patch” tutorial:
https://docs.djangoproject.com/en/stable/intro/contributing/ .

If you get stuck or have questions, post back here or in the “Mentorship”
section on the forum:
https://forum.djangoproject.com/c/internals/mentorship/10

Hope that helps,

Adam

On Sun, 24 Jan 2021 at 18:39, kiran baby  wrote:

> Hello everyone,
>
>  I am new to open source.  I hope to
> contribute to the  Django community. But i really don't know where to get
> started. Can someone please guide me as to how to go about contributing in
> django. It would be of much help in building a good foundation for me.
>
>
>
> Thanks in advance,
>
> Kiran Baby
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3b1e75ee-91a9-4d62-9daf-3c038f6218c7n%40googlegroups.com
> 
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0sqP1F0xX_fceCLGBYVr3JZh1k06hBRiK5_g3%2Bs2bYjw%40mail.gmail.com.

Beginner in Django

[kiran baby]

Hello everyone,

 I am new to open source.  I hope to contribute 
to the  Django community. But i really don't know where to get started. Can 
someone please guide me as to how to go about contributing in django. It 
would be of much help in building a good foundation for me.



Thanks in advance,

Kiran Baby

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3b1e75ee-91a9-4d62-9daf-3c038f6218c7n%40googlegroups.com.

Beginner in Django

[kiran baby]

Hello everyone,

 I am new to open source.  I hope to contribute 
to the  Django community. But i really don't know where to get started . 
Can someone please guide me as to how to go about contributing in django. 
It would be of much help in building a good foundation for me.

Thanks in advance,

Kiran Baby

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/299ef222-7926-46eb-abc1-a41edaa284fbn%40googlegroups.com.

Re: To keep or not to keep: logging of undefined template variables

[Timothy McCurrach]

I was going to have a go at this ticket 
(https://code.djangoproject.com/ticket/28526) -  which links this thread.

Having read the various replies, it seems like there is no shortage of 
differing views how missing/invalid variables should be treated:
 - There should be no logging
 - There should be logging, but full tracebacks are too noisy / not 
beginner friendly
 - Full tracebacks are useful
 - There should be logging but only for the first time an invalid variable 
is encountered within a template
 - Some combination of the above with a setting (or settings) to alter 
behaviour
 - There should be a setting to make invalid variables raise errors

There is a danger of bloating the number of options/settings and still not 
catering for what everyone wants.

One way to allow all of these would be to provide a hook to handle raising 
errors/logging in the case of invalid variables. This would also allow all 
kinds of custom behaviour, that might be useful for particular cases, but 
which wouldn't warrant being features of django itself:
 - log / raise only on particular templates
 - provide different levels of logging depending on the type of the invalid 
variable
 - etc

I originally thought of replacing `string_if_invalid` with an option 
function `invalid_variable_handler` that points to a function, which would 
return a string for invalid variables, and could also handle logging/errors 
at the same time. Perhaps this is too many concerns for one function; 
although having said that, it's really just one concern - handling 
invalid/undefined variables. The default function could return 
`string_if_invalid` during the interim whilst we add a deprecation warning 
for `string_if_invalid`.

A less destructive option would be to leave `string_if_invalid` as it is, 
and just move the code that logs/raises errors to a public method 
`handle_variable_resolve_errors` of Engine(?). This would provide a public 
API for people to customise logging/raising of errors if they should so 
wish, by sub-classing `Engine` (and then add an engine attribute to 
DjangoTemplates??). 

Alternatively, `handle_variable_resolve_errors` could just be another 
option which would point to the above function, rather than having to 
subclass Engine.

The very first of these approaches would allow useful things like returning 
different `string_if_invalid` values for different templates, if debug is 
on etc. But seems a bit messier.

There are a few more variations on the same theme, in terms of actual 
implementation, but the basic idea is the same - move logging/raising 
errors to an overridable function. 

Any thoughts on this would be much appreciated

On Friday, August 25, 2017 at 11:50:27 AM UTC+1 Vlastimil Zíma wrote:

> If anyone is interested, I've cleaned the errors in admin templates:
>
> Ticket: https://code.djangoproject.com/ticket/28529
> PR: https://github.com/django/django/pull/8973
>
> The fixes are quite simple. The biggest problem is sometimes to find out, 
> in which template the bug actually appears.
>
> Vlastik
>
> Dne pátek 25. srpna 2017 9:28:30 UTC+2 Vlastimil Zíma napsal(a):
>
>> Apparently there is number of errors in admin templates. I suggest to fix 
>> the templates. I my experience, the most cases are missing if statements or 
>> missing context variables. These can be fixed very easily and produce 
>> cleaner templates. I consider this much better solution than just ignoring 
>> error messages.
>>
>> As Anthony suggested, the main problem is more often the fuzziness of the 
>> messages, which do not often properly state template, line or expression 
>> which is incorrect. This makes it difficult to resolve them in some cases.
>>
>> Vlastik
>>
>> Dne čtvrtek 24. srpna 2017 17:21:38 UTC+2 Tim Graham napsal(a):
>>>
>>> We received a report that shows the large number of undefined variable 
>>> warnings when rendering an admin changelist page [0]. 
>>>
>>> I'm still not sure what the solution should be, but I created #28526 [1] 
>>> to track this problem: finding a remedy to the problem of verbose, often 
>>> unhelpful logging of undefined variables.
>>>
>>> I don't think "the end goal of errors raising when using undefined 
>>> variables" is feasible. My sense is that relying on the behavior of 
>>> undefined variables is too entrenched in the Django template language to 
>>> change it at this point. (If someone wanted to try to fix all the warnings 
>>> in the admin templates, that might provide a useful data point). See the 
>>> "Template handling of undefined variables" thread [2] for a longer 
>>> discussion.
>>>
>>> [0] https://code.djangoproject.com/ticket/28516
>>> [1] https://code.djangoproject.com/ticket/28526
>>> [2] 
>>> https://groups.google.com/d/topic/django-developers/LT5ESP0w0gQ/discussion
>>>
>>> On Tuesday, June 20, 2017 at 4:12:52 AM UTC-4, Anthony King wrote:

 -1 for removing logs. Like Vlastimil, it's helped me spot a couple of 
 stray bugs.

 What I'd actually