Ability to use QFieldCloud without explicitly asking users to register in advance

[suricactus]

I would also like to request this feature.

Sure in western developed countries everyone has an email address and creating an account on QFieldCloud isn't a barrier.

But this isn't the reality in many parts of the world. If QField cloud wants to be a serious option for mapping in developing countries (empowering people from the country, not consultants or INGOs), it needs either:

• The ability to use a single shared service account that can be pre-configured for users in advanced. This login is distributed amongst the team of local mappers during training, so they can get started with the mapping straight away (this issue).

• An option to access and edit projects without requiring a password at all: https://ideas.qfield.org/qfieldcloud-feature-requests/p/allow-editing-of-certain-projects-without-requiring-login-via-a-param-qrcode

@suricactus would you possibly reconsider this?

[!NOTE]
It seems you have to be part of the organisation for editing in QField anyway, currently making QField great for mapping within a single organisation with limited coordinated users, but not great for coordinated open mapping campaigns (gathering lots of community members together to map their own areas).

Originally posted by @spwoodcock in #1222

[suricactus]

@spwoodcock hey, thanks for the interest. I would introduce a third alternative here:

The ability for organization managers to prepare accounts for users in advance. So instead of asking the user to register to QFC and then inviting them to an organization/project, we reverse the process and allow the organization manager to create N members in advance, assign roles and permissions and then find a way to share those with the end users outside QFieldCloud.

This is currently possible, even though a bit cumbersome, as you have to use the Sign Up page several times, but the idea would be to have a dedicated page in organizations settings for that.

This can be further upgraded with a bulk creation - I want to create N users using this username pattern, all with this email address.

The only limitation with that approach is that the number of users to be added need to be known in advance. This can be furhter solved by exposing this functionality as an API, so a third-party "wrapper app" can create new users on demand.

[spwoodcock]

Love the idea! This could work nicely in many contexts 😄

For mapping campaigns that have a predefined scope and group of mappers - such as a funded mapping campaign organised by an NGO - the manager could configure the project so every user has the required permission, and distribute credentials.

There is another kind of mapping to consider though: open mapping campaigns with undefined number of users, that are open for community contribution. QField currently has the concept of 'public' projects, but this is read-only in scope. This specific Github issue would cover these use cases, such as contributing as a community to OpenStreetMap, where we want to allow any user to easily join the campaign and contribute (via an easy method such as QRCode scan).

The only two approaches to achieve this I could think of for now were (1) no login requirement (probably less feasible) (2) service account creation tied to a project, possibly linked to a QRCode that can be distributed (3) a single service account created for all projects (privacy concerns with this approach though).

[suricactus]

Those are other feature requests and we have them very close to the top of the backlog. Pretty much looking for funding.

1. Default project role for org members - so when someone joins an organization, they automatically have that role on all organization owned projects. Currently they see none of the projects.

2. Default project role for project collaborators - either inherit from the owner, or set any of the available roles. So when you add a new user to a project, that will be the default suggestion.

3. request joining an organization - instead admins adding new org members, the users can request joining organizations and the admins approve them with the default role.

4. Google SSO comes very soon on app.qfield.cloud.

I think 3 and 4 partly cover what you have described as user story. Once we have those in place, we can think for the "loginless" contribution again, but I have a pretty strong feeling these features will open some new doors which we cannot forsee as of now.

[spwoodcock]

Thanks @suricactus!

We could potentially provide funding and/or dev support for the 'loginless' approach, as it's quite a priority for our mappers - let's discuss further =)

But you are right, adding Google SSO would go quite a way to solving this - many users have a Google account already.

Equally, as mentioned in the original spec, many users have no email at all and are unable to 'sign up' to the platform before mapping - so we need a nice approach to cover that scenario.

[spwoodcock]

@spwoodcock hey, thanks for the interest. I would introduce a third alternative here:

The ability for organization managers to prepare accounts for users in advance. So instead of asking the user to register to QFC and then inviting them to an organization/project, we reverse the process and allow the organization manager to create N members in advance, assign roles and permissions and then find a way to share those with the end users outside QFieldCloud.

This is currently possible, even though a bit cumbersome, as you have to use the Sign Up page several times, but the idea would be to have a dedicated page in organizations settings for that.

This can be further upgraded with a bulk creation - I want to create N users using this username pattern, all with this email address.

The only limitation with that approach is that the number of users to be added need to be known in advance. This can be furhter solved by exposing this functionality as an API, so a third-party "wrapper app" can create new users on demand.

Creating uses in advance

I was mulling over this idea and I do quite like it.

The advantage is it sticks to the current auth models and doesn't introduce a new permission with public read.

The disadvantage is that it means the credential must be distributed to the user for login. But this isn't end the of the world.

Just to clarify, we would need to create users with a different username and password each time right? (essentially service accounts)

So:
project-xxx-user-xxx
project-xxx-user-xxx@fakeemail.com

Alternative: create users by sharing

• Currently the QRCode for sharing a project in QField has content qfield://cloud?project=33369d41-fde1-414b-b791-116dabeeeec7

• Perhaps we could have a new QRCode option to 'grant access to user'. This would:

  • POST to QFC to create a new user for the project, with editor permission (using the current user creds).
  • Return the credentials of the new user.
  • Generate a QRCode for the other user to scan with content qfield://cloud?project=33369d41-fde1-414b-b791-116dabeeeec7&username=xxx&password=xxx (alternatively have a single variable token that can be accepted instead).
  • QField on second phone opens by QRCode scan intent, logging in automatically and accessing the project (would require QField accepting those extra URL params for login).

• A side benefit of this approach is that we could generate QRCodes on QFC web ui too for direct project access in QField (project, plus credentials for login).

Note

A caveat is that all the users probably need elevated permissions for creating new users...

(btw I would happily help implement whatever idea you think is most feasible / in line with QFC goals)

[suricactus]

Creating uses in advance

Just to clarify, we would need to create users with a different username and password each time right? (essentially service accounts)

Correct. This is what I mean by:

• I want to create N users using this username pattern, all with this email address.

As for the email address, we have few options here: (best) use different email address; (ok) use the +@ pattern; (more work, less likely) share the same email for all of them.

The disadvantage is that it means the credential must be distributed to the user for login. But this isn't end the of the world.

Yup, I believe if we are in the conversation started with everyone sharing the same credentials, this would be the least problem. :)

---

Alternative: create users by sharing

This is something we have discussed initially just before the FOSS4G Mostar this year internally and we agreed that eventually develop it one day. Happy to see an independent party coming up to the same idea, it seems we are not that off from what the real world needs and wants. :)

The workflow you have described is pretty much my general understanding too.

---

Before we commit in one or another direction, we need to discuss this internally and probably come by clear solution by mid November. My personal opinion is that the first approach "create users in advance" is slightly less effort with similar or higher impact for now. But this does not mean that "create users by sharing" is in any way not interesting and both of them could not co-exist.

[t-book]

Great discussion! Just thinking out loud …

Building on @spwoodcock's loginless idea — a time-limited access window (e.g. 48h) paired with a simple local nickname prompt could be helpfull to keep trace who did what.

Or Device-Based Authorization?
Instead of tying access to an email, the device itself could act as the identity.

• Concept: QField generates a unique ID (UUID) for the phone, which an admin then authorizes once (perhaps via a quick QR scan).
• Pro: This might be a clean fit for NGOs lending out pre-configured tablets to local mappers where individual accounts are a hurdle.

A note on Auth: Regarding the Google SSO mention — in the GeoNode ecosystem, we've had good experiences relying on Keycloak as an identity broker. It unifies Social Logins (Google, GitHub, etc.) and LDAP for organizations under a single OIDC layer. This could be a natural fit alongside the planned Google SSO, covering both the enterprise use case (org-managed LDAP accounts) and a way to handle these diverse user types without having to build custom logic for every new provider.

[spwoodcock]

Device based identities is what ODK Collect does at least. Its not a bad idea, but doesn't work with the auth model of QField really (which is based on users).

For OIDC, I believe you can already add custom providers like Keycloak 😃

SOCIALACCOUNT_PROVIDERS = '{ "openid_connect": { "OAUTH_PKCE_ENABLED": true, "APP": { "provider_id": "keycloak", "name": "Keycloak", "client_id": "qfc-oidc", "settings": { "server_url": "http://keycloak:7080/realms/ninjas/.well-known/openid-configuration" } } } }'

[t-book]

@spwoodcock nice, thanks for the hint!

[spwoodcock]

@suricactus did you manage to discuss this internally as mentioned? 🙏

I'm looking into adding a user creation API soon - perhaps I can make a PR?

For now, for my local dev setup I am using a simple http service to modify the db users:

"""Minimal HTTP service for QFieldCloud user management.

Runs inside a container using the qfield-app image (same Django environment)
so it can use the ORM directly to create users.

Exposes a single endpoint:
    POST /create-user  { "username": "...", "password": "...", "email": "..." }
    --> 201  { "status": "created" }
    --> 200  { "status": "exists" }
    --> 400/500  { "error": "..." }
"""

import json
import logging
import os
from http.server import BaseHTTPRequestHandler, HTTPServer

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "qfieldcloud.settings")

import django  # noqa: E402

django.setup()

from qfieldcloud.core.models import Person  # noqa: E402

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s | %(levelname)-8s | %(name)s | %(message)s",
)
log = logging.getLogger(__name__)

PORT = 8081


class UserMgmtHandler(BaseHTTPRequestHandler):
    def log_message(self, format, *args):
        log.info("%s - %s", self.address_string(), format % args)

    def do_POST(self):
        if self.path != "/create-user":
            self._send_json(404, {"error": "not found"})
            return

        try:
            length = int(self.headers.get("Content-Length", 0))
            body = json.loads(self.rfile.read(length))
        except Exception:
            self._send_json(400, {"error": "invalid JSON body"})
            return

        username = (body.get("username") or "").strip()
        password = (body.get("password") or "").strip()
        email = (body.get("email") or f"{username}@noreply.local").strip()

        if not username or not password:
            self._send_json(400, {"error": "username and password are required"})
            return

        try:
            existing_user = Person.objects.filter(username=username).first()
            if existing_user:
                existing_user.email = email
                existing_user.has_accepted_tos = True
                existing_user.set_password(password)
                existing_user.save(
                    update_fields=["email", "has_accepted_tos", "password"]
                )
                log.info("Updated QFieldCloud user '%s'", username)
                self._send_json(200, {"status": "updated"})
                return

            Person.objects.create_user(
                username=username,
                email=email,
                password=password,
                has_accepted_tos=True,
            )
            log.info("Created QFieldCloud user '%s'", username)
            self._send_json(201, {"status": "created"})

        except Exception as exc:
            log.error("Error creating user '%s': %s", username, exc)
            self._send_json(500, {"error": str(exc)})

    def _send_json(self, code: int, payload: dict) -> None:
        body = json.dumps(payload).encode()
        self.send_response(code)
        self.send_header("Content-Type", "application/json")
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)


if __name__ == "__main__":
    server = HTTPServer(("0.0.0.0", PORT), UserMgmtHandler)
    log.info("QFieldCloud user management service listening on port %d", PORT)
    server.serve_forever()

[spwoodcock]

#1506 would go some way to addressing this