Skip to main content

datasette-auth-github

PyPI Changelog Tests License

Datasette plugin that authenticates users against GitHub.

Setup instructions

  • Install the plugin: datasette install datasette-auth-github
  • Create a GitHub OAuth app: https://github.com/settings/applications/new
  • Set the Authorization callback URL to http://127.0.0.1:8001/-/github-auth-callback
  • Create a metadata.json file with the following structure:
{
    "title": "datasette-auth-github demo",
    "plugins": {
        "datasette-auth-github": {
            "client_id": {"$env": "GITHUB_CLIENT_ID"},
            "client_secret": {"$env": "GITHUB_CLIENT_SECRET"}
        }
    }
}

For a GitHub Enterprise server, add "host": "github.example.com" to datasette-auth-github.

Now you can start Datasette like this, passing in the secrets as environment variables:

$ GITHUB_CLIENT_ID=XXX GITHUB_CLIENT_SECRET=YYY datasette \
    fixtures.db -m metadata.json

Note that hard-coding secrets in metadata.json is a bad idea as they will be visible to anyone who can navigate to /-/metadata. Instead, we use Datasette's mechanism for adding secret plugin configuration options.

By default anonymous users will still be able to interact with Datasette. If you wish all users to have to sign in with a GitHub account first, add this to your metadata.json:

{
    "allow": {
        "id": "*"
    },
    "plugins": {
        "datasette-auth-github": {
            "...": "..."
        }
    }
}

The authenticated actor

Visit /-/actor when signed in to see the shape of the authenticated actor. It should look something like this:

{
    "actor": {
        "id": "github:9599",
        "display": "simonw",
        "gh_id": "9599",
        "gh_name": "Simon Willison",
        "gh_login": "simonw",
        "gh_email": "...",
        "gh_orgs": [
            "dogsheep",
            "datasette-project"
        ],
        "gh_teams": [
            "dogsheep/test"
        ]
    }
}

The gh_orgs and gh_teams properties will only be present if you used load_teams or load_orgs, documented below.

Restricting access to specific users

You can use Datasette's permissions mechanism to specify which user or users are allowed to access your instance. Here's how to restrict access to just GitHub user simonw:

{
    "allow": {
        "gh_login": "simonw"
    },
    "plugins": {
        "datasette-auth-github": {
            "...": "..."
        }
    }
}

This "allow" block can be positioned at the database, table or query level instead: see Configuring permissions in metadata.json for details.

Note that GitHub allows users to change their username, and it is possible for other people to claim old usernames. If you are concerned that your users may change their usernames you can key the allow blocks against GitHub user IDs instead, which do not change:

{
    "allow": {
        "id": "github:9599"
    }
}

Restricting access to specific GitHub organizations or teams

You can also restrict access to users who are members of a specific GitHub organization.

You'll need to configure the plugin to check if the user is a member of that organization when they first sign in. You can do that using the "load_orgs" plugin configuration option.

Then you can use "allow": {"gh_orgs": [...]} to specify which organizations are allowed access.

{
    "plugins": {
        "datasette-auth-github": {
            "...": "...",
            "load_orgs": ["your-organization"]
        }
    },
    "allow": {
        "gh_orgs": "your-organization"
    }
}

If your organization is arranged into teams you can restrict access to a specific team like this:

{
    "plugins": {
        "datasette-auth-github": {
            "...": "...",
            "load_teams": [
                "your-organization/staff",
                "your-organization/engineering",
            ]
        }
    },
    "allows": {
        "gh_team": "your-organization/engineering"
    }
}

What to do if a user is removed from an organization or team

A user's organization and team memberships are checked once, when they first sign in. Those teams and organizations are then persisted in the user's signed ds_actor cookie.

This means that if a user is removed from an organization or team but still has a Datasette cookie, they will still be able to access that Datasette instance.

You can remedy this by rotating the DATASETTE_SECRET environment variable any time you make changes to your GitHub organization members.

Changing this value will cause all of your existing users to be signed out, by invalidating their cookies. When they sign back in again their new memberships will be recorded in a new cookie.

See Configuring the secret in the Datasette documentation for more details.

Release files for datasette-auth-github 0.14

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for datasette-auth-github 0.14
File Size Uploaded
datasette_auth_github-0.14.tar.gz 11.8 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for datasette-auth-github 0.14
File Interpreter ABI Platform
datasette_auth_github-0.14-py3-none-any.whl Python 3 none any Details

Total release size:22.6 kB

Release files / datasette_auth_github-0.14.tar.gz

Download URL datasette_auth_github-0.14.tar.gz
Size 11.8 kB
Tags Source
SHA-256 checksum
How to use checksums
88f5de74db49798092c1bb998974089d9ed0fb4153d19f78396a3323a37bce36
BLAKE2b-256 checksum
How to use checksums
7ac8054677d30b9bf39e8473d6e33142b414af593b0204cf76a9e5afa315897f
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.7

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Nov 16, 2025.

Transparency log

Release files / datasette_auth_github-0.14-py3-none-any.whl

Download URL datasette_auth_github-0.14-py3-none-any.whl
Size 10.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
c639cc6f6b1c7d3e76a156c4283276f37c5482b66830209632e1dabc70473969
BLAKE2b-256 checksum
How to use checksums
2108de491378be044f3f76f58e279437c3abd01fd9ba12a4a18684ad6fbb5f72
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.7

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Nov 16, 2025.

Transparency log

Release history Release notifications | RSS feed

This release

0.14 This release

2 release files

0.13.1

2 release files

0.13

2 release files

0.12

1 release file

0.11.1

1 release file

0.11

1 release file

0.10

1 release file

0.9.1

1 release file

0.9

1 release file

0.8

1 release file

0.7

1 release file

0.6.3

1 release file

0.6.2

1 release file

0.6.1

1 release file

0.6

1 release file

0.5

1 release file

0.4

1 release file

0.3.2

1 release file

0.3.1

1 release file

0.3

1 release file

0.2

1 release file

0.1.1

1 release file

0.1

1 release file

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page