Re: Integrate dj-database-url into Django

[linus]

There's also https://github.com/doismellburning/django12factor - and it 
simplifies all the boilerplate, that is still required in django-environ, 
into:

import django12factorglobals().update(django12factor.factorise())


It would be quite nice if Django supported 12factor configuration natively, 
or at least with a single function call like this one.

Regards,
Linus

On Sunday, May 28, 2017 at 12:09:57 AM UTC+2, Tim Allen wrote:
>
> I've recently been introduced to `django-environ`, a similar library that 
> has additional features to DB connect URLs that we may want to consider: 
> https://github.com/joke2k/django-environ
>
> It has the same issue with third party DB engines; for example, I recently 
> issued a PR to include `pyodbc` as an option. It has some nice newcomer 
> friendly features, such as a cleaner way of determining BASE_URL / 
> SITE_ROOT. Have a look at the URL for a good "before" and "after" settings 
> file example.
>
> Having full support for .env files would make Django projects easier to 
> bring in line with 12-factor.
>
> Regards,
>
> Tim
>
> On Saturday, May 27, 2017 at 3:52:23 PM UTC-4, Tom Forbes wrote:
>>
>> Edit: DJANGO_SETTINGS_MODULE isn't relative, it will import any arbitrary 
>> module you give it. If we accept that then I think we are accepting the 
>> risk of imports via an attacker controlling environment variables whilst 
>> Django starts up?
>>
>> On Sat, May 27, 2017 at 8:49 PM, Tom Forbes  wrote:
>>
>>> > I'm wary of possible security ramifications: if we do this, changing a 
>>> configuration value will import an arbitrary module, which could make it 
>>> easier to run arbitrary code in some scenarios. I don't have a clear threat 
>>> model in mind here, though.
>>>
>>> Good point, it's not wise to enable this even without a clear threat 
>>> model. Django does import the settings based on an environment variable, 
>>> but it's relative and if you can use that to do anything nasty then you're 
>>> most likely already through the airtight hatch (so to speak). However 
>>> importing potentially global modules could be bad news.
>>>
>>> Ignoring it is always an option, but could we not specify that the third 
>>> party database provider has to be in the `INSTALLED_APPS`? That could 
>>> provide some form of whitelisting so not any old module is imported. Not 
>>> sure about any issues that may arise from this though.
>>>
>>> > One possibility would be to use entrypoints in setuptools, this way 
>>> 3rd party backends could specify a name which then has a fixed & verified 
>>> import path.
>>>
>>> This seems like it could get complex, and be quite unlike anything else 
>>> in Django.
>>>
>>> Perhaps just supporting this for first-party database backends is 
>>> easiest?
>>>
>>> On Thu, May 25, 2017 at 8:46 AM, Aymeric Augustin <
>>> aymeric@polytechnique.org> wrote:
>>>
 Hello,

 I'm wondering what the exact definition of the URL format is. Is it 
 specified somewhere? Or is it just:

 [engine]://[username]:[password]@[host]:[port]/[name]

 where we create arbitrary [engine] values in an ad-hoc fashion?

 On 24 May 2017, at 21:21, Tom Forbes  wrote:

 My two cents: connection strings/database URI's are a feature I've 
 sorely missed in Django.

 Built-in functionality to convert environment variables like 
 DJANGO_DB_DEFAULT (or more generally DJANGO_DB_*key*) into the relevant 
 DATABASE setting would make some deployment situations a lot simpler. 
 Currently, unless you use dj-database-uri you have to define a bunch of 
 ad-hoc DB_USER/DB_PASSWORD etc env variables and price the dictionary 
 together yourself.


 Fully agreed. While relatively minor, it's an annoyance.

 How does this library complex keys like OPTIONS, TEST or DEPENDENCIES?


 I don't think it's reasonable to cram them in a URL.

 dj-database-url allows passing options as extra keyword arguments. 
 Other values should be explicitly added in the settings module, by 
 updating 
 the dict generated from the URL.

 To help support third part backends: perhaps the scheme portion of the 
 URI could be either a relative import from django.db.backends or an 
 absolute import to a third party library? It seems URI schemes can 
 have dots and underscores in them, so they can be python package paths.

 I.e sqlite3://xyz would resolve go django.db.backends.sqlite3, but 
 sqlserver_ado://xyz would resolve to the third party django-mssql engine 
 via an absolute import.


 I'm wary of possible security ramifications: if we do this, changing a 
 configuration value will import an arbitrary module, which could make it 
 easier to run arbitrary code in some scenarios. I don't have a clear 
 threat 
 model in mind here, though.

 I'd rather specify the database engine 

Re: Responsive admin

[elky]

Bump!

Sorry for so long silence. Seems it's done - I added some more tweaks to 
the app.

Regarding third-party apps, I think the most less-painful ways to disable 
responsive css are:
- override responsive.css or make it empty;
- override admin base.html to remove  tag which 
enables responsive stuff for devices (it won't help for desktop browsers).


I prepared demo site for quick testing, it contains few models with some 
non-trivial admin features. Feel free to test it on your device!   

http://demo.elky.me/
login: demo
password: demo

Any CSS problems? Please report here 
.
If you think to add more admin features to test (I missed something or you 
have complex example) please create an issue or submit pull request here 
.

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/15f742c3-5088-4259-8ba5-29720c3fc72a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.