Sponsor subdomain pointing to part of our Django site?

[Richard Brockie]

Hi,

I’m wondering if it is possible to use a subdomain of a sponsor’s url as an alias to a particular part of our Django site?

Our Django site has urls of the form: “site.url/year/slug/*” where “*” represents a large set of child pages for various data reports and update actions related to a particular race. Here’s an example: https://ontheday.net/2017/pescadero/

What we would like is for an alias of the form: “subdomain.sponsor.url/” to reference “ontheday.net/year/slug/” and work just the same as if we are accessing the site using our standard url. This includes updating links displayed in our pages that are viewed using the sponsor subdomain.

I see I might want to do some inspection of the incoming url which points me in the direction of the sites framework and django-hosts: https://github.com/jazzband/django-hosts. Also, a second SSL certificate is likely to be required.

Any advice on how I can accomplish this? Any particular things I would need to do in the Django project to make this possible?

Many thanks!

Richard

[Melvyn Sopacua]

On zondag 3 juni 2018 22:45:31 CEST Richard Brockie wrote:

> Any advice on how I can accomplish this? Any particular things I would need
> to do in the Django project to make this possible?

Since you seem to be using the {% url %} tag and have no absolute URLs with
the hostname in it, I don't think Django is part of the problem, short of
ALLOWED_HOSTS setting.

Your problem would be in the webserver configuration and as you suspected the
SSL certificate.

Why don't you add a subdomain 'test', add it to allowed hosts setting, add the
certificate and see what breaks. I don't think anything breaks at all.
--
Melvyn Sopacua

[Richard Brockie]

Hi Melvyn,

Thanks for the reply. We will test this after getting the ssl certificates sorted out.

However, I'm pretty sure that we will need to make some changes to our project to deal with links when the site is being accessed through "subdomain.sponsor.url/". You are correct that {% url %} is used in the templates as well as django.core.urlresolvers.reverse() being used in the code. However, I think we need to catch the case where url or reverse() are returning "site.url/year/slug/some/more/path/" and convert it to "subdomain.sponsor.url/some/more/path/" based on the http_host in the request.

I'm wondering if this is a solved problem?

Thanks,

R.

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/jZt_bO2dR5c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/33245904.Kc6r1lpH81%40fritzbook.
For more options, visit https://groups.google.com/d/optout.

--

    R.

Richard Brockie

Real-time bicycle race results - www.ontheday.net

[Melvyn Sopacua]

On maandag 4 juni 2018 13:26:24 CEST Richard Brockie wrote:

 

> However, I'm pretty sure that we will need to make some changes to our

> project to deal with links when the site is being accessed through

> "subdomain.sponsor.url/". You are correct that {% url %} is used in the

> templates as well as django.core.urlresolvers.reverse() being used in the

> code. However, I think we need to catch the case where url or reverse() are

> returning "site.url/year/slug/some/more/path/" and convert it to

> "subdomain.sponsor.url/some/more/path/" based on the http_host in the

> request.

>

> I'm wondering if this is a solved problem?

 

This isn't a problem. Neither url nor reverse is capable of returning URLs with hostnames, at least not that I'm aware of. Only django.contrib.site module can do this for out-of-band communications.

 

So if you're encountering such cases, then you're using custom or 3rd party code or have a hardcoded hostname in your templates or are using the site module.

 

There is no magic case where reverse or the url template tag decides to add a hostname, because it senses you want it. And if you just want to serve the exact same site on a different domain, then ALLOWED_HOSTS is all you need.

 

If you want to brand the site with a different look and feel, then you will need the site module, because then you will serve different content.

 

If you're asking "how can i be sure there are no mistakes in our code", then you should already know the answer - test, test, test :).

--

Melvyn Sopacua

[Richard Brockie]

On Mon, Jun 4, 2018 at 9:01 PM Melvyn Sopacua <m.r.s...@gmail.com> wrote:

This isn't a problem. Neither url nor reverse is capable of returning URLs with hostnames, at least not that I'm aware of. Only django.contrib.site module can do this for out-of-band communications.

Aha - there's an error in how I posed the question. I was confusing the url and reverse() outputs with the links as interpreted by a browser.

If http_host is ''subdomain.sponsor.url" we are at the site using the sponsor's alias which maps to a unique "/year/slug/" on our site (just one of many). In this case, we require the output of {% url %} and reverse() to have 2 possibilities:

1. Normal operation (with our default http_host): returns the full path: "/year/slug/some/more/path/"
2. Sponsor http_host: returns a trimmed path: "/some/more/path". Here "/year/slug" is suppressed as it is built into the ''subdomain.sponsor.url" alias.

I hope this clarifies what we think we need to do?

 

So if you're encountering such cases, then you're using custom or 3rd party code or have a hardcoded hostname in your templates or are using the site module.

 

There is no magic case where reverse or the url template tag decides to add a hostname, because it senses you want it. And if you just want to serve the exact same site on a different domain, then ALLOWED_HOSTS is all you need.

We're wanting to do something else - the sponsor's subdomain points to just one part of our site. We want to keep the charade of this part of our site being part of the sponsor subdomain so the urls that we present to browsers have to adjust correctly.

 

You rightly deduce that we are going to brand this part of the site differently, but this will be global and will not depend on the http_host.

Thanks!

R.

 

If you want to brand the site with a different look and feel, then you will need the site module, because then you will serve different content.

 

If you're asking "how can i be sure there are no mistakes in our code", then you should already know the answer - test, test, test :).

--

Melvyn Sopacua

--

You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/jZt_bO2dR5c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1789736.NRtqCP1Ze9%40fritzbook.

For more options, visit https://groups.google.com/d/optout.

[Melvyn Sopacua]

On maandag 4 juni 2018 20:40:03 CEST Richard Brockie wrote:

> On Mon, Jun 4, 2018 at 9:01 PM Melvyn Sopacua <m.r.s...@gmail.com> wrote:

> > This isn't a problem. Neither url nor reverse is capable of returning URLs

> > with hostnames, at least not that I'm aware of. Only django.contrib.site

> > <https://docs.djangoproject.com/en/2.0/ref/contrib/sites/#getting-the-curr

> > ent-domain-for-display> module can do this for out-of-band communications.

>

> Aha - there's an error in how I posed the question. I was confusing the url

> and reverse() outputs with the links as interpreted by a browser.

>

> If http_host is ''subdomain.sponsor.url" we are at the site using the

> sponsor's alias which maps to a unique "/year/slug/" on our site (just one

> of many). In this case, we require the output of {% url %} and reverse() to

> have 2 possibilities:

>

> 1. Normal operation (with our default http_host): returns the full path:

> "/year/slug/some/more/path/"

> 2. Sponsor http_host: returns a trimmed path: "/some/more/path". Here

> "/year/slug" is suppressed as it is built into the

> ''subdomain.sponsor.url" alias.

>

> I hope this clarifies what we think we need to do

 

Aha! Now I get it! This should be solveable at the WSGI layer:

 

PATH_INFO

The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.

 

See https://www.python.org/dev/peps/pep-0333/

 

A URL rewrite or proxy at the webserver level should work as well. It may take a bit of experimenting.

 

--

Melvyn Sopacua

[James Schneider]

Would URL rewrites solve this? How does that affect URL's generated in the template?

It sounds like a separate 'site' with the sites framework is needed, along with a modified urls.py that does not include the year and slug in the path.

Your might be able to use the existing urls.py by making the year and slug optional in the regex. When using the sponsored site, you would pass along extra context to the URL dispatcher that includes the year/slug or whatever data is being assumed by the usage of the sponsor URL.

Basically, you need two different paths to the same resource, dependent on the domain name or site in question.

Why not just leave the year and slug in and save yourself the extra work? Is the vanity path a requirement or just 'nice to have'?

-James

[Richard Brockie]

Hi James,

On Tue, Jun 5, 2018 at 2:19 PM James Schneider <jrschn...@gmail.com> wrote:

On Mon, Jun 4, 2018, 12:37 PM Melvyn Sopacua <m.r.s...@gmail.com> wrote:

Aha! Now I get it! This should be solveable at the WSGI layer:

 

PATH_INFO

The remainder of the request URL's "path", designating the virtual "location" of the request's target within the application. This may be an empty string, if the request URL targets the application root and does not have a trailing slash.

 

See https://www.python.org/dev/peps/pep-0333/

 

A URL rewrite or proxy at the webserver level should work as well. It may take a bit of experimenting.

Would URL rewrites solve this? How does that affect URL's generated in the template?

I also don't think this works for the outbound traffic for the html urls.

It sounds like a separate 'site' with the sites framework is needed, along with a modified urls.py that does not include the year and slug in the path.

I don't think I need to do this: assuming the subdomain.sponsor.url resolves correctly to include the required path, this is already taken care of.

 

Your might be able to use the existing urls.py by making the year and slug optional in the regex. When using the sponsored site, you would pass along extra context to the URL dispatcher that includes the year/slug or whatever data is being assumed by the usage of the sponsor URL.

I think I follow what you're suggesting. However, I think this would require a wholesale redesign of urls.py and I'm not clear I can see how this might work given all the other functions that are already in place. I'll ponder a little more as our urls.py could benefit from a major scrub/refactor. If we could get this to work in the urls.py, then I think we are done.

Failing that, I'm now wondering if there is something we can do to call and modify the output of {% url %} and reverse() ourselves? I think there is essentially a worked example in django-hosts (https://github.com/jazzband/django-hosts). Maybe that these functions are emulated in django-hosts is a hint that urls.py is not the way to go?

 

Basically, you need two different paths to the same resource, dependent on the domain name or site in question.

Why not just leave the year and slug in and save yourself the extra work? Is the vanity path a requirement or just 'nice to have'?

If we do implement this, the vanity path is a requirement as subdomain.sponsor.url essentially duplicates the /year/slug/ part of the path. There are other parts of our site that we could in future want to associate with other sponsors in a similar manner, so the /year/slug/ must go!

Thanks for helping me think this through,