Re: add prefered/default protocol in the sites framework #26079

[James Addison]

In using Marten Kenbeek's URL dispatch rewrite branch, I've found that
using the pattern of defining some site configuration in your settings is
the way to go: it more easily allows you to have URL patterns on multiple
domain/scheme combinations.

I use a dict similar to what Tim has shown, and then use it to initialize
my scheme/domain URL constraints in my root urls.py.
On Jan 25, 2016 08:01, "Tim Graham"  wrote:

> Oh, looks like django-hosts also has this problem. It looks like in some
> cases the URLs will be correct (due to the PARENT_HOST setting, I think,
> which is 'djangoproject.dev:8000' in the djangoproject.com dev settings),
> but if you are browsing a different host (e.g. the docs site), then those
> URLs use the value from the Site model.
>
> Another thought: I've sometimes thought that the Site model violates the
> principle that you shouldn't put configuration in your database. I guess
> there's some usefulness to having a ForeignKey to the site, but... would it
> be feasible to offer a SITES setting that could be used instead? e.g.
>
> SITES = {
> 1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
> ...
> }
>
> That would solve the portability issue, I think, since you could easily
> override the necessary parts in development settings. Not sure if it'd be
> palatable to deprecation the models though. I don't think maintaining both
> versions would be worthwhile in the long run.
>
> On Monday, January 25, 2016 at 9:57:39 AM UTC-5, Aymeric Augustin wrote:
>>
>> On 25 janv. 2016, at 14:19, Tim Graham  wrote:
>>
>>
>> I believe it's a common use case to import a copy of a production
>> database and examine it locally -- that's what I meant about portability.
>>
>>
>> I’m not convinced by this argument because the data for the Site model
>> will be wrong anyway in this situation. Or did I miss something?
>>
>> --
>> Aymeric.
>>
>> --
> 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/b12433a7-aa49-4951-9a77-32747699038d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CALfx8k3fZev0ZOfUdKBq-74qSa6qu5n-O7pBTcLz9q7-25Sb%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[Carl Meyer]

On 01/25/2016 09:01 AM, Tim Graham wrote:
> Oh, looks like django-hosts also has this problem. It looks like in some
> cases the URLs will be correct (due to the PARENT_HOST setting, I think,
> which is 'djangoproject.dev:8000' in the djangoproject.com dev
> settings), but if you are browsing a different host (e.g. the docs
> site), then those URLs use the value from the Site model.
> 
> Another thought: I've sometimes thought that the Site model violates the
> principle that you shouldn't put configuration in your database. I guess
> there's some usefulness to having a ForeignKey to the site, but... would
> it be feasible to offer a SITES setting that could be used instead? e.g.
> 
> SITES = {
> 1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
> ...
> }
> 
> That would solve the portability issue, I think, since you could easily
> override the necessary parts in development settings. Not sure if it'd
> be palatable to deprecation the models though. I don't think maintaining
> both versions would be worthwhile in the long run.

+1 to this, I've long felt that the Site model was an anti-pattern. I
don't know if it's worth deprecating and switching to a different
system, though; it'd be a relatively painful deprecation for those using
it, I would guess.

Carl

-- 
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/56A6473F.50203%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: add prefered/default protocol in the sites framework #26079

[Tim Graham]

Oh, looks like django-hosts also has this problem. It looks like in some 
cases the URLs will be correct (due to the PARENT_HOST setting, I think, 
which is 'djangoproject.dev:8000' in the djangoproject.com dev settings), 
but if you are browsing a different host (e.g. the docs site), then those 
URLs use the value from the Site model.

Another thought: I've sometimes thought that the Site model violates the 
principle that you shouldn't put configuration in your database. I guess 
there's some usefulness to having a ForeignKey to the site, but... would it 
be feasible to offer a SITES setting that could be used instead? e.g.

SITES = {
1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
...
}

That would solve the portability issue, I think, since you could easily 
override the necessary parts in development settings. Not sure if it'd be 
palatable to deprecation the models though. I don't think maintaining both 
versions would be worthwhile in the long run.

On Monday, January 25, 2016 at 9:57:39 AM UTC-5, Aymeric Augustin wrote:
>
> On 25 janv. 2016, at 14:19, Tim Graham  
> wrote:
>
>
> I believe it's a common use case to import a copy of a production database 
> and examine it locally -- that's what I meant about portability.
>
>
> I’m not convinced by this argument because the data for the Site model 
> will be wrong anyway in this situation. Or did I miss something?
>
> -- 
> Aymeric.
>
>

-- 
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/b12433a7-aa49-4951-9a77-32747699038d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[Aymeric Augustin]

> On 25 janv. 2016, at 14:19, Tim Graham  wrote:
> 
> I believe it's a common use case to import a copy of a production database 
> and examine it locally -- that's what I meant about portability.

I’m not convinced by this argument because the data for the Site model will be 
wrong anyway in this situation. Or did I miss something?

-- 
Aymeric.

-- 
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/AD243A26-0ADA-4A7A-9568-DF2F3653FC95%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[Tim Graham]

I believe it's a common use case to import a copy of a production database 
and examine it locally -- that's what I meant about portability.

I'm not aware of any Django usage that involves serving protocols other 
than http(s). Is this a case you've come across?

On Monday, January 25, 2016 at 4:34:25 AM UTC-5, Eric Rouleau wrote:
>
>
>1. it's not necessarily about SSL, it can be for any protocol but SITE 
>dependent.
>2. and for the dev/prod , your data will be different anyway so you 
>put the preferred protocol accordingly to your setup.
>3. it's only for generating full URLs, not for internal links (ex: 
>sitemaps). 
>
> a settings option could work too for sure, but I think we have more 
> flexibility with the sites framework, and any time you need the protocol 
> it's to generate a full URL which also needs the domain name.
>
>

-- 
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/28c72705-db21-484c-8b1a-80621a52b4b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[Eric Rouleau]

   
   1. it's not necessarily about SSL, it can be for any protocol but SITE 
   dependent.
   2. and for the dev/prod , your data will be different anyway so you put 
   the preferred protocol accordingly to your setup.
   3. it's only for generating full URLs, not for internal links (ex: 
   sitemaps). 

a settings option could work too for sure, but I think we have more 
flexibility with the sites framework, and any time you need the protocol 
it's to generate a full URL which also needs the domain name.

-- 
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/2d0a6998-e21d-4a56-8380-2cf1273e3f97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[Daniel Chimeno]

Hi,

I think the same in the case of:

>
>1. It would make data less portable between development (where SSL is 
>often not in use) and production.
>
> So maybe  a settings option could work.


El miércoles, 13 de enero de 2016, 14:21:14 (UTC+1), Eric Rouleau escribió:
>
> Hi
>
> I've created a ticket to propose adding a preferred/default protocol in 
> the "sites" framework at https://code.djangoproject.com/ticket/26079
>
> tim suggested I bring this to the mailing list and said the following:
>
> I'm not immediately convinced that a database field is the way to go for a 
>> couple reasons:
>>
>>1. It would make data less portable between development (where SSL is 
>>often not in use) and production.
>>2. I'm not sure it's a common case that only some sites would use SSL 
>>but not others.
>>
>> A third-party library called django-hosts, which djangoproject.com uses, 
>> adds a setting called ​HOSTS_SCHEME 
>> 
>>  to 
>> solve this. I think there's been some discussion about merging at least 
>> parts of this library into core since it solves common problems.
>>
>> See also #10944  (we might 
>> close this ticket as a duplicate of that one) and #23829 
>>  (about customizing 
>> ping_google to allow https). I think the best course of action would be 
>> to consider this feedback and write to the DevelopersMailingList 
>>  with your 
>> proposal. Either solution of a new setting or a new database field need 
>> feedback from a wider audience. Thanks!
>>
>
>- actually I would say it is even more portable as you 
>would probably use different databases between dev and prod , meaning you 
>can have http in dev but https in prod
>- its not just for SSL but also maybe a it could be used with other 
>protocols/schemes such as dav, webcal, feed
>- third party libraries could now have a definitive way of generating 
>a full URL 
>
> what do you guys think?
>
>

-- 
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/7063ff52-e065-4193-b615-f70c5cf45f1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[Eric Rouleau]

since no feedback has been given yet,   I will add that the change is just 
an addition (new feature)  meaning there is no breaking of code , it just 
provides a way to define a default protocol for a given SITE, and will 
ultimately default to http when none is specified

-- 
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/df5ea735-b41e-4197-96a8-2cb6333bf3de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

add prefered/default protocol in the sites framework #26079

[Eric Rouleau]

Hi

I've created a ticket to propose adding a preferred/default protocol in the 
"sites" framework at https://code.djangoproject.com/ticket/26079

tim suggested I bring this to the mailing list and said the following:

I'm not immediately convinced that a database field is the way to go for a 
> couple reasons:
>
>1. It would make data less portable between development (where SSL is 
>often not in use) and production.
>2. I'm not sure it's a common case that only some sites would use SSL 
>but not others.
>
> A third-party library called django-hosts, which djangoproject.com uses, 
> adds a setting called ​HOSTS_SCHEME 
> 
>  to 
> solve this. I think there's been some discussion about merging at least 
> parts of this library into core since it solves common problems.
>
> See also #10944  (we might 
> close this ticket as a duplicate of that one) and #23829 
>  (about customizing 
> ping_google to allow https). I think the best course of action would be 
> to consider this feedback and write to the DevelopersMailingList 
>  with your 
> proposal. Either solution of a new setting or a new database field need 
> feedback from a wider audience. Thanks!
>

   - actually I would say it is even more portable as you 
   would probably use different databases between dev and prod , meaning you 
   can have http in dev but https in prod
   - its not just for SSL but also maybe a it could be used with other 
   protocols/schemes such as dav, webcal, feed
   - third party libraries could now have a definitive way of generating a 
   full URL 

what do you guys think?

-- 
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/4daa6fb3-071a-4ca0-849c-63283cc3737b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.