Noob question, getting "No tenant for hostname '127.0.0.1'"

[j2l]

Fantastic and easy extension, thank you!

Using Ubuntu 22.04 and a docker postgres DB fresh install, I followed the doc, setup a dynamic client1 (and clients.../client./), and successfully access it.
But how to access public schema admin interface since URLCONF is forbidden for public?

Here are my tenants:

TENANTS = {
    "public": {
        "APPS": [
            "django.contrib.contenttypes",
            "django.contrib.staticfiles",
            "django_pgschemas",
            "app",
        ],
    },
    "default": {
        "TENANT_MODEL": "app.Client",
        "DOMAIN_MODEL": "app.Domain",
        "APPS": [
            'django.contrib.admin',
            "django.contrib.auth",
            "django.contrib.sessions",
            'django.contrib.messages',
            "backend",
        ],
        "URLCONF": "backend.urls",
    },
    "www": {
        "APPS": [
            "django.contrib.auth",
            "django.contrib.sessions",
            "backend"
        ],
        "DOMAINS": ["mydomain.com", "www.mydomain.com"],
        "URLCONF": "backend.urls",
    },

backend is the project, app is a test app.
*.mydomain.com resolves to 127.0.0.1 via etc/hosts

Checking into the db, I can see that schema client1 and www are present.

Ultimately, I'd like to create a form to offer to users of the main app the ability to create their own schema and log into it, but I don't get how. Any idea?

Thank you again :)

[lorinkoz]

Are you using mydomain.com or 127.0.0.1 as URL?

[lorinkoz]

What you're getting is expected. This package works by mapping a "domain url" into a tenant. IP address is technically not enough, because multiple tenants can (should) resolve to the same IP address. You should work with domains, not IP addresses.

[j2l]

OK, I understand, let's forget about IP. localhost domain (public):

or clients.mydomain.com (dynamic in default):

And if I add a DOMAINS to public, I get error django.core.exceptions.ImproperlyConfigured: TENANTS['public'] cannot contain a 'DOMAINS' key.
How to access public admin then?

[lorinkoz]

When you added the admin, what domain did you have in the URL? One corresponding to www?

[j2l]

I don't remember, used 127.0.0.1 I guess (I meant I added the user before installing django-pgschema).
www tenant auth is empty for now:

Ultimately, I'd like to create a form to offer to users of the main app the ability to create their own schema and log into it, but I don't get how a user could register (tenant or host) and get its tenant created in a SaaS way. Hope it makes more sense, thank you for your patience. 😺
Any idea?

[lorinkoz]

There is no public admin. I assume what you refer to as public admin is your "www" static tenant.

[lorinkoz]

I assume you want a setup like this:

www.mydomain.com or mydomain.com -> points to the enterprise site where you can sign up for a tenant

clients.mydomain.dom//path/to/somewhere - > points to the space of each tenant

If that's the case, the your admin site needs to operate also on two different levels. Any users you create in www will only be available in www. Any users you create in a specific tenant will only be available on that tenant. It will all depend on which tenant you're in based on the domain you're using to access the page.

[j2l]

Thank you again.

www.mydomain.com or mydomain.com -> points to the enterprise site where you can sign
up for a tenant
clients.mydomain.dom//path/to/somewhere - > points to the space of each tenant

yes!

AFAIU, shared_app (app in my case, managing Clients and Domains) is needed in public, if I add admin.py to manage it in www, it is also visible in dynamic clients admin.
Does a form in www could manage the shared_app?

[lorinkoz]

Were you able to solve this?

[j2l]

I'll reply ASAP when the test server is running. Thank you

[j2l]

Thank you for your patience and your willingness to help a noob like me.
Checked my code and notes, it was a mess ... I needed this holiday 😄
So I redo everything from scratch and it makes more sense now.

Here are my (fixed) tenants:

TENANTS = {
    "public": {
        "APPS": [
            "django.contrib.contenttypes",
            "django.contrib.staticfiles",
            "django_pgschemas",
            "shared_app",
        ],
    },
    "default": {
        "TENANT_MODEL": "shared_app.Client",
        "DOMAIN_MODEL": "shared_app.Domain",
        "APPS": [
            "django.contrib.auth",
            "django.contrib.sessions",
            'django.contrib.messages',
            "tenant_app",
        ],
        "URLCONF": "tenant_app.urls",
    },
    "www": {
        "APPS": [
            'django.contrib.admin',
            "django.contrib.auth",
            "django.contrib.sessions",
        ],
        "DOMAINS": ["mydomain.com", "www.mydomain.com"],
        "URLCONF": "main_app.urls",
    },
}

Top 1 issue :
A view and form to CRUD a client from www.mydomain.com, that also CRUD the superuser of the client in its schema.

[lorinkoz]

Ah, that's a tricky™ one. The problem with the schemas approach is that you cannot peek inside other schemas. When you are in www your search path is ["www", "public"]. You can view everything on those schemas, but nothing outside.

If we were to talk theory a bit you could in theory set the search path to ["www","client1","public"] but that's also not gonna work because the users table is both in www and client1 and then you would only see the first in the list (that is www). But in general, this package does not support such schema "jumping" and there is no feasible way to do implement it.

Back to the original problem. If you are superadmin (that is, a user whose level is above all clients) and you want to peek inside a client, then the superadmin user must be present in the client's user table.

If this is the constraint you have, I'd recommend using a different approach for users. In the new documentation I am preparing for v1 (https://django-pgschemas.readthedocs.io/en/latest/overview/#users-and-tenants) I briefly touch on this topic of users vs tenants. If you need a configuration where the exact same user can access more than one tenant (aka client) then you need to do this:

Your user table (and session table as well) needs to live in the public schema. For this you need to move the user and session app to the public section of the TENANTS config. With this, every tenant can see every user. The challenge of this approach is that you then need to control which users have access to which tenants. That is, because they are not inside a schema, you have to control it yourself with other tables (e.g. UserToTenant).

[lorinkoz]

But then again, you will never be able to look into client1 while being inside www. If a superadmin needs to look into client1 the must go to the hypothetical admin page of client1 (client1.mydomain.com/admin) login as superadmin (which should be granted permission to do so from your internally defined permission system) and do whatever you need to do on that schema.

[j2l]

Thank you very much for all these explanations. I'll see what I can do.