Django==1.11.7
django-tenant-schemas==1.8.0
django-allauth==0.34.0
Multi tenant site using django-tenant-schemas (postgres).
On different tenants, different settings are required.
More specifically, different setting is required for ACCOUNT_EMAIL_VERIFICATION
1 tenant needs ACCOUNT_EMAIL_VERIFICATION = "optional" while another one needs ACCOUNT_EMAIL_VERIFICATION ="mandatory"
Looking in the source code, the setting looks not customisable, it is fixed for the whole django site.
-> How can this be done?
You can compute the settings at runtime, since it's simply a python code.
Set that specific code programmatically, using your preferred way. One example:
# predefine the settings per tenant
ACCOUNT_EMAIL_VERIFICATION_PER_TENANT = {
"tenant_x": "mandatory",
"tenant_y": "optional",
}
# implement get_tenant
def get_tenant():
# here be tenant logic
pass
this_tenant = get_tenant()
ACCOUNT_EMAIL_VERIFICATION = ACCOUNT_EMAIL_VERIFICATION_PER_TENANT[get_tenant()]
Or you can have multiple settings files and join them as you wish. Here's how django does.
Oh and if you want to separate the logic from the settings file and have it run before evaluating the settings perhaps, you can inspect what is the trail of execution when you launch your server (e.g. starting from manage.py and insert your get_tenant logic somewhere in between). Most probably it will be somewhere starting from the wsgi.py file - where the application instance gets created and all the django fun begins.
When it comes to programming, you are always in control.
Solved in following way:
In settings.py:
try:
ACCOUNT_EMAIL_VERIFICATION = os.environ['ACCOUNT_EMAIL_VERIFICATION_OVERRIDE']
except KeyError:
ACCOUNT_EMAIL_VERIFICATION = 'mandatory'
In wsgi.py file of the tenant where e-mail verification is optional:
os.environ['ACCOUNT_EMAIL_VERIFICATION_OVERRIDE'] = 'optional'
wsgi files for the other tenants remain unchanged.
Gave the bounty to Adelin as he suggested to look into the wsgi file.
I stumbled upon this situation, and my dynamic solution is a middleware as follows without any hardcoding tenant's names
from django.conf import settings
from django.db import connection
from django_tenants.utils import get_public_schema_name, get_tenant_model
class TenantSettingsMiddleWare:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
self.request = request
self.overload_settings()
response = self.get_response(request)
return response
def overload_settings(self):
current_schema_obj = get_tenant_model().objects.get(schema_name=connection.schema_name)
settings.DEFAULT_FROM_EMAIL = 'admin#{}'.format(current_schema_obj.domains.last())
Cheers 🍻🍻🍻
Related
I have a cart where I have two fields that I use to connect to a user. One is User, I use that if user is logged in. Other is session, this is used to keep track of logged out users. It uses session_key.
Now the problem I am facing is that when a user logs in the cart disconnects because the session_key has changed. I know that I can use cookie to identify the browser or client. But I am not able to find an example of Django's set_cookies being used with JsonResponse(AJAX call). It is only for HttpResponse.
I think I could use either of these two ways, if possible.
Set cookie through AJAX
Or Set cookie when user visits website. I want this with ability that no matter which page the user visits at fist the cookie should be set on that visit.
Does anyone have a resource or example to achieve this?
Thank you
Answering my own question in case this might help someone.
I went with the point# 2 mentioned in my question. What I needed was Middleware. They allow us to inject data in request and response objects for our views.
In myproject/cart/middleware.py I have this:
from . import settings as cart_settings
import uuid
class SetCartSessionKeyMiddleware(object):
def __init__(self, get_response):
self.get_response = get_response
# One-time configuration and initialization.
def __call__(self, request):
cart_key = request.COOKIES.get(cart_settings.CART_SESSION_ID_KEY, None)
if cart_key:
response = self.get_response(request)
else:
cart_id = str(uuid.uuid4())
response = self.get_response(request)
response.set_cookie(cart_settings.CART_SESSION_ID_KEY, cart_id)
return response
In my settings.py I have:
CART_SESSION_ID_KEY = 'user_cart_id'
Now you can access that cookie anywhere where you have access to request object like in your views. You can do session_id = request.COOKIES.get(cart_settings.CART_SESSION_ID_KEY, None)
Don't forget to import settings in views as you did in the middleware.py file. Remember that it is my app settings.py(ie. myproject/cart/settings.py) not the main project settings.py.
In your myproject/settings.py register your new middleware like this
MIDDLEWARE = [
'django.middleware.gzip.GZipMiddleware',
....
## Our custom middlewares
'cart.middleware.SetCartSessionKeyMiddleware',
]
Enjoy!
I noticed looking through the django-allauth templates there's a signup_closed.html users can be redirected to when user registration is closed or disabled. Does anyone who's familiar with that module know if there's a pre-configured setting that can be set in settings.py to turn off new user registration via existing social apps? Or do I need to configure that myself? I've read the full docs for allauth and I don't see any mention of it. Thanks.
Looks like you need to override is_open_for_signup on your adapter.
See the code.
There is no pre-configured setting but it's easy to make one (this is what I do).
# settings.py
# Point to custom account adapter.
ACCOUNT_ADAPTER = 'myproject.myapp.adapter.CustomAccountAdapter'
# A custom variable we created to tell the CustomAccountAdapter whether to
# allow signups.
ACCOUNT_ALLOW_SIGNUPS = False
# myapp/adapter.py
from django.conf import settings
from allauth.account.adapter import DefaultAccountAdapter
class CustomAccountAdapter(DefaultAccountAdapter):
def is_open_for_signup(self, request):
"""
Whether to allow sign ups.
"""
allow_signups = super(
CustomAccountAdapter, self).is_open_for_signup(request)
# Override with setting, otherwise default to super.
return getattr(settings, 'ACCOUNT_ALLOW_SIGNUPS', allow_signups)
This is flexible, especially if you have multiple environments (e.g. staging) and want to allow user registration in staging before setting it live in production.
More information at http://django-allauth.readthedocs.io/en/latest/advanced.html#custom-redirects.
You need to subclass allauth.account.adapter.DefaultAccountAdapter to override is_open_for_signup, and then set ACCOUNT_ADAPTER to your class in settings.py
I wrote a signal in my django project, inside I want to send an email with the full path of my website. But to do so, I need to get the request object inside the signal, how could I do that? Thanks.
#receiver(pre_save, sender=AccessRequest)
def email_if_access_true(sender, instance, **kwargs):
#How can I get the full path of my website here?
pass
If you don’t have access to the request object, you can use the get_current() method of the Site model’s manager.
from django.contrib.sites.models import Site
#receiver(pre_save, sender=AccessRequest)
def email_if_access_true(sender, instance, **kwargs):
current_site = Site.objects.get_current()
if current_site.domain == 'foo.com':
#do other stuff here
else:
pass
you need to ensure that you defined SITE_ID=1 in your settings
If you don’t have access to the request object, you can use the get_current() method of the Site model’s manager.
from django.contrib.sites.models import Site
#receiver(pre_save, sender=MyModel)
def my_function_without_request(sender, instance, **kwargs):
current_site = Site.objects.get_current()
domain = current_site.domain
# Do something
To enable the sites framework, follow these steps:
Add 'django.contrib.sites' to your INSTALLED_APPS setting.
Define a SITE_ID setting: SITE_ID = 1
Run migrate.
Source: https://docs.djangoproject.com/en/3.2/ref/contrib/sites/
To set the correct name and domain for your project, you can use a data migration.
To start, make an empty migration file you can work from (Django will put the file in the right place, suggest a name, and add dependencies for you):
python manage.py makemigrations --empty yourappname
Then, open up the file and create a new function and have RunPython use it.
from django.contrib.sites.models import Site
from django.db import migrations
def set_name_and_domain():
one = Site.objects.all()[0]
one.domain = 'yourdomain.com'
one.name = 'Your Name'
one.save()
class Migration(migrations.Migration):
dependencies = [
('yourappname', '0001_initial'),
]
operations = [
migrations.RunPython(set_name_and_domain),
]
All of this will save your domain and site name in your database where you can access it without having the request object. So far I have not found a better way to do this.
Source: https://docs.djangoproject.com/en/3.2/topics/migrations/#data-migrations
Put following code in your pre_save signal receiver:
from django.contrib.sites.models import get_current_site
current_site = get_current_site(request=None)
domain = current_site.domain
protocol = "http"
You can generate absolute url to your website in email by passing required context variables to template. If access_request is instance in your case and there is one get_abosulte_url() method in your AccessRequest model, then following line in email template will give you absolute url.
{{ protocol }}://{{ domain }}{% access_request.get_absolute_url %}
Reference - PasswordResetForm in django.contrib.auth.form.
I have a number of sites under one Django application that I would like to implement site wide caching on. However it is proving to be a real hassle.
what happens is that settings.CACHE_MIDDLEWARE_KEY_PREFIX is set once on startup, and I cannot go ahead and change it depending on what the current site is. As a result if a page of url http://website1.com/abc/ is cached then http://website2.com/abc/ renders the cached version of http://website1.com/abc/. Both these websites are running on the same Django instance as this is what Django Sites appears to allow us to do.
Is this an incorrect approach? Because I cannot dynamically set CACHE_MIDDLEWARE_KEY_PREFIX during runtime I am unable to cache multiple sites using Django's Site wide caching. I also am unable to do this for template and view caching.
I get the impression that the way this really needs to be setup is that each site needs its own Django instance which is pretty much identical except for the settings file, which in my case will differ only by the value of CACHE_MIDDLEWARE_KEY_PREFIX. These Django instances all read and write to the same database. This concerns me as it could create a number of new issues.
Am I going down the right track or am I mistaken about how multi site architecture needs to work? I have checked the Django docs and there is not real mention of how to handle caching (that isn't low level caching) for Django applications that serve multiple sites.
(Disclaimer: the following is purely speculation and has not been tested. Consume with a pinch of salt.)
It might be possible to use the vary_on_headers view decorator to include the 'Host' header in the cache key. That should result in cache keys that include the HTTP Host header, thus effectively isolating the caches for your sites.
#vary_on_headers('Host')
def my_view(request):
# ....
Of course, that will only work on a per-view basis, and having to add a decorator to all views can be a big hassle.
Digging into the source of #vary_on_headers reveals the use of patch_vary_headers() which one might be able to use in a middleware to apply the same behaviour on a site level. Something along the lines of:
from django.utils.cache import patch_vary_headers
class VaryByHostMiddleware(object):
def process_response(self, request, response):
patch_vary_headers(response, ('Host',))
return response
I faced this problem recently. What I did based on the documentation was to create a custom method to add the site id to the key used to cache the view.
In settings.py add the KEY_FUNCTION argument:
CACHES = {
'default': {
'BACKEND': 'path.to.backend',
'LOCATION': 'path.to.location',
'TIMEOUT': 60,
'KEY_FUNCTION': 'path.to.custom.make_key_per_site',
'OPTIONS': {
'MAX_ENTRIES': 1000
}
}
}
And my custom make_key method:
def make_key_per_site(key, key_prefix, version):
site_id = ''
try:
site = get_current_site() # Whatever you use to get your site's data
site_id = site['id']
except:
pass
return ':'.join([key_prefix, site_id, str(version), key])
You need to change get_full_path to build_absolute_uri in django.util.cache
def _generate_cache_header_key(key_prefix, request):
"""Returns a cache key for the header cache."""
#path = md5_constructor(iri_to_uri(request.get_full_path()))
path = md5_constructor(iri_to_uri(request.build_absolute_uri())) # patch using full path
cache_key = 'views.decorators.cache.cache_header.%s.%s' % (
key_prefix, path.hexdigest())
return _i18n_cache_key_suffix(request, cache_key)
def _generate_cache_key(request, method, headerlist, key_prefix):
"""Returns a cache key from the headers given in the header list."""
ctx = md5_constructor()
for header in headerlist:
value = request.META.get(header, None)
if value is not None:
ctx.update(value)
#path = md5_constructor(iri_to_uri(request.get_full_path()))
path = md5_constructor(iri_to_uri(request.build_absolute_uri()))
cache_key = 'views.decorators.cache.cache_page.%s.%s.%s.%s' % (
key_prefix, request.method, path.hexdigest(), ctx.hexdigest())
return _i18n_cache_key_suffix(request, cache_key)
Or create you own slightly changed cache middleware for multisite.
http://macrotoma.blogspot.com/2012/06/custom-multisite-caching-on-django.html
I have to assign to work on one Django project. I need to know about the URL say, http://....
Since with ‘urls.py’ we indeed have ‘raw’ information. How I come to know about the complete URL name; mean with
http+domain+parameters
Amit.
Look at this snippet :
http://djangosnippets.org/snippets/1197/
I modified it like this :
from django.contrib.sites.models import RequestSite
from django.contrib.sites.models import Site
def site_info(request):
site_info = {'protocol': request.is_secure() and 'https' or 'http'}
if Site._meta.installed:
site_info['domain'] = Site.objects.get_current().domain
site_info['name'] = Site.objects.get_current().name
else:
site_info['domain'] = RequestSite(request).domain
site_info['name'] = RequestSite(request).name
site_info['root'] = site_info['protocol'] + '://' + site_info['domain']
return {'site_info':site_info}
The if/else is because of different versions of Django Site API
This snippet is actually a context processor, so you have to paste it in a file called context_processors.py in your application, then add to your settings :
TEMPLATE_CONTEXT_PROCESSORS = DEFAULT_SETTINGS.TEMPLATE_CONTEXT_PROCESSORS + (
'name-of-your-app.context_processors.site_info',
)
The + is here to take care that we d'ont override the possible default context processor set up by django, now or in the future, we just add this one to the tuple.
Finally, make sure that you use RequestContext in your views when returning the response, and not just Context. This explained here in the docs.
It's just a matter of using :
def some_view(request):
# ...
return render_to_response('my_template.html',
my_data_dictionary,
context_instance=RequestContext(request))
HTTPS status would be handled differently by different web servers.
For my Nginx reverse proxy to Apache+WSGI setup, I explicitly set a header that apache (django) can check to see if the connection is secure.
This info would not be available in the URL but in your view request object.
django uses request.is_secure() to determine if the connection is secure. How it does so depends on the backend.
http://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpRequest.is_secure
For example, for mod_python, it's the following code:
def is_secure(self):
try:
return self._req.is_https()
except AttributeError:
# mod_python < 3.2.10 doesn't have req.is_https().
return self._req.subprocess_env.get('HTTPS', '').lower() in ('on', '1')
If you are using a proxy, you will probably find it useful that HTTP Headers are available in HttpRequest.META
http://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpRequest.META
Update: if you want to log every secure request, use the above example with a middleware
class LogHttpsMiddleware(object):
def process_request(self, request):
if request.is_secure():
protocol = 'https'
else:
protocol = 'http'
print "%s://www.mydomain.com%s" % (protocol, request.path)
Add LogHttpsMiddleware to your settings.py MIDDLEWARE_CLASSES