Re: Adding a security concerned feature

[Daryl]

My 2c:

The analogy is pretty straightforward here;
- changing the admin URL is like putting your house's front door key slot
in a strange, unique place, so that additional *knowledge* is required to
unlock it.
- django-axes, fail2ban, etc is like having a bouncer standing beside the
door, watching for suspicious activity and ejecting anyone who
clearly doesn't have a genuine key.

Changing your admin URL is not a waste of time, but if your time is
precious, spend it on ensuring your users have strong passwords, and that
your logon page can't be abused.

D



On Thu, 3 Dec 2020 at 07:08, 'Aaron C. de Bruyn' via Django developers
(Contributions to Django itself)  wrote:

> On Wed, Dec 2, 2020 at 9:23 AM Collin Anderson 
> wrote:
>
>> > combination of blocking IPs and having a different admin URL would
>> raise the bar quite a bit.
>>
>> So having a different default admin URL would help, right?
>>
>
> Sure.  But so would disconnecting the network cable from your server. :)
> It's all about practicality.
>
> Using something similar to django-axes raises the bar quite a bit, but
> simply obscuring the URL doesn't do much.
>
> I have plenty of apps exposed with the admin URL being '/admin/', but no
> one's been able to compromise the site because I use django-axes to block
> repeated attempts, and I have a strong password.  On several of the sites I
> require logins with a YubiKey.
>
> In my worthless opinion, I think it would be better to leave it in the
> urlconf but commented out with a note that says "you might want to change
> the admin URL to something different before you enable it for $REASONS".
> Maybe have something in the docs on deploying your code into production
> that goes over it too.
>
> -A
>
> --
> 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/CAEE%2BrGqvVXrAZbWwuieitTVTNuKzR%2B%2BWWqc-6HsO4LO0OhvEog%40mail.gmail.com
> 
> .
>


-- 
-- 
==
Daryl Egarr,  Director
Kawhai Consultants Ltd
Cell   021 521 353
da...@kawhai.net
==

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

Re: Adding a security concerned feature

['Aaron C. de Bruyn' via Django developers (Contributions to Django itself)]

On Wed, Dec 2, 2020 at 9:23 AM Collin Anderson  wrote:

> > combination of blocking IPs and having a different admin URL would raise
> the bar quite a bit.
>
> So having a different default admin URL would help, right?
>

Sure.  But so would disconnecting the network cable from your server. :)
It's all about practicality.

Using something similar to django-axes raises the bar quite a bit, but
simply obscuring the URL doesn't do much.

I have plenty of apps exposed with the admin URL being '/admin/', but no
one's been able to compromise the site because I use django-axes to block
repeated attempts, and I have a strong password.  On several of the sites I
require logins with a YubiKey.

In my worthless opinion, I think it would be better to leave it in the
urlconf but commented out with a note that says "you might want to change
the admin URL to something different before you enable it for $REASONS".
Maybe have something in the docs on deploying your code into production
that goes over it too.

-A

-- 
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/CAEE%2BrGqvVXrAZbWwuieitTVTNuKzR%2B%2BWWqc-6HsO4LO0OhvEog%40mail.gmail.com.

Re: Adding a security concerned feature

[Collin Anderson]

> combination of blocking IPs and having a different admin URL would raise
the bar quite a bit.

So having a different default admin URL would help, right?

On Wed, Nov 25, 2020 at 10:11 AM 'Aaron C. de Bruyn' via Django developers
(Contributions to Django itself)  wrote:

> That's security through obscurity that isn't too difficult to get past.
> It certainly raises the bar a bit, but like you said, the root problem is
> someone finding a login box and hammering away trying to guess usernames
> and passwords.  I'm betting your 'standard' login box isn't difficult to
> find if your site has one.  Once you have cracked an account, see if it
> gets you into /admin.
>
> I use django-axes.  If you keep guessing passwords, your IP gets banned.
>
> Maybe a warning could be set that says "Your admin URL is at /admin, we
> recommend you change that"?
>
> I think the combination of blocking IPs and having a different admin URL
> would raise the bar quite a bit.
>
> -A
>
> On Wed, Nov 25, 2020 at 6:51 AM Collin Anderson 
> wrote:
>
>> Hi All,
>>
>> I think at minimum we should change the default admin url for new
>> projects, as that's very easy to do, and it does provide a lot of value for
>> new projects. This helps Django to be secure by default.
>>
>> I use the default /admin/ url for my projects and bots are regurarly
>> trying different password combinitations. In addition, security scanners
>> are now starting to warn if you have an /admin/ url visible on your website.
>>
>> It would be a ton of work for me to change it, but it would be trivial if
>> this were a new project.
>>
>> I think adding the project name as a prefix would help a lot and be very
>> easy to do.
>>
>> https://github.com/django/django/compare/master...collinanderson:patch-14
>>
>> (and then the docs would need to be updated too.)
>>
>> Thanks,
>> Collin
>>
>>
>> On Thursday, November 19, 2020 at 7:11:59 PM UTC-5 arvind...@gmail.com
>> wrote:
>>
>>> A security model doesn’t necessarily have to be any one thing that’s
>>> 100% secure. It can be a combination of things which include “actual”
>>> security features as well as plain ol’ obscurity.
>>>
>>> If I have to register the admin urls on a project, I make sure to setup
>>> django-honeypot and move the admin site to something non-standard.
>>>
>>> Any one thing may not be doing much on it’s own. But the combination, if
>>> messy enough to make someone give up, will give you a better overall
>>> security situation.
>>>
>>> Just my 2¢.
>>>
>>> Onward,
>>> Arvind
>>>
>>> On 19 Nov 2020, at 23:32, r...@whidbey.com wrote:
>>>
>>> FWIW, I agree with Tim and Carlton.  There doesn't seem to me to be a
>>> compelling argument for recommending developers to change the default
>>> "/admin" url.  Any security concerns would hopefully be addressed by actual
>>> security safeguards rather than changing names to something non-standard.
>>>
>>> On Thursday, November 19, 2020 at 7:44:21 AM UTC-8 carlton...@gmail.com
>>> wrote:
>>>
 On this topic, a ticket proposing to prepend the project name to the
 `admin/` URL in the default project template was opened.
 https://code.djangoproject.com/ticket/32209

 Given that it's the exact discussion we're having here, I've paused
 that to see if there's a consensus for a change.

 Thanks. C.

 On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com
 wrote:

>  I've got this idea with the usage of json files that require some
> keys which is authenticated for a single user which seems to excite me for
> fact that if this was similar for admin/, then it'd give django a overhead
> advantages for future use.
>
> On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson, 
> wrote:
>
>> I think I'd come down as -1 for a system check here...
>>
>> They're not costless, there's a tendency to want to add a new system
>> check for every possible configuration choice, but, beyond implementing 
>> and
>> maintaining, the danger is it leads to too much noise.
>> If you get a system check warning, you shouldn't be tempted to ignore
>> it. In general I think reserving the built-in checks slightly means they
>> don't get devalued. (Folks are free, and encouraged, to implement, and
>> share, their own checks to enforce project-level standards.)
>>
>> I think it's not sufficiently clear-cut that using `/admin/` is a bad
>> idea to justify including a check.
>>
>> (On a personal note, I like to use `/admin/`, configure nginx to only
>> serve the admin from the localhost, and then use an SSH tunnel to access 
>> it
>> remotely, so I'd have to silence a system check here.)
>>
>> C.
>>
>> On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany
>> wrote:
>>
>>>
>>> Hi,
>>>
>>> I wasn't convinced about changing the 'admin' path until recently.
>>> My reasons to change the path of 'admin' 

Re: Adding a security concerned feature

['Aaron C. de Bruyn' via Django developers (Contributions to Django itself)]

That's security through obscurity that isn't too difficult to get past.  It
certainly raises the bar a bit, but like you said, the root problem is
someone finding a login box and hammering away trying to guess usernames
and passwords.  I'm betting your 'standard' login box isn't difficult to
find if your site has one.  Once you have cracked an account, see if it
gets you into /admin.

I use django-axes.  If you keep guessing passwords, your IP gets banned.

Maybe a warning could be set that says "Your admin URL is at /admin, we
recommend you change that"?

I think the combination of blocking IPs and having a different admin URL
would raise the bar quite a bit.

-A

On Wed, Nov 25, 2020 at 6:51 AM Collin Anderson 
wrote:

> Hi All,
>
> I think at minimum we should change the default admin url for new
> projects, as that's very easy to do, and it does provide a lot of value for
> new projects. This helps Django to be secure by default.
>
> I use the default /admin/ url for my projects and bots are regurarly
> trying different password combinitations. In addition, security scanners
> are now starting to warn if you have an /admin/ url visible on your website.
>
> It would be a ton of work for me to change it, but it would be trivial if
> this were a new project.
>
> I think adding the project name as a prefix would help a lot and be very
> easy to do.
>
> https://github.com/django/django/compare/master...collinanderson:patch-14
>
> (and then the docs would need to be updated too.)
>
> Thanks,
> Collin
>
>
> On Thursday, November 19, 2020 at 7:11:59 PM UTC-5 arvind...@gmail.com
> wrote:
>
>> A security model doesn’t necessarily have to be any one thing that’s 100%
>> secure. It can be a combination of things which include “actual” security
>> features as well as plain ol’ obscurity.
>>
>> If I have to register the admin urls on a project, I make sure to setup
>> django-honeypot and move the admin site to something non-standard.
>>
>> Any one thing may not be doing much on it’s own. But the combination, if
>> messy enough to make someone give up, will give you a better overall
>> security situation.
>>
>> Just my 2¢.
>>
>> Onward,
>> Arvind
>>
>> On 19 Nov 2020, at 23:32, r...@whidbey.com wrote:
>>
>> FWIW, I agree with Tim and Carlton.  There doesn't seem to me to be a
>> compelling argument for recommending developers to change the default
>> "/admin" url.  Any security concerns would hopefully be addressed by actual
>> security safeguards rather than changing names to something non-standard.
>>
>> On Thursday, November 19, 2020 at 7:44:21 AM UTC-8 carlton...@gmail.com
>> wrote:
>>
>>> On this topic, a ticket proposing to prepend the project name to the
>>> `admin/` URL in the default project template was opened.
>>> https://code.djangoproject.com/ticket/32209
>>>
>>> Given that it's the exact discussion we're having here, I've paused that
>>> to see if there's a consensus for a change.
>>>
>>> Thanks. C.
>>>
>>> On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com wrote:
>>>
  I've got this idea with the usage of json files that require some keys
 which is authenticated for a single user which seems to excite me for fact
 that if this was similar for admin/, then it'd give django a overhead
 advantages for future use.

 On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson, 
 wrote:

> I think I'd come down as -1 for a system check here...
>
> They're not costless, there's a tendency to want to add a new system
> check for every possible configuration choice, but, beyond implementing 
> and
> maintaining, the danger is it leads to too much noise.
> If you get a system check warning, you shouldn't be tempted to ignore
> it. In general I think reserving the built-in checks slightly means they
> don't get devalued. (Folks are free, and encouraged, to implement, and
> share, their own checks to enforce project-level standards.)
>
> I think it's not sufficiently clear-cut that using `/admin/` is a bad
> idea to justify including a check.
>
> (On a personal note, I like to use `/admin/`, configure nginx to only
> serve the admin from the localhost, and then use an SSH tunnel to access 
> it
> remotely, so I'd have to silence a system check here.)
>
> C.
>
> On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany
> wrote:
>
>>
>> Hi,
>>
>> I wasn't convinced about changing the 'admin' path until recently. My
>> reasons to change the path of 'admin' are:
>>
>> -A bit less likely to be affected by bugs like
>>
>> https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
>> : at least the site wouldn't appear in automatic scans for
>> vulnerabilities (if checking Django versions based on the admin
>> template, etc.) . The bug/exploit might have been known before the

Re: Adding a security concerned feature

[Collin Anderson]

Hi All,

I think at minimum we should change the default admin url for new projects, 
as that's very easy to do, and it does provide a lot of value for new 
projects. This helps Django to be secure by default.

I use the default /admin/ url for my projects and bots are regurarly trying 
different password combinitations. In addition, security scanners are now 
starting to warn if you have an /admin/ url visible on your website.

It would be a ton of work for me to change it, but it would be trivial if 
this were a new project.

I think adding the project name as a prefix would help a lot and be very 
easy to do.

https://github.com/django/django/compare/master...collinanderson:patch-14

(and then the docs would need to be updated too.)

Thanks,
Collin


On Thursday, November 19, 2020 at 7:11:59 PM UTC-5 arvind...@gmail.com 
wrote:

> A security model doesn’t necessarily have to be any one thing that’s 100% 
> secure. It can be a combination of things which include “actual” security 
> features as well as plain ol’ obscurity.
>
> If I have to register the admin urls on a project, I make sure to setup 
> django-honeypot and move the admin site to something non-standard.
>
> Any one thing may not be doing much on it’s own. But the combination, if 
> messy enough to make someone give up, will give you a better overall 
> security situation.
>
> Just my 2¢.
>
> Onward,
> Arvind
>
> On 19 Nov 2020, at 23:32, r...@whidbey.com wrote:
>
> FWIW, I agree with Tim and Carlton.  There doesn't seem to me to be a 
> compelling argument for recommending developers to change the default 
> "/admin" url.  Any security concerns would hopefully be addressed by actual 
> security safeguards rather than changing names to something non-standard.
>
> On Thursday, November 19, 2020 at 7:44:21 AM UTC-8 carlton...@gmail.com 
> wrote:
>
>> On this topic, a ticket proposing to prepend the project name to the 
>> `admin/` URL in the default project template was opened. 
>> https://code.djangoproject.com/ticket/32209
>>
>> Given that it's the exact discussion we're having here, I've paused that 
>> to see if there's a consensus for a change. 
>>
>> Thanks. C.
>>
>> On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com wrote:
>>
>>>  I've got this idea with the usage of json files that require some keys 
>>> which is authenticated for a single user which seems to excite me for fact 
>>> that if this was similar for admin/, then it'd give django a overhead 
>>> advantages for future use.
>>>
>>> On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson,  
>>> wrote:
>>>
 I think I'd come down as -1 for a system check here... 

 They're not costless, there's a tendency to want to add a new system 
 check for every possible configuration choice, but, beyond implementing 
 and 
 maintaining, the danger is it leads to too much noise. 
 If you get a system check warning, you shouldn't be tempted to ignore 
 it. In general I think reserving the built-in checks slightly means they 
 don't get devalued. (Folks are free, and encouraged, to implement, and 
 share, their own checks to enforce project-level standards.)

 I think it's not sufficiently clear-cut that using `/admin/` is a bad 
 idea to justify including a check. 

 (On a personal note, I like to use `/admin/`, configure nginx to only 
 serve the admin from the localhost, and then use an SSH tunnel to access 
 it 
 remotely, so I'd have to silence a system check here.) 

 C.

 On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany 
 wrote:

>
> Hi, 
>
> I wasn't convinced about changing the 'admin' path until recently. My 
> reasons to change the path of 'admin' are: 
>
> -A bit less likely to be affected by bugs like 
>
> https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
>  
> : at least the site wouldn't appear in automatic scans for 
> vulnerabilities (if checking Django versions based on the admin 
> template, etc.) . The bug/exploit might have been known before the fix 
> was implemented (and everyone updated) so I prefer to not be exposed 
> (or 
> less exposed) 
>
> -At the moment in Django there is no rate-limiting login attempts "out 
> of the box" so I prefer to avoid the opportunity if possible 
>
> -Partially out of my control: an 'admin' user might have used the same 
> password in another place and the password got leaked 
>
> Other people might have other reasons. 
>
> Cheers, 
>
> On Nov/18/2020, Tim Graham wrote: 
> > I'm not convinced that a system check promoting security by 
> obscurity adds 
> > much value. The original poster wrote "sometimes it can be a 
> security 
> > concern." Maybe that's the case (how so?) but for most sites I would 
> say 
> > it's 

Re: Adding a security concerned feature

[Arvind Nedumaran]

A security model doesn’t necessarily have to be any one thing that’s 
100% secure. It can be a combination of things which include 
“actual” security features as well as plain ol’ obscurity.


If I have to register the admin urls on a project, I make sure to setup 
django-honeypot and move the admin site to something non-standard.


Any one thing may not be doing much on it’s own. But the combination, 
if messy enough to make someone give up, will give you a better overall 
security situation.


Just my 2¢.

Onward,
Arvind

On 19 Nov 2020, at 23:32, r...@whidbey.com wrote:


FWIW, I agree with Tim and Carlton.  There doesn't seem to me to be a
compelling argument for recommending developers to change the default
"/admin" url.  Any security concerns would hopefully be addressed by 
actual
security safeguards rather than changing names to something 
non-standard.


On Thursday, November 19, 2020 at 7:44:21 AM UTC-8 
carlton...@gmail.com

wrote:


On this topic, a ticket proposing to prepend the project name to the
`admin/` URL in the default project template was opened.
https://code.djangoproject.com/ticket/32209

Given that it's the exact discussion we're having here, I've paused 
that

to see if there's a consensus for a change.

Thanks. C.

On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com 
wrote:


 I've got this idea with the usage of json files that require some 
keys
which is authenticated for a single user which seems to excite me 
for fact
that if this was similar for admin/, then it'd give django a 
overhead

advantages for future use.

On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson, 
wrote:


I think I'd come down as -1 for a system check here...

They're not costless, there's a tendency to want to add a new 
system
check for every possible configuration choice, but, beyond 
implementing and

maintaining, the danger is it leads to too much noise.
If you get a system check warning, you shouldn't be tempted to 
ignore
it. In general I think reserving the built-in checks slightly means 
they
don't get devalued. (Folks are free, and encouraged, to implement, 
and

share, their own checks to enforce project-level standards.)

I think it's not sufficiently clear-cut that using `/admin/` is a 
bad

idea to justify including a check.

(On a personal note, I like to use `/admin/`, configure nginx to 
only
serve the admin from the localhost, and then use an SSH tunnel to 
access it

remotely, so I'd have to silence a system check here.)

C.

On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany
wrote:



Hi,

I wasn't convinced about changing the 'admin' path until recently. 
My

reasons to change the path of 'admin' are:

-A bit less likely to be affected by bugs like

https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
: at least the site wouldn't appear in automatic scans for
vulnerabilities (if checking Django versions based on the admin
template, etc.) . The bug/exploit might have been known before the 
fix
was implemented (and everyone updated) so I prefer to not be 
exposed

(or
less exposed)

-At the moment in Django there is no rate-limiting login attempts 
"out

of the box" so I prefer to avoid the opportunity if possible

-Partially out of my control: an 'admin' user might have used the 
same

password in another place and the password got leaked

Other people might have other reasons.

Cheers,

On Nov/18/2020, Tim Graham wrote:
I'm not convinced that a system check promoting security by 
obscurity

adds
much value. The original poster wrote "sometimes it can be a 
security
concern." Maybe that's the case (how so?) but for most sites I 
would

say

it's not.
On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina

Estany

wrote:



Hi,

On Nov/16/2020, Carles Pina i Estany wrote:


Either way: I'd be happy to write a django check to make sure

that

'admin/' is not routed to admin.


Regarding this check: this morning I've done a very 
preliminary/for

fun

draft to play with.




https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1


I'm not sure what is the best way to check if /admin is routed 
to

django.contrib.admin. At the moment it's doing:

resolve(admin_url)._func_path == 
'django.contrib.admin.sites.index'


Yes, I know! :-)

I could also do something along the lines of:
resolve(admin_url).func.admin_site == admin.site

This causes problems on the unit test side (need to import

admin.site).

Still I don't really like it.

Does anyone have any better suggestions or comments? (or code

pointer).

Otherwise later on I'll have another look.

Thank you very much,

--
Carles Pina i Estany
https://carles.pina.cat



--
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 

Re: Adding a security concerned feature

[r...@whidbey.com]

FWIW, I agree with Tim and Carlton.  There doesn't seem to me to be a 
compelling argument for recommending developers to change the default 
"/admin" url.  Any security concerns would hopefully be addressed by actual 
security safeguards rather than changing names to something non-standard.

On Thursday, November 19, 2020 at 7:44:21 AM UTC-8 carlton...@gmail.com 
wrote:

> On this topic, a ticket proposing to prepend the project name to the 
> `admin/` URL in the default project template was opened. 
> https://code.djangoproject.com/ticket/32209
>
> Given that it's the exact discussion we're having here, I've paused that 
> to see if there's a consensus for a change. 
>
> Thanks. C.
>
> On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com wrote:
>
>>  I've got this idea with the usage of json files that require some keys 
>> which is authenticated for a single user which seems to excite me for fact 
>> that if this was similar for admin/, then it'd give django a overhead 
>> advantages for future use.
>>
>> On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson,  
>> wrote:
>>
>>> I think I'd come down as -1 for a system check here... 
>>>
>>> They're not costless, there's a tendency to want to add a new system 
>>> check for every possible configuration choice, but, beyond implementing and 
>>> maintaining, the danger is it leads to too much noise. 
>>> If you get a system check warning, you shouldn't be tempted to ignore 
>>> it. In general I think reserving the built-in checks slightly means they 
>>> don't get devalued. (Folks are free, and encouraged, to implement, and 
>>> share, their own checks to enforce project-level standards.)
>>>
>>> I think it's not sufficiently clear-cut that using `/admin/` is a bad 
>>> idea to justify including a check. 
>>>
>>> (On a personal note, I like to use `/admin/`, configure nginx to only 
>>> serve the admin from the localhost, and then use an SSH tunnel to access it 
>>> remotely, so I'd have to silence a system check here.) 
>>>
>>> C.
>>>
>>> On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany 
>>> wrote:
>>>

 Hi, 

 I wasn't convinced about changing the 'admin' path until recently. My 
 reasons to change the path of 'admin' are: 

 -A bit less likely to be affected by bugs like 

 https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
  
 : at least the site wouldn't appear in automatic scans for 
 vulnerabilities (if checking Django versions based on the admin 
 template, etc.) . The bug/exploit might have been known before the fix 
 was implemented (and everyone updated) so I prefer to not be exposed 
 (or 
 less exposed) 

 -At the moment in Django there is no rate-limiting login attempts "out 
 of the box" so I prefer to avoid the opportunity if possible 

 -Partially out of my control: an 'admin' user might have used the same 
 password in another place and the password got leaked 

 Other people might have other reasons. 

 Cheers, 

 On Nov/18/2020, Tim Graham wrote: 
 > I'm not convinced that a system check promoting security by obscurity 
 adds 
 > much value. The original poster wrote "sometimes it can be a security 
 > concern." Maybe that's the case (how so?) but for most sites I would 
 say 
 > it's not. 
 > On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina 
 Estany 
 > wrote: 
 > 
 > > 
 > > Hi, 
 > > 
 > > On Nov/16/2020, Carles Pina i Estany wrote: 
 > > 
 > > > Either way: I'd be happy to write a django check to make sure 
 that 
 > > > 'admin/' is not routed to admin. 
 > > 
 > > Regarding this check: this morning I've done a very preliminary/for 
 fun 
 > > draft to play with. 
 > > 
 > > 
 > > 
 https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1
  
 > > 
 > > I'm not sure what is the best way to check if /admin is routed to 
 > > django.contrib.admin. At the moment it's doing: 
 > > 
 > > resolve(admin_url)._func_path == 'django.contrib.admin.sites.index' 
 > > 
 > > Yes, I know! :-) 
 > > 
 > > I could also do something along the lines of: 
 > > resolve(admin_url).func.admin_site == admin.site 
 > > 
 > > This causes problems on the unit test side (need to import 
 admin.site). 
 > > Still I don't really like it. 
 > > 
 > > Does anyone have any better suggestions or comments? (or code 
 pointer). 
 > > Otherwise later on I'll have another look. 
 > > 
 > > Thank you very much, 
 > > 
 > > -- 
 > > Carles Pina i Estany 
 > > https://carles.pina.cat 
 > > 
 > 
 > -- 
 > You received this message because you are subscribed to the Google 
 Groups "Django developers (Contributions to 

Re: Adding a security concerned feature

[Carlton Gibson]

On this topic, a ticket proposing to prepend the project name to the 
`admin/` URL in the default project template was opened. 
https://code.djangoproject.com/ticket/32209

Given that it's the exact discussion we're having here, I've paused that to 
see if there's a consensus for a change. 

Thanks. C.

On Thursday, 19 November 2020 at 12:35:00 UTC+1 shan...@gmail.com wrote:

>  I've got this idea with the usage of json files that require some keys 
> which is authenticated for a single user which seems to excite me for fact 
> that if this was similar for admin/, then it'd give django a overhead 
> advantages for future use.
>
> On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson,  
> wrote:
>
>> I think I'd come down as -1 for a system check here... 
>>
>> They're not costless, there's a tendency to want to add a new system 
>> check for every possible configuration choice, but, beyond implementing and 
>> maintaining, the danger is it leads to too much noise. 
>> If you get a system check warning, you shouldn't be tempted to ignore it. 
>> In general I think reserving the built-in checks slightly means they don't 
>> get devalued. (Folks are free, and encouraged, to implement, and share, 
>> their own checks to enforce project-level standards.)
>>
>> I think it's not sufficiently clear-cut that using `/admin/` is a bad 
>> idea to justify including a check. 
>>
>> (On a personal note, I like to use `/admin/`, configure nginx to only 
>> serve the admin from the localhost, and then use an SSH tunnel to access it 
>> remotely, so I'd have to silence a system check here.) 
>>
>> C.
>>
>> On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany wrote:
>>
>>>
>>> Hi, 
>>>
>>> I wasn't convinced about changing the 'admin' path until recently. My 
>>> reasons to change the path of 'admin' are: 
>>>
>>> -A bit less likely to be affected by bugs like 
>>>
>>> https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
>>>  
>>> : at least the site wouldn't appear in automatic scans for 
>>> vulnerabilities (if checking Django versions based on the admin 
>>> template, etc.) . The bug/exploit might have been known before the fix 
>>> was implemented (and everyone updated) so I prefer to not be exposed (or 
>>> less exposed) 
>>>
>>> -At the moment in Django there is no rate-limiting login attempts "out 
>>> of the box" so I prefer to avoid the opportunity if possible 
>>>
>>> -Partially out of my control: an 'admin' user might have used the same 
>>> password in another place and the password got leaked 
>>>
>>> Other people might have other reasons. 
>>>
>>> Cheers, 
>>>
>>> On Nov/18/2020, Tim Graham wrote: 
>>> > I'm not convinced that a system check promoting security by obscurity 
>>> adds 
>>> > much value. The original poster wrote "sometimes it can be a security 
>>> > concern." Maybe that's the case (how so?) but for most sites I would 
>>> say 
>>> > it's not. 
>>> > On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina Estany 
>>> > wrote: 
>>> > 
>>> > > 
>>> > > Hi, 
>>> > > 
>>> > > On Nov/16/2020, Carles Pina i Estany wrote: 
>>> > > 
>>> > > > Either way: I'd be happy to write a django check to make sure that 
>>> > > > 'admin/' is not routed to admin. 
>>> > > 
>>> > > Regarding this check: this morning I've done a very preliminary/for 
>>> fun 
>>> > > draft to play with. 
>>> > > 
>>> > > 
>>> > > 
>>> https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1
>>>  
>>> > > 
>>> > > I'm not sure what is the best way to check if /admin is routed to 
>>> > > django.contrib.admin. At the moment it's doing: 
>>> > > 
>>> > > resolve(admin_url)._func_path == 'django.contrib.admin.sites.index' 
>>> > > 
>>> > > Yes, I know! :-) 
>>> > > 
>>> > > I could also do something along the lines of: 
>>> > > resolve(admin_url).func.admin_site == admin.site 
>>> > > 
>>> > > This causes problems on the unit test side (need to import 
>>> admin.site). 
>>> > > Still I don't really like it. 
>>> > > 
>>> > > Does anyone have any better suggestions or comments? (or code 
>>> pointer). 
>>> > > Otherwise later on I'll have another look. 
>>> > > 
>>> > > Thank you very much, 
>>> > > 
>>> > > -- 
>>> > > Carles Pina i Estany 
>>> > > https://carles.pina.cat 
>>> > > 
>>> > 
>>> > -- 
>>> > 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/df485a53-2ad2-461f-95c8-f8f3857d67dbn%40googlegroups.com.
>>>  
>>>
>>>
>>> -- 
>>> Carles Pina i Estany 
>>> https://carles.pina.cat 
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to 

Re: Adding a security concerned feature

[Shoury Sharma]

 I've got this idea with the usage of json files that require some keys
which is authenticated for a single user which seems to excite me for fact
that if this was similar for admin/, then it'd give django a overhead
advantages for future use.

On Thu, 19 Nov, 2020, 4:09 pm Carlton Gibson, 
wrote:

> I think I'd come down as -1 for a system check here...
>
> They're not costless, there's a tendency to want to add a new system check
> for every possible configuration choice, but, beyond implementing and
> maintaining, the danger is it leads to too much noise.
> If you get a system check warning, you shouldn't be tempted to ignore it.
> In general I think reserving the built-in checks slightly means they don't
> get devalued. (Folks are free, and encouraged, to implement, and share,
> their own checks to enforce project-level standards.)
>
> I think it's not sufficiently clear-cut that using `/admin/` is a bad idea
> to justify including a check.
>
> (On a personal note, I like to use `/admin/`, configure nginx to only
> serve the admin from the localhost, and then use an SSH tunnel to access it
> remotely, so I'd have to silence a system check here.)
>
> C.
>
> On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany wrote:
>
>>
>> Hi,
>>
>> I wasn't convinced about changing the 'admin' path until recently. My
>> reasons to change the path of 'admin' are:
>>
>> -A bit less likely to be affected by bugs like
>>
>> https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
>> : at least the site wouldn't appear in automatic scans for
>> vulnerabilities (if checking Django versions based on the admin
>> template, etc.) . The bug/exploit might have been known before the fix
>> was implemented (and everyone updated) so I prefer to not be exposed (or
>> less exposed)
>>
>> -At the moment in Django there is no rate-limiting login attempts "out
>> of the box" so I prefer to avoid the opportunity if possible
>>
>> -Partially out of my control: an 'admin' user might have used the same
>> password in another place and the password got leaked
>>
>> Other people might have other reasons.
>>
>> Cheers,
>>
>> On Nov/18/2020, Tim Graham wrote:
>> > I'm not convinced that a system check promoting security by obscurity
>> adds
>> > much value. The original poster wrote "sometimes it can be a security
>> > concern." Maybe that's the case (how so?) but for most sites I would
>> say
>> > it's not.
>> > On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina Estany
>> > wrote:
>> >
>> > >
>> > > Hi,
>> > >
>> > > On Nov/16/2020, Carles Pina i Estany wrote:
>> > >
>> > > > Either way: I'd be happy to write a django check to make sure that
>> > > > 'admin/' is not routed to admin.
>> > >
>> > > Regarding this check: this morning I've done a very preliminary/for
>> fun
>> > > draft to play with.
>> > >
>> > >
>> > >
>> https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1
>> > >
>> > > I'm not sure what is the best way to check if /admin is routed to
>> > > django.contrib.admin. At the moment it's doing:
>> > >
>> > > resolve(admin_url)._func_path == 'django.contrib.admin.sites.index'
>> > >
>> > > Yes, I know! :-)
>> > >
>> > > I could also do something along the lines of:
>> > > resolve(admin_url).func.admin_site == admin.site
>> > >
>> > > This causes problems on the unit test side (need to import
>> admin.site).
>> > > Still I don't really like it.
>> > >
>> > > Does anyone have any better suggestions or comments? (or code
>> pointer).
>> > > Otherwise later on I'll have another look.
>> > >
>> > > Thank you very much,
>> > >
>> > > --
>> > > Carles Pina i Estany
>> > > https://carles.pina.cat
>> > >
>> >
>> > --
>> > 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/df485a53-2ad2-461f-95c8-f8f3857d67dbn%40googlegroups.com.
>>
>>
>> --
>> Carles Pina i Estany
>> https://carles.pina.cat
>>
> --
> 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/61afea37-34af-4271-91cb-e4a116c1eb71n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe 

Re: Adding a security concerned feature

[Carlton Gibson]

I think I'd come down as -1 for a system check here... 

They're not costless, there's a tendency to want to add a new system check 
for every possible configuration choice, but, beyond implementing and 
maintaining, the danger is it leads to too much noise. 
If you get a system check warning, you shouldn't be tempted to ignore it. 
In general I think reserving the built-in checks slightly means they don't 
get devalued. (Folks are free, and encouraged, to implement, and share, 
their own checks to enforce project-level standards.)

I think it's not sufficiently clear-cut that using `/admin/` is a bad idea 
to justify including a check. 

(On a personal note, I like to use `/admin/`, configure nginx to only serve 
the admin from the localhost, and then use an SSH tunnel to access it 
remotely, so I'd have to silence a system check here.) 

C.

On Wednesday, 18 November 2020 at 22:15:38 UTC+1 Carles Pina Estany wrote:

>
> Hi,
>
> I wasn't convinced about changing the 'admin' path until recently. My 
> reasons to change the path of 'admin' are:
>
> -A bit less likely to be affected by bugs like
>
> https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
> : at least the site wouldn't appear in automatic scans for
> vulnerabilities (if checking Django versions based on the admin
> template, etc.) . The bug/exploit might have been known before the fix
> was implemented (and everyone updated) so I prefer to not be exposed (or
> less exposed)
>
> -At the moment in Django there is no rate-limiting login attempts "out
> of the box" so I prefer to avoid the opportunity if possible
>
> -Partially out of my control: an 'admin' user might have used the same
> password in another place and the password got leaked
>
> Other people might have other reasons.
>
> Cheers,
>
> On Nov/18/2020, Tim Graham wrote:
> > I'm not convinced that a system check promoting security by obscurity 
> adds 
> > much value. The original poster wrote "sometimes it can be a security 
> > concern." Maybe that's the case (how so?) but for most sites I would say 
> > it's not.
> > On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina Estany 
> > wrote:
> > 
> > >
> > > Hi,
> > >
> > > On Nov/16/2020, Carles Pina i Estany wrote:
> > >
> > > > Either way: I'd be happy to write a django check to make sure that
> > > > 'admin/' is not routed to admin.
> > >
> > > Regarding this check: this morning I've done a very preliminary/for fun
> > > draft to play with.
> > >
> > >
> > > 
> https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1
> > >
> > > I'm not sure what is the best way to check if /admin is routed to
> > > django.contrib.admin. At the moment it's doing:
> > >
> > > resolve(admin_url)._func_path == 'django.contrib.admin.sites.index'
> > >
> > > Yes, I know! :-)
> > >
> > > I could also do something along the lines of:
> > > resolve(admin_url).func.admin_site == admin.site
> > >
> > > This causes problems on the unit test side (need to import admin.site).
> > > Still I don't really like it.
> > >
> > > Does anyone have any better suggestions or comments? (or code pointer).
> > > Otherwise later on I'll have another look.
> > >
> > > Thank you very much,
> > >
> > > -- 
> > > Carles Pina i Estany
> > > https://carles.pina.cat
> > >
> > 
> > -- 
> > 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/df485a53-2ad2-461f-95c8-f8f3857d67dbn%40googlegroups.com
> .
>
> -- 
> Carles Pina i Estany
> https://carles.pina.cat
>

-- 
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/61afea37-34af-4271-91cb-e4a116c1eb71n%40googlegroups.com.

Re: Adding a security concerned feature

[Carles Pina i Estany]

Hi,

I wasn't convinced about changing the 'admin' path until recently. My reasons 
to change the path of 'admin' are:

-A bit less likely to be affected by bugs like
https://docs.djangoproject.com/en/3.1/releases/3.0.1/#cve-2019-19844-potential-account-hijack-via-password-reset-form
: at least the site wouldn't appear in automatic scans for
vulnerabilities (if checking Django versions based on the admin
template, etc.) . The bug/exploit might have been known before the fix
was implemented (and everyone updated) so I prefer to not be exposed (or
less exposed)

-At the moment in Django there is no rate-limiting login attempts "out
of the box" so I prefer to avoid the opportunity if possible

-Partially out of my control: an 'admin' user might have used the same
password in another place and the password got leaked

Other people might have other reasons.

Cheers,

On Nov/18/2020, Tim Graham wrote:
> I'm not convinced that a system check promoting security by obscurity adds 
> much value. The original poster wrote "sometimes it can be a security 
> concern." Maybe that's the case (how so?) but for most sites I would say 
> it's not.
> On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina Estany 
> wrote:
> 
> >
> > Hi,
> >
> > On Nov/16/2020, Carles Pina i Estany wrote:
> >
> > > Either way: I'd be happy to write a django check to make sure that
> > > 'admin/' is not routed to admin.
> >
> > Regarding this check: this morning I've done a very preliminary/for fun
> > draft to play with.
> >
> >
> > https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1
> >
> > I'm not sure what is the best way to check if /admin is routed to
> > django.contrib.admin. At the moment it's doing:
> >
> > resolve(admin_url)._func_path == 'django.contrib.admin.sites.index'
> >
> > Yes, I know! :-)
> >
> > I could also do something along the lines of:
> > resolve(admin_url).func.admin_site == admin.site
> >
> > This causes problems on the unit test side (need to import admin.site).
> > Still I don't really like it.
> >
> > Does anyone have any better suggestions or comments? (or code pointer).
> > Otherwise later on I'll have another look.
> >
> > Thank you very much,
> >
> > -- 
> > Carles Pina i Estany
> > https://carles.pina.cat
> >
> 
> -- 
> 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/df485a53-2ad2-461f-95c8-f8f3857d67dbn%40googlegroups.com.

-- 
Carles Pina i Estany
https://carles.pina.cat

-- 
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/20201118211506.GA4744%40pina.cat.

Re: Adding a security concerned feature

[Tim Graham]

I'm not convinced that a system check promoting security by obscurity adds 
much value. The original poster wrote "sometimes it can be a security 
concern." Maybe that's the case (how so?) but for most sites I would say 
it's not.
On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina Estany 
wrote:

>
> Hi,
>
> On Nov/16/2020, Carles Pina i Estany wrote:
>
> > Either way: I'd be happy to write a django check to make sure that
> > 'admin/' is not routed to admin.
>
> Regarding this check: this morning I've done a very preliminary/for fun
> draft to play with.
>
>
> https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1
>
> I'm not sure what is the best way to check if /admin is routed to
> django.contrib.admin. At the moment it's doing:
>
> resolve(admin_url)._func_path == 'django.contrib.admin.sites.index'
>
> Yes, I know! :-)
>
> I could also do something along the lines of:
> resolve(admin_url).func.admin_site == admin.site
>
> This causes problems on the unit test side (need to import admin.site).
> Still I don't really like it.
>
> Does anyone have any better suggestions or comments? (or code pointer).
> Otherwise later on I'll have another look.
>
> Thank you very much,
>
> -- 
> Carles Pina i Estany
> https://carles.pina.cat
>

-- 
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/df485a53-2ad2-461f-95c8-f8f3857d67dbn%40googlegroups.com.

Re: Adding a security concerned feature

[Carles Pina i Estany]

Hi,

On Nov/16/2020, Carles Pina i Estany wrote:

> Either way: I'd be happy to write a django check to make sure that
> 'admin/' is not routed to admin.

Regarding this check: this morning I've done a very preliminary/for fun
draft to play with.

https://github.com/cpina/django/commit/199c2fb26dc6b323195b8136bda596d1cc9857f1

I'm not sure what is the best way to check if /admin is routed to
django.contrib.admin. At the moment it's doing:

resolve(admin_url)._func_path == 'django.contrib.admin.sites.index'

Yes, I know! :-)

I could also do something along the lines of:
resolve(admin_url).func.admin_site == admin.site

This causes problems on the unit test side (need to import admin.site).
Still I don't really like it.

Does anyone have any better suggestions or comments? (or code pointer).
Otherwise later on I'll have another look.

Thank you very much,

-- 
Carles Pina i Estany
https://carles.pina.cat

-- 
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/20201118123320.GA9221%40pina.cat.

Re: Adding a security concerned feature

[Carles Pina i Estany]

Hi Adam, Shoury,

About '/admin' URL to not be routed to admin: I can't remember if this
is documented in Django documentation (I can't find it right now). But
a lot of documentation on the internet says to change, in urls.py, from
path('admin/') to path('admin-something'). In my opinion the admin path
should be stored with the secrets of the application (like S3 keys,
SECRET_KEY, etc.) to make sure that it doesn't get into
GitHub/somewhere.

Another idea would be to create the ADMIN_URL='admin/' variable by
default in settings.py with a comment next to it: similar to SECRET_KEY
and also add a deployment check. So all (or more) changes to go to
production happen in settings.py instead of different places. Users
would be more aware of this from the beginning as well while editing
settings.py.

Either way: I'd be happy to write a django check to make sure that
'admin/' is not routed to admin.

rate-limiting: recently I've started using django-axes. I don't know if
any inspiration could be taken from there (
https://github.com/jazzband/django-axes ).

Cheers,


On Nov/16/2020, Adam Johnson wrote:
> Hi Shoury
> 
> I agree that this is an easy thing to change to prevent discovery of the
> admin. I've done it on several projects, and I saw Will Vincent mentioned
> it in his recent article on security:
> https://learndjango.com/tutorials/django-best-practices-security
> 
> Implementation-wise, perhaps we could add another system check that checks
> if /admin is routed to the admin, and recommends it be changed if so.
> 
> That said, such a check would not apply in every situation. I've seen
> Django projects that are *only* the admin, or that only exist on an
> internal trusted network, and there the '/admin' URL may be of use for
> discovery.
> 
> We also have other possible, stronger defenses here, such as adding
> rate-limiting to the login page: https://code.djangoproject.com/ticket/21289
> .
> 
> Thanks,
> 
> Adam
> 
> On Tue, 10 Nov 2020 at 20:30, Arvind Nedumaran 
> wrote:
> 
> > The one I follow is to set an environment variable to see if it’s a public
> > facing instance or a private one (disconnected from the internet) and use
> > that as a condition, which when true will add some urls.
> >
> > It’s the same pattern you’ll follow when using something like Django debug
> > toolbar - where you check if debug is true and if it is, you add some more
> > urls to the root urlconf conf.
> >
> > Hope that helps.
> >
> > P.s. This is the mailing list for contributions to Django itself.
> > Questions about how to use django are better suited in the Django Users
> > mailing list or the forums.
> >
> > Onward,
> > Arvind
> >
> > On 10 Nov 2020, at 14:46, Shoury Sharma wrote:
> >
> > Hello everyone!
> > I was going though idea of admin page but sometimes it can be a security
> > concern regarding access of admin stuff by URL/admin.
> > I would therefore like to give a suggestions regarding the URL/admin to be
> > some key which only the owners would have access to so the user can never
> > have anyway to check admin by penetrating into it in any malicious way.
> > Generous regards,
> > Shoury Sharma
> >
> > --
> > 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/46bf01ff-dc32-47ff-92bc-c56c260a9f29n%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/10669A3E-5DBB-46C8-8CF3-411C7DC149CC%40gmail.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/CAMyDDM3grhVVLo6cPT71Sdb8m3rwq_GkdDzqGrpRUd%2BN0xR%2BCg%40mail.gmail.com.
-- 
Carles Pina i Estany
https://carles.pina.cat

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django 

Re: Adding a security concerned feature

[Adam Johnson]

Hi Shoury

I agree that this is an easy thing to change to prevent discovery of the
admin. I've done it on several projects, and I saw Will Vincent mentioned
it in his recent article on security:
https://learndjango.com/tutorials/django-best-practices-security

Implementation-wise, perhaps we could add another system check that checks
if /admin is routed to the admin, and recommends it be changed if so.

That said, such a check would not apply in every situation. I've seen
Django projects that are *only* the admin, or that only exist on an
internal trusted network, and there the '/admin' URL may be of use for
discovery.

We also have other possible, stronger defenses here, such as adding
rate-limiting to the login page: https://code.djangoproject.com/ticket/21289
.

Thanks,

Adam

On Tue, 10 Nov 2020 at 20:30, Arvind Nedumaran 
wrote:

> The one I follow is to set an environment variable to see if it’s a public
> facing instance or a private one (disconnected from the internet) and use
> that as a condition, which when true will add some urls.
>
> It’s the same pattern you’ll follow when using something like Django debug
> toolbar - where you check if debug is true and if it is, you add some more
> urls to the root urlconf conf.
>
> Hope that helps.
>
> P.s. This is the mailing list for contributions to Django itself.
> Questions about how to use django are better suited in the Django Users
> mailing list or the forums.
>
> Onward,
> Arvind
>
> On 10 Nov 2020, at 14:46, Shoury Sharma wrote:
>
> Hello everyone!
> I was going though idea of admin page but sometimes it can be a security
> concern regarding access of admin stuff by URL/admin.
> I would therefore like to give a suggestions regarding the URL/admin to be
> some key which only the owners would have access to so the user can never
> have anyway to check admin by penetrating into it in any malicious way.
> Generous regards,
> Shoury Sharma
>
> --
> 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/46bf01ff-dc32-47ff-92bc-c56c260a9f29n%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/10669A3E-5DBB-46C8-8CF3-411C7DC149CC%40gmail.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/CAMyDDM3grhVVLo6cPT71Sdb8m3rwq_GkdDzqGrpRUd%2BN0xR%2BCg%40mail.gmail.com.

Re: Adding a security concerned feature

[Arvind Nedumaran]

The one I follow is to set an environment variable to see if it’s a 
public facing instance or a private one (disconnected from the internet) 
and use that as a condition, which when true will add some urls.


It’s the same pattern you’ll follow when using something like Django 
debug toolbar - where you check if debug is true and if it is, you add 
some more urls to the root urlconf conf.


Hope that helps.

P.s. This is the mailing list for contributions to Django itself. 
Questions about how to use django are better suited in the Django Users 
mailing list or the forums.


Onward,
Arvind


On 10 Nov 2020, at 14:46, Shoury Sharma wrote:


Hello everyone!
I was going though idea of admin page but sometimes it can be a 
security

concern regarding access of admin stuff by URL/admin.
I would therefore like to give a suggestions regarding the URL/admin 
to be
some key which only the owners would have access to so the user can 
never
have anyway to check admin by penetrating into it in any malicious 
way.

Generous regards,
Shoury Sharma

--
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/46bf01ff-dc32-47ff-92bc-c56c260a9f29n%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/10669A3E-5DBB-46C8-8CF3-411C7DC149CC%40gmail.com.