Re: Allow scroll on jQuery fancy Table

2021-12-30 Thread Joel Tanko
A simple tweak I would use is to find the elements id using DEV tools and
set the
element{
 overflow: auto
} using css

On Wed, Dec 8, 2021, 1:10 PM Eugene TUYIZERE 
wrote:

> Dear Team,
>
> I am using jquery fancyTable in the django app but I searched everywhere
> and I did not find how to allow the scroll bar when fancyTable is used in
> django. Does anyone know how to do that? This is the code I have and I what
> to allow scroll bar:
>
>
> 
> const itemsPerPage = 12;
> if (100 > itemsPerPage) {
> $(".items").fancyTable({
> sortColumn: 0,
> sortable: true,
> pagination: true,
> searchable: true,
> globalSearch: true,
> paginationClass: "btn btn-secondary btn-sm",
> paginationClassActive: "active",
> pagClosest: 3,
> perPage: itemsPerPage,
> });
> }
> 
>
> * Eugene*
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CABxpZHvNNkny_N89-VBFP4nR57Yd%2Barfxvo74CdDCWzhz%3DqgTg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJ4Kmg4UjK5aTw8N9jZBeZfTvc%2BbJDY_fRHhjHN0FY%2BV9ffHSw%40mail.gmail.com.


Re: Not sure if I am doing django-paypal correctly

2021-12-30 Thread Joel Tanko
The code is really simple to implement, but I don't think the explanation
was intuitive enough.

You would need to create a signal like so

#hooks.py
from django.dispatch import Signal

success_signal = Signal(providing_args=[])

#views.py
from .hooks import success_signal
... # after payment

success_signal.connect(handler_function)
success_signal.send(sender=None, **kwargs)

This assumes that you already have a listener waiting for the signal
broadcast,
Also replace None with your sender (optional), and replace **kwargs with
any kwargs you're sending to your listeners.

Cheers


On Wed, Dec 29, 2021, 9:23 PM lone...@gmail.com  wrote:

> Hello all,
>
>   I decided to try and accept payments on my web application.  I have
> chosen the django-paypal application to help me out with this task.  I
> found a decent walkthrough at:
> how-to-accept-paypal-payments-on-your-django-application
> .
> I was able to follow everything until the last step of: "6. Setup a
> listener to detect successful Paypal payments"  I have never really setup
> any listeners before so I did not know what to do.  I decided to read the 
> Django-PayPal
> ReadTheDocs
>  and I
> found a file that looked structurally similar to what I found on the
> original walkthrough I had found.  It looks like I needed to make a
> hooks.py file in my project directory.  I have accomplished that, and the
> ReadTheDocs says: "Remember to ensure that import the hooks file is
> imported i.e. that you are connecting the signals when your project
> initializes. The standard way to do this is to create an AppConfig class
> 
>  and
> add a ready()
> 
>  method,
> in which you can register your signal handlers or import a module that does
> this."  This is where I am getting lost.  I am not quite sure what to
> do.  Does anyone have a better walkthrough or know what I need to do?
>
> Thank you.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/d9567663-20fb-4f43-a6c5-131f23497a7bn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJ4Kmg7mQXtRCh3MCTS-jKVdfoK0ZW5BTc2PLFWTO5142hcyRQ%40mail.gmail.com.


Re: Automatic subdomain for each user

2021-12-30 Thread Joel Tanko
Check out the django-hosts package, the docs are pretty explanatory and
easy to use.
You'd also want to add '.yourdomain' to the allowed_hosts list and it
doesn't work with '127.0.0.1' as its harder for if to figure out the
sub-domain, if you want to use it on your development server use localhost,
e.g mrj.localhost:8000

On Thu, Dec 30, 2021, 12:02 AM Sherif Adigun  wrote:

> I am faced with a requirement where each user is required to use the
> application under his own subdomain. Whenever a user registers, he gets
> username.domain.com and he can add staff, manage reports, etc under his
> subdomain.
>
> What is the best approach to you can suggest please?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/f330ad74-75c1-4244-ae27-aa6b97717940n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJ4Kmg7P12reF-DN_uuLg%3DvAn6sb0yu%3DScWUHZ1%2BxeZyHdoJKw%40mail.gmail.com.


"include super" with django templates?

2021-12-30 Thread Nick Farrell
I would like to extend a django template which is used via the include 
macro. That is, I want to add additional output before or after what would 
otherwise be emitted.

With the normal {% block %} syntax, it's easy to use super to follow the 
template heirachy similar to __mro__ - but to my knowledge there isn't an 
equivalent for include().

For example, form.as_p() calls render() with a template (by default, 
django/forms/p.html). I want my application to modify this, so whenever 
p.html is rendered, it is wrapped by my application's supplied template. 
(As I want this to work for any form instance, I cannot just override the 
default template name)

Another example is 
say django/forms/templates/django/forms/widgets/number.html. It consists of 
a single include() statement pointint to input.html. I would like to 
override input.html, but in a way which eventually renders the original 
template, in addition to my application's template.

Any suggestions?

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9ab15060-2dcd-44a0-abe3-eaeed8015813n%40googlegroups.com.


Re: Automatic subdomain for each user

2021-12-30 Thread Nick Farrell
Once you have the TLS certificates and routing working, can't you make a 
tiny piece of middleware which takes the hostname (provided via 
nginx/apache in a request header) and add an attribute on the request which 
corresponds to your virtual site?

e.g. (dodgy untested code follows):
def multisite_middleware(get_response): def middleware(request): 
domain_name = request.META.get('HTTP_HOST', DEFAULT_DOMAIN)
request.my_site = Site.objects.get(id=domain_name) response = 
get_response(request) return response return middleware

Then anywhere in your code you can access request.my_site for the 
site-specific data you need.

In addition, if you haven't already, take a look 
at https://docs.djangoproject.com/en/4.0/ref/contrib/sites/
On Friday, 31 December 2021 at 07:03:44 UTC+11 adigun...@gmail.com wrote:

> Thank you for your detailed response. Following your response point by 
> point with few additional googling, it works as expected.
>
> On cpanel:
> I created a subdomain called *
> Then I chose document root as the main Django root. (This is needed so 
> that letsencrypt can automatically create a certificate.)
>
> Then the routing works seemlessly
>
> Thank you
>
> On Thu, Dec 30, 2021, 7:06 PM Sherif Adigun  wrote:
>
>> Thank you very much for you guidance. I have been able to make it work 
>> using Django-hosts on my local. Still trying to fix it out to work on my 
>> shared hosting if possible
>>
>> On Thu, Dec 30, 2021, 10:29 AM Sherif Adigun  wrote:
>>
>>> Thank you @Tim.  Django subdomains looks promising but it's outdated. It 
>>> uses codes and imports of django< v2  I have checked django-hosts but it 
>>> looks as if it can be used  for only predefined list of subdomains. Please 
>>> help clarify this doubt.
>>>
>>> Thank you for your time
>>>
>>> On Thursday, December 30, 2021 at 1:10:17 AM UTC+1 Tim Chase wrote:
>>>
 On 2021-12-29 15:02, Sherif Adigun wrote: 
 > I am faced with a requirement where each user is required to use 
 > the application under his own subdomain. Whenever a user registers, 
 > he gets username.domain.com and he can add staff, manage reports, 
 > etc under his subdomain. 
 > 
 > What is the best approach to you can suggest please? 

 Generally this requires 

 1) configuring your DNS to allow for wildcard domains so that 
 *.domain.com points at your web server, usually looking something like 

 *.example.com. 3600 IN A 198.51.100.17 

 2) setting up your HTTPS certificates. This could be 

 - involve an ACME-aware Django route (I'm not sure if such a beast 
 exists) 

 - configuring an ACME client like certbot to update your 
 DNS records so that Let's Encrypt can verify that you own the 
 domain and then grant your a wildcard cert 

 - use a different CA to obtain a wildcard cert 

 2b) if you used a more manual method, put the certs in the 
 appropriate place for your web-server to pick them up 

 3) configure your web-server front-end/proxy (usually nginx or 
 Apache, but there are others) to handle the wildcard domains and pass 
 them through to your Django app or WSGI server or what have you. Make 
 sure the domain information is passed through in the HTTP_HOST header 

 4) use django-subdomains[1] (or maybe django-hosts[2]) middleware to 
 extract the intended host-name from the HTTP_HOST header and possibly 
 make the route reversable so that .reverse() works 

 5) check your views so that they make use of the HTTP_HOST 
 information to filter for user-specific information 

 -tkc 


 [1] https://django-subdomains.readthedocs.io/en/latest/ 


 [2] https://github.com/jazzband/django-hosts 





 -- 
>>> 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/CTynQlthabY/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> django-users...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-users/6057efaf-5e10-498a-ad2a-40132425412dn%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7cef164d-0f9c-4ad9-9d2d-18bfcb2d404bn%40googlegroups.com.


Re: Not sure if I am doing django-paypal correctly

2021-12-30 Thread lone...@gmail.com
Hey man, beggars cannot be choosers!  Thank you!

On Thursday, December 30, 2021 at 1:28:12 AM UTC-5 Yorben Verhoest wrote:

> Hello
>
> I'm a Django Noobie and maybe I'm completely wrong about this but in my 
> app named "core", I have a file called apps.py where I register my signals.
> I just followed a tutorial as well so I can't yet explain what it does but 
> if I had to guess is just to register the app with my signals.
>
> Just when reading your question it reminded me of this:
> [image: appconfig.png]
>
> If this is wrong info I'll delete this but maybe this helps :)
>
> Regards
>
> On Wednesday, 29 December 2021 at 21:22:46 UTC+1 lone...@gmail.com wrote:
>
>> Hello all,
>>
>>   I decided to try and accept payments on my web application.  I have 
>> chosen the django-paypal application to help me out with this task.  I 
>> found a decent walkthrough at: 
>> how-to-accept-paypal-payments-on-your-django-application 
>> .
>>   
>> I was able to follow everything until the last step of: "6. Setup a 
>> listener to detect successful Paypal payments"  I have never really setup 
>> any listeners before so I did not know what to do.  I decided to read the 
>> Django-PayPal 
>> ReadTheDocs 
>>  and I 
>> found a file that looked structurally similar to what I found on the 
>> original walkthrough I had found.  It looks like I needed to make a 
>> hooks.py file in my project directory.  I have accomplished that, and the 
>> ReadTheDocs says: "Remember to ensure that import the hooks file is 
>> imported i.e. that you are connecting the signals when your project 
>> initializes. The standard way to do this is to create an AppConfig class 
>> 
>>  and 
>> add a ready() 
>> 
>>  method, 
>> in which you can register your signal handlers or import a module that does 
>> this."  This is where I am getting lost.  I am not quite sure what to 
>> do.  Does anyone have a better walkthrough or know what I need to do?
>>
>> Thank you.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/db143e07-597c-489a-ace7-9bb5847ef69an%40googlegroups.com.


Re: Automatic subdomain for each user

2021-12-30 Thread Sherif Adigun
Thank you for your detailed response. Following your response point by
point with few additional googling, it works as expected.

On cpanel:
I created a subdomain called *
Then I chose document root as the main Django root. (This is needed so that
letsencrypt can automatically create a certificate.)

Then the routing works seemlessly

Thank you

On Thu, Dec 30, 2021, 7:06 PM Sherif Adigun  wrote:

> Thank you very much for you guidance. I have been able to make it work
> using Django-hosts on my local. Still trying to fix it out to work on my
> shared hosting if possible
>
> On Thu, Dec 30, 2021, 10:29 AM Sherif Adigun 
> wrote:
>
>> Thank you @Tim.  Django subdomains looks promising but it's outdated. It
>> uses codes and imports of django< v2  I have checked django-hosts but it
>> looks as if it can be used  for only predefined list of subdomains. Please
>> help clarify this doubt.
>>
>> Thank you for your time
>>
>> On Thursday, December 30, 2021 at 1:10:17 AM UTC+1 Tim Chase wrote:
>>
>>> On 2021-12-29 15:02, Sherif Adigun wrote:
>>> > I am faced with a requirement where each user is required to use
>>> > the application under his own subdomain. Whenever a user registers,
>>> > he gets username.domain.com and he can add staff, manage reports,
>>> > etc under his subdomain.
>>> >
>>> > What is the best approach to you can suggest please?
>>>
>>> Generally this requires
>>>
>>> 1) configuring your DNS to allow for wildcard domains so that
>>> *.domain.com points at your web server, usually looking something like
>>>
>>> *.example.com. 3600 IN A 198.51.100.17
>>>
>>> 2) setting up your HTTPS certificates. This could be
>>>
>>> - involve an ACME-aware Django route (I'm not sure if such a beast
>>> exists)
>>>
>>> - configuring an ACME client like certbot to update your
>>> DNS records so that Let's Encrypt can verify that you own the
>>> domain and then grant your a wildcard cert
>>>
>>> - use a different CA to obtain a wildcard cert
>>>
>>> 2b) if you used a more manual method, put the certs in the
>>> appropriate place for your web-server to pick them up
>>>
>>> 3) configure your web-server front-end/proxy (usually nginx or
>>> Apache, but there are others) to handle the wildcard domains and pass
>>> them through to your Django app or WSGI server or what have you. Make
>>> sure the domain information is passed through in the HTTP_HOST header
>>>
>>> 4) use django-subdomains[1] (or maybe django-hosts[2]) middleware to
>>> extract the intended host-name from the HTTP_HOST header and possibly
>>> make the route reversable so that .reverse() works
>>>
>>> 5) check your views so that they make use of the HTTP_HOST
>>> information to filter for user-specific information
>>>
>>> -tkc
>>>
>>>
>>> [1] https://django-subdomains.readthedocs.io/en/latest/
>>>
>>>
>>> [2] https://github.com/jazzband/django-hosts
>>>
>>>
>>>
>>>
>>>
>>> --
>> 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/CTynQlthabY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> django-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/6057efaf-5e10-498a-ad2a-40132425412dn%40googlegroups.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACP0aXhauGv-q4o_UERihQgAH3Ga6wn_MSYXqm8O4SmMfabTqQ%40mail.gmail.com.


Re: Automatic subdomain for each user

2021-12-30 Thread Sherif Adigun
Thank you very much for you guidance. I have been able to make it work
using Django-hosts on my local. Still trying to fix it out to work on my
shared hosting if possible

On Thu, Dec 30, 2021, 10:29 AM Sherif Adigun  wrote:

> Thank you @Tim.  Django subdomains looks promising but it's outdated. It
> uses codes and imports of django< v2  I have checked django-hosts but it
> looks as if it can be used  for only predefined list of subdomains. Please
> help clarify this doubt.
>
> Thank you for your time
>
> On Thursday, December 30, 2021 at 1:10:17 AM UTC+1 Tim Chase wrote:
>
>> On 2021-12-29 15:02, Sherif Adigun wrote:
>> > I am faced with a requirement where each user is required to use
>> > the application under his own subdomain. Whenever a user registers,
>> > he gets username.domain.com and he can add staff, manage reports,
>> > etc under his subdomain.
>> >
>> > What is the best approach to you can suggest please?
>>
>> Generally this requires
>>
>> 1) configuring your DNS to allow for wildcard domains so that
>> *.domain.com points at your web server, usually looking something like
>>
>> *.example.com. 3600 IN A 198.51.100.17
>>
>> 2) setting up your HTTPS certificates. This could be
>>
>> - involve an ACME-aware Django route (I'm not sure if such a beast
>> exists)
>>
>> - configuring an ACME client like certbot to update your
>> DNS records so that Let's Encrypt can verify that you own the
>> domain and then grant your a wildcard cert
>>
>> - use a different CA to obtain a wildcard cert
>>
>> 2b) if you used a more manual method, put the certs in the
>> appropriate place for your web-server to pick them up
>>
>> 3) configure your web-server front-end/proxy (usually nginx or
>> Apache, but there are others) to handle the wildcard domains and pass
>> them through to your Django app or WSGI server or what have you. Make
>> sure the domain information is passed through in the HTTP_HOST header
>>
>> 4) use django-subdomains[1] (or maybe django-hosts[2]) middleware to
>> extract the intended host-name from the HTTP_HOST header and possibly
>> make the route reversable so that .reverse() works
>>
>> 5) check your views so that they make use of the HTTP_HOST
>> information to filter for user-specific information
>>
>> -tkc
>>
>>
>> [1] https://django-subdomains.readthedocs.io/en/latest/
>>
>>
>> [2] https://github.com/jazzband/django-hosts
>>
>>
>>
>>
>>
>> --
> 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/CTynQlthabY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/6057efaf-5e10-498a-ad2a-40132425412dn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACP0aXjm8Kpdtvef6Aztvp6FmrKLCA7okgFbLFyYUAZ8xrf%3DTw%40mail.gmail.com.


Re: dotenv - django-environ - etc

2021-12-30 Thread Nagaraju Singothu
Hii All,
I want freelancing projects works



On Wed, 29 Dec 2021, 1:29 am bnmng,  wrote:

> Hi everyone,
>
> I can't wrap my mind around why having my settings in a .env file is more
> secure than having them in a local_settings.py file, or why one of the
> various methods is better than another as long as you keep your local
> settings out of your version control.  Any opinions?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/2bd1faca-5e79-48cf-950e-81e5c4b6929fn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAMyGuAaYxECJsjCPYAfb45h3_mAS3uswyyrTzAs13rEGQFC6qQ%40mail.gmail.com.


Re: dotenv - django-environ - etc

2021-12-30 Thread bnmng
Thank you for the replies.  I think I'm getting a better understanding of 
this.  I had been keeping the .env file in the project folder with the 
settings file, which seemed to offer no extra security  - hardly worth only 
being able to store settings as strings (using django-environ).  I'll take 
another look at the options and I'll move .env out of the project

On Tuesday, December 28, 2021 at 7:39:43 PM UTC-5 ber...@autofyle.com wrote:

> In all cases below, the .env file will exist outside of the Django project 
> and will be referenced from the settings file. This allows you to customize 
> and secure each environment while automating the whole build.
>
> *Developers*
> Local settings will point tot he location of the .env file. 
> This file is excluded from git via gitignore.
> Developers push to your repo's development branch which updates your 
> development server after passing CI/CD
>
>1. Developer 1 - /developer1Machine/whatever/unique path/.env
>2. Developer 2 - /unique path/.env/unique path/.env
>
> *Development environment*
> Developer settings references its own or same .env file path location 
> This directory and .env file permissions are secured such that only the 
> process running the web server has access to it and admin. So you may be 
> bale to log on to the server but won't be able to see this file and or 
> directory if you are not allowed to or in the right security group based on 
> your role.
>
>
> *Staging environment*
> Can be configured like development with staging desired tweaks.
> Testing and QA happens here prior to push to production
>
>
> *Production environment*
> Can be configured like staging.
> On Tuesday, December 28, 2021 at 3:41:25 PM UTC-7 Jason wrote:
>
>> an env file is basically imported into your OS environment, so you can 
>> retrieve them with the same interface.  That means you can easily include 
>> that with your build environment, or inject in some other means.  Can't do 
>> that with settings.
>>
>> Also, lets you keep one settings file, and use `os.environ.get()` 
>> anywhere you need to, which provides an identical interface.
>>
>> On Tuesday, December 28, 2021 at 2:58:28 PM UTC-5 bnmng wrote:
>>
>>> Hi everyone,
>>>
>>> I can't wrap my mind around why having my settings in a .env file is 
>>> more secure than having them in a local_settings.py file, or why one of the 
>>> various methods is better than another as long as you keep your local 
>>> settings out of your version control.  Any opinions?
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7e0271ad-be6b-4036-8edf-b837b842eb43n%40googlegroups.com.


Re: Automatic subdomain for each user

2021-12-30 Thread Sherif Adigun
Thank you @Tim.  Django subdomains looks promising but it's outdated. It 
uses codes and imports of django< v2  I have checked django-hosts but it 
looks as if it can be used  for only predefined list of subdomains. Please 
help clarify this doubt.

Thank you for your time

On Thursday, December 30, 2021 at 1:10:17 AM UTC+1 Tim Chase wrote:

> On 2021-12-29 15:02, Sherif Adigun wrote:
> > I am faced with a requirement where each user is required to use
> > the application under his own subdomain. Whenever a user registers,
> > he gets username.domain.com and he can add staff, manage reports,
> > etc under his subdomain.
> > 
> > What is the best approach to you can suggest please? 
>
> Generally this requires
>
> 1) configuring your DNS to allow for wildcard domains so that
> *.domain.com points at your web server, usually looking something like
>
> *.example.com. 3600 IN A 198.51.100.17
>
> 2) setting up your HTTPS certificates. This could be
>
> - involve an ACME-aware Django route (I'm not sure if such a beast
> exists)
>
> - configuring an ACME client like certbot to update your
> DNS records so that Let's Encrypt can verify that you own the
> domain and then grant your a wildcard cert
>
> - use a different CA to obtain a wildcard cert
>
> 2b) if you used a more manual method, put the certs in the
> appropriate place for your web-server to pick them up
>
> 3) configure your web-server front-end/proxy (usually nginx or
> Apache, but there are others) to handle the wildcard domains and pass
> them through to your Django app or WSGI server or what have you. Make
> sure the domain information is passed through in the HTTP_HOST header
>
> 4) use django-subdomains[1] (or maybe django-hosts[2]) middleware to
> extract the intended host-name from the HTTP_HOST header and possibly
> make the route reversable so that .reverse() works
>
> 5) check your views so that they make use of the HTTP_HOST
> information to filter for user-specific information
>
> -tkc
>
>
> [1] https://django-subdomains.readthedocs.io/en/latest/
>
>
> [2] https://github.com/jazzband/django-hosts
>
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6057efaf-5e10-498a-ad2a-40132425412dn%40googlegroups.com.