Re: Improving MSSQL and Azure SQL support on Django

[r...@whidbey.com]

Good news.  I've been using Django on MSSQL for about 8 years.  Couple of 
things:
- I've been using pyodbc, not django-mssql.  I note your messages from 2015 
include it as a library to check for compatibility; what was the outcome of 
that?  Is it proposed that django-mssql become the "best-practices" 
interface for SQL Server?
- Couple of persistent pain points:
  1. Testing.  The Django code that sets up test databases fails with 
MSSQL, while it succeeds with PostGRE, MySQL and SQLite.  The issues seem 
to revolve around setting constraints as the tables are generated, rather 
than holding off and enabling the constraints at the end of the process.
  2. Stored Procedures.  These need to be loaded as an additional step in 
the creation of a database, and don't really have any representation in 
Django per se so migrations, etc don't generally have an idea that they 
exist.

I'd be happy to test out what you come up with against our system.  It's 
currently serving a custom REST interface with 2-million-plus rows of 
transactions,with clients world-wide, along with a customer-facing web app, 
a staff site and a suite of Tableau reports.

On Thursday, November 26, 2020 at 5:40:18 PM UTC-8 vwa...@gmail.com wrote:

> Hi All,
>
> Microsoft has now committed ongoing resources towards improving MSSQL and 
> Azure SQL support for Django. We're currently focused on internal 
> compliance and forking the ESSolutions django-mssql-backend 
> , adding testing 
> pipelines, refactoring the Django DB engine naming convention, and 
> addressing current test suite errors.
>
> We'd love to hear from current mssql-backend maintainers as well as 
> mssql-backend users about the existing issues and feature requests that we 
> should be prioritizing.
>
> We looking forward to engaging the community and working towards MSSQL as 
> a first-class supported backend for Django.
>
> -Warren
>
> On Wednesday, 4 December 2019 at 07:05:25 UTC-8 Tim Allen wrote:
>
>> Hi Sean, just an update from what I know.
>>
>> We are still waiting for a reply from Microsoft. They're a large company, 
>> so understandably, it takes a little while.
>>
>>
>> For now, if people need to get onto Django 2.2 for long term support 
>> (which will last until April, 2022), you can use this package:
>>
>> https://github.com/ESSolutions/django-mssql-backend I've been running it 
>> in production for months without incident. Of course, YMMV.
>>
>>
>> If Microsoft and/or the DSF end up wanting to bring support under the 
>> Django umbrella, the django-mssql-backend repository is a possible 
>> starting point, IMHO.
>>
>> The django-mssql-backend is currently being developed and support for 
>> Django 3.0 is being worked on: ESSolutions/django-mssql-backend#18 
>> 
>>
>>
>> Regards,
>>
>>
>> Tim
>>
>> On Monday, December 2, 2019 at 11:03:56 AM UTC-5, Sean Martz wrote:
>>>
>>> Hello,
>>>
>>> It seems like this issue has lost momentum. Is this still something 
>>> that's on anyones radar? It looks like django-pyodbc-azure is not actively 
>>> maintained anymore (it looks like Michaya has taken a hiatus from GitHub). 
>>> It also looks like there's a small community potentially popping up that's 
>>> interested in first class MSSQL Server support for Django. (
>>> https://github.com/FlipperPA/django-mssql-backend). Is Microsoft still 
>>> interested in committing resources to this goal? In my situation, it would 
>>> be a lot easier to sell stakeholders and decision makers on Django if it 
>>> had first class support for MSSQL Server.
>>>
>>> For what it's worth, Django-pyodbc-azure is still working well.
>>>
>>> Cheers,
>>> Sean
>>>
>>>

-- 
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/a531fb44-4a5c-48f3-b28c-d78e3419141fn%40googlegroups.com.

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