Re: Production Django use and "real ip"

[Arthur Pemberton]

At this point, I'm not even suggesting that Django handle this internally.
I'm suggesting that the behaviour/expectation be documented, at least in
the deployment guide.

Are there any deployment scenarios where META.REMOTE_ADDR is ever even
correct?

Arthur Pemberton

On Wed, Apr 19, 2023 at 3:37 AM 'st...@jigsawtech.co.uk' via Django
developers (Contributions to Django itself) <
django-developers@googlegroups.com> wrote:

> As someone whose worked on various projects in different languages over
> the last 15 years that heavily involved deciphering IP sent in headers to
> try to determine the "real" IP address of a connection, I would urge
> caution with anything around determining a "real IP". There is no standard
> in terms of where to look and what to trust. The X-FORWARDED-FOR is not
> always right, can easily be spoofed, it can include multiple IPs of which
> the order is not consistent. Sometimes the left most element is the first
> and "true IP", sometimes it's the right, sometimes its a value in the
> middle. It all depends what's included, what appended to the request, what
> the values are and what you want to trust/ignore. I've seen requests that
> include internal network IPs, then router/gateway IPs, proxy IPs and load
> balancers all within that head all in different orders.   It's especially
> messy when dealing with requests on mobile network where the carrier uses
> proxies, sometimes 3rd parties, and where your website is hosted behind
> both load balancers and webserver as each may manipulate the header in
> different ways.
>
> One of the best packages within the Django eco-system for trying to
> identify a users actual external IP that I've come across is django-ipware
> . It allows you to choose the
> precedence order that matches your use case, yo have private IP prefixes,
> to configure how many proxies you wish to ignore etc. They also have a
> handy notice/disclaimer
>  on
> the subject.
>
> IMO Django core should leave this 3rd party packages and individual
> deployments to decide and determine what they deem as being the source of
> the "real IP" for their individual project.
>
>
>
> On Friday, 14 April 2023 at 10:13:22 UTC+1 Adam Johnson wrote:
>
>> It's surprisingly complex to interpret x-forwarded-for:
>> https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/ .
>> We will never be able to safely add automated handling.
>>
>> I *guess* we could add a note to the deployment guide like "check your
>> HTTP_X_FORWARDED_FOR setting". I'm concerned it would be a step towards
>> making the guide too long, and filled with irrelevant details. Most sites
>> don't care about recording the user's IP. On those that do, it should be
>> easy enough to discover the setting.
>>
>> On Sat, Apr 1, 2023 at 4:39 AM Arthur Pemberton  wrote:
>>
>>> I have read previous discussions (most recent I could find was Dec 2013
>>>  [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the
>>> "real" IP address of an HttpRequest. From what I can see, currently there
>>> is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django.
>>>
>>> However, I do notice that Django acknowledges `X_FORWARDED_HOST`,
>>> `X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO`
>>> (though SECURE_PROXY_SSL_HEADER).
>>>
>>> If there is still opposition to having some built-in handling for
>>> `HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at
>>> least mention the need for the developer to handle this explicitly.
>>>
>>> Regards,
>>> Arthur P.
>>>
>>> 
>>>
>>> [1]
>>> https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J
>>> [2] https://docs.djangoproject.com/en/4.1/howto/deployment/
>>>
>>> --
>>> 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/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.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/4f06664d-135e-4eb2-86ec-11eccf4cb495n%40googlegroups.com
> 

RE: Django's automatic admin interface.

[Matthew Pava]

I agree with your sentiment, Tom. I would add that we could get a more 
“SPA-feel” by using HTML over the wire or htmx, which requires minimal 
JavaScript.

From: django-developers@googlegroups.com  
On Behalf Of Tom Carrick
Sent: Wednesday, April 19, 2023 5:07 AM
To: django-developers@googlegroups.com
Subject: Re: Django's automatic admin interface.

IMO, if we were going to modernise the admin (which is laudable), it wouldn't 
be by using JS frameworks or Tailwind, but by simplifying things further, by 
removing the last bits of JQuery, simplifying the HTML and making it more 
semantic, and rewriting the CSS to use a grid based layout and cut down the 
amount of code that is needed to achieve the same result.

I don't have anything against Tailwind or Vue per së, but forcing every Django 
project to have them in the backend seems too opinionated and too much of a 
maintenance burden.

As you mentioned, there are already opinionated packages out there, I'm happy 
they exist, but in my opinion they belong in external packages, not in core.

Tom

On Wed, 19 Apr 2023 at 11:45, Dipankar 
mailto:dipit2...@gmail.com>> wrote:
Sorry if my question is wrong.. .. Not exactly technology I wanted to know 
about the frontend framework like tailwindCSS,react or Vue.

In nutshell I want admin interface with tailwindCSS/React/Vue. any suggestion ?

On Wed, Apr 19, 2023 at 3:01 PM David Sanders 
mailto:shang.xiao.sand...@gmail.com>> wrote:
Hi Dipankar,

Not being rude but serious question: What's the latest front end technology? :)

On Wed, 19 Apr 2023, 7:27 pm Dipankar, 
mailto:dipit2...@gmail.com>> wrote:
Is there any plan to replace Django's automatic admin interface with the latest 
front end technology?
There are several packages available but what if Django itself provides the 
same as core.

--
Warm Regards,
Dipankar B.
--
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/CAFdBwp_N0remvp8zAPFVda6iyFWVWR%3DZh0EtfE9fzYcPQVixkQ%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/CADyZw-61oX4oh3apDatm_MKCdoYCMLxkk8O4krKMZuPZF2LpNg%40mail.gmail.com.


--
Warm Regards,
Dipankar B.
--
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/CAFdBwp-cO_g_JCTQhMQVEJe%2BN4FjJD5F-D%2B7LKugRK%2B1-Pq3Rg%40mail.gmail.com.
--
You received this message because you a

Re: Deprecate CICharField, CIEmailField, CITextField

[fly.a...@gmail.com]

Hey everyone!

Thanks for the discussion.
And special thanks @Adam, for the great article, helped us with the 
migration.

What I am struggling now with is whenever I specify 
`db_collation="case_insensitive"` on the field and this field is used in 
`ModelAdmin.search_fields` - Django simply breaks (as it by default uses 
`icontains` lookup).
That is quite unfortunate for the big projects, as I have to come up with 
some generic solution to something that was not broken before this feature 
deprecation (and the docs does not mention this case).
Good that Adam covered it in the article, but I feel that this could be 
handled on a lower level than right now. Currently, we'd need to write a 
manual annotation for admin queryset in almost every project that uses 
usernames or emails (which my guess is something you'd want to be 
case-insensitive on a database level).

I wonder how we could move forward (in case reverting this is not an 
option) and reduce overall aftermath stress.
For example, in terms of documentation, we could add a note on 
`db_collation` to `icontains` page:
https://docs.djangoproject.com/en/4.2/ref/models/querysets/#icontains

But I also feel that might not be enough.

Best,
Rust


On Tuesday, 18 April 2023 at 09:52:20 UTC+2 Johannes Maron wrote:

> Thanks Adam,
>
> of course I read your well-written article before diving into this topic, 
> thanks for sharing.
>
> However, I don't agree about the index. The best solution is using the 
> CITEXT db type, which is very much alive.
> Should Django to deprecate support for the db type, a 3rd party package 
> seems the bast choice for me.
> With the downside of me having to maintain yet another package. But I can 
> understand if the Django project has no interest in maintenance.
>
> In any event, I opened a ticket: 
> https://code.djangoproject.com/ticket/34501
>
> Best Joe
>
>
> On Fri, Apr 14, 2023 at 11:36 AM 'Adam Johnson' via Django developers 
> (Contributions to Django itself)  wrote:
>
>> Just to note, for anyone that finds it useful, that I wrote a blog post 
>> on migrating to collations: 
>> https://adamj.eu/tech/2023/02/23/migrate-django-postgresql-ci-fields-case-insensitive-collation/
>>
>> But yes, I have also been thinking like Tom that indexing UPPER("email") 
>> seems to be the path of least complexity...
>>
>> On Thu, Apr 13, 2023 at 8:12 AM Tom Carrick  wrote:
>>
>>> Hi,
>>>
>>> I wrote most of the code for collation support, and I also argued 
>>> (softly) against deprecating citext support for the reasons you stated.
>>>
>>> However, I've changed my mind on this now. As you can't index the citext 
>>> column for LIKE queries, doing these types of searches on any real amount 
>>> of data is going to be too slow in most cases. I actually think the best 
>>> practice right now for having searchable case-insensitive emails is to do 
>>> it old-school - have a regular EmailField with an index on UPPER("email") 
>>> and then make sure you always use iexact, istartswith etc. and this will 
>>> properly use the indexes and result in a faster search.
>>>
>>> So I see very few advantages now to keeping CITEXT at all, and they're 
>>> quite easy to add as a third party package as Mariusz suggested if anyone 
>>> is so inclined.
>>>
>>> Cheers,
>>> Tom
>>>
>>> On Wed, 12 Apr 2023 at 12:09, Mariusz Felisiak  
>>> wrote:
>>>
 Hi

 > Unless we want to drop support for the CITEXT extension, ...

 What do you mean by that? As far as I'm now, we don't do anything 
 special to support CITEXT extension 🤔.

 > I'd caution to revert the deprecation and keep support ...

 I'm obviously biased as the author of this proposition and patch, 
 however, IMO, small differences between using CI fields and collations 
 don't justify maintaining 3 additional fields that were mostly untested. 
 Also, they are deprecated in a LTS so folks still have *3* more years 
 to update their code. In the worst case someone can create 3rd party 
 package with them.

 Unless something is fundamentally broken I'm against reverting.

 Best,
 Mariusz

 -- 
 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/5c11b704-68c4-490d-84bf-90c734cc02d1n%40googlegroups.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 emai

Re: Django's automatic admin interface.

[Tom Carrick]

IMO, if we were going to modernise the admin (which is laudable), it
wouldn't be by using JS frameworks or Tailwind, but by simplifying things
further, by removing the last bits of JQuery, simplifying the HTML and
making it more semantic, and rewriting the CSS to use a grid based layout
and cut down the amount of code that is needed to achieve the same result.

I don't have anything against Tailwind or Vue per së, but forcing every
Django project to have them in the backend seems too opinionated and too
much of a maintenance burden.

As you mentioned, there are already opinionated packages out there, I'm
happy they exist, but in my opinion they belong in external packages, not
in core.

Tom

On Wed, 19 Apr 2023 at 11:45, Dipankar  wrote:

> Sorry if my question is wrong.. .. Not exactly technology I wanted to know
> about the frontend framework like tailwindCSS,react or Vue.
>
> In nutshell I want admin interface with tailwindCSS/React/Vue. any
> suggestion ?
>
> On Wed, Apr 19, 2023 at 3:01 PM David Sanders <
> shang.xiao.sand...@gmail.com> wrote:
>
>> Hi Dipankar,
>>
>> Not being rude but serious question: What's the latest front end
>> technology? :)
>>
>> On Wed, 19 Apr 2023, 7:27 pm Dipankar,  wrote:
>>
>>> Is there any plan to replace Django's automatic admin interface with the
>>> latest front end technology?
>>> There are several packages available but what if Django itself provides
>>> the same as core.
>>>
>>> --
>>> Warm Regards,
>>> Dipankar B.
>>>
>>> --
>>> 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/CAFdBwp_N0remvp8zAPFVda6iyFWVWR%3DZh0EtfE9fzYcPQVixkQ%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/CADyZw-61oX4oh3apDatm_MKCdoYCMLxkk8O4krKMZuPZF2LpNg%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Warm Regards,
> Dipankar B.
>
> --
> 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/CAFdBwp-cO_g_JCTQhMQVEJe%2BN4FjJD5F-D%2B7LKugRK%2B1-Pq3Rg%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/CAHoz%3DMY5g6fxw8DXCEhm%2BoQDW3isSCBGk7kYhdwB3Omdg4%3DjAQ%40mail.gmail.com.

Re: Django's automatic admin interface.

[Dipankar]

Sorry if my question is wrong.. .. Not exactly technology I wanted to know
about the frontend framework like tailwindCSS,react or Vue.

In nutshell I want admin interface with tailwindCSS/React/Vue. any
suggestion ?

On Wed, Apr 19, 2023 at 3:01 PM David Sanders 
wrote:

> Hi Dipankar,
>
> Not being rude but serious question: What's the latest front end
> technology? :)
>
> On Wed, 19 Apr 2023, 7:27 pm Dipankar,  wrote:
>
>> Is there any plan to replace Django's automatic admin interface with the
>> latest front end technology?
>> There are several packages available but what if Django itself provides
>> the same as core.
>>
>> --
>> Warm Regards,
>> Dipankar B.
>>
>> --
>> 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/CAFdBwp_N0remvp8zAPFVda6iyFWVWR%3DZh0EtfE9fzYcPQVixkQ%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/CADyZw-61oX4oh3apDatm_MKCdoYCMLxkk8O4krKMZuPZF2LpNg%40mail.gmail.com
> 
> .
>


-- 
Warm Regards,
Dipankar B.

-- 
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/CAFdBwp-cO_g_JCTQhMQVEJe%2BN4FjJD5F-D%2B7LKugRK%2B1-Pq3Rg%40mail.gmail.com.

Re: Django's automatic admin interface.

[David Sanders]

Hi Dipankar,

Not being rude but serious question: What's the latest front end
technology? :)

On Wed, 19 Apr 2023, 7:27 pm Dipankar,  wrote:

> Is there any plan to replace Django's automatic admin interface with the
> latest front end technology?
> There are several packages available but what if Django itself provides
> the same as core.
>
> --
> Warm Regards,
> Dipankar B.
>
> --
> 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/CAFdBwp_N0remvp8zAPFVda6iyFWVWR%3DZh0EtfE9fzYcPQVixkQ%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/CADyZw-61oX4oh3apDatm_MKCdoYCMLxkk8O4krKMZuPZF2LpNg%40mail.gmail.com.

Django's automatic admin interface.

[Dipankar]

Is there any plan to replace Django's automatic admin interface with the
latest front end technology?
There are several packages available but what if Django itself provides the
same as core.

-- 
Warm Regards,
Dipankar B.

-- 
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/CAFdBwp_N0remvp8zAPFVda6iyFWVWR%3DZh0EtfE9fzYcPQVixkQ%40mail.gmail.com.

Re: Production Django use and "real ip"

['st...@jigsawtech.co.uk' via Django developers (Contributions to Django itself)]

As someone whose worked on various projects in different languages over the 
last 15 years that heavily involved deciphering IP sent in headers to try 
to determine the "real" IP address of a connection, I would urge caution 
with anything around determining a "real IP". There is no standard in terms 
of where to look and what to trust. The X-FORWARDED-FOR is not always 
right, can easily be spoofed, it can include multiple IPs of which the 
order is not consistent. Sometimes the left most element is the first and 
"true IP", sometimes it's the right, sometimes its a value in the middle. 
It all depends what's included, what appended to the request, what the 
values are and what you want to trust/ignore. I've seen requests that 
include internal network IPs, then router/gateway IPs, proxy IPs and load 
balancers all within that head all in different orders.   It's especially 
messy when dealing with requests on mobile network where the carrier uses 
proxies, sometimes 3rd parties, and where your website is hosted behind 
both load balancers and webserver as each may manipulate the header in 
different ways.

One of the best packages within the Django eco-system for trying to 
identify a users actual external IP that I've come across is django-ipware 
. It allows you to choose the 
precedence order that matches your use case, yo have private IP prefixes, 
to configure how many proxies you wish to ignore etc. They also have a 
handy notice/disclaimer 
 on 
the subject.

IMO Django core should leave this 3rd party packages and individual 
deployments to decide and determine what they deem as being the source of 
the "real IP" for their individual project.



On Friday, 14 April 2023 at 10:13:22 UTC+1 Adam Johnson wrote:

> It's surprisingly complex to interpret x-forwarded-for: 
> https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/ . We 
> will never be able to safely add automated handling.
>
> I *guess* we could add a note to the deployment guide like "check your 
> HTTP_X_FORWARDED_FOR setting". I'm concerned it would be a step towards 
> making the guide too long, and filled with irrelevant details. Most sites 
> don't care about recording the user's IP. On those that do, it should be 
> easy enough to discover the setting.
>
> On Sat, Apr 1, 2023 at 4:39 AM Arthur Pemberton  wrote:
>
>> I have read previous discussions (most recent I could find was Dec 2013 
>>  [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the 
>> "real" IP address of an HttpRequest. From what I can see, currently there 
>> is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django.
>>
>> However, I do notice that Django acknowledges `X_FORWARDED_HOST`, 
>> `X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO`  
>> (though SECURE_PROXY_SSL_HEADER).
>>
>> If there is still opposition to having some built-in handling for 
>> `HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at 
>> least mention the need for the developer to handle this explicitly.
>>
>> Regards,
>> Arthur P.
>>
>> 
>>
>> [1] 
>> https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J
>> [2] https://docs.djangoproject.com/en/4.1/howto/deployment/
>>
>> -- 
>> 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/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.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/4f06664d-135e-4eb2-86ec-11eccf4cb495n%40googlegroups.com.