django-allauth is included and configured within dino, but there is no way for users to connect their dino account to a social account.

Deleting zones in dino works just fine, but the local database is never updated, leading to dormant entries in the DB and UI.

• when deleting a zone, delete the database entry as well
• when the database has a zone, but it's not present in the pdns API ask the user what to do
  • admins: "this zone vanished in pdns, want to delete?"
  • users: "this zone vanished in pdns. ask your admin for details."

Could not create new record. PowerDNS error: RRset www.asd.com. IN CNAME: Conflicts with pre-existing non-CNAME RRset

Depending on the old and new rtype, change the delete behavior. For example, create new SOA before deleting old one, delete old record before creating CNAME,...

• switch form to GET
• add redirect_url to delete forms
• add redirect_url to edit form

add a dino config for SECURE_PROXY_SSL_HEADER to fix full URLs generated by django. This fixes the redirect_uri given to google and others during social login.

• move apps not needed to the bottom
  • accounts
  • sites
  • social accounts
• boil remaining ones down to as few categories as possible
  • User Management
  • Tenants

  File "/var/dino/.local/lib/python3.6/site-packages/dino/settings.py", line 24, in <module>
    os.path.abspath('./dino.cfg'),
  File "/usr/lib64/python3.6/posixpath.py", line 376, in abspath
    cwd = os.getcwd()
FileNotFoundError: [Errno 2] No such file or directory

1. su -
2. cd ~root
3. sudo -u www-dino /bin/uwsgi --http :8081 --module dino.wsgi

When editing the SOA record created by PowerDNS we end up with two of them. This probably applies to all apex/root records, but I can't test that due to #24.

Our dockerfile currently installs the development dependencies and uses runserver. Neither is a good idea in production.

• define a production Dockerfile, without dev dependencies and with uwsgi/gunicorn
• try to derive the development Dockerfile from the prod one, installing only additional packages and changing the CMD to runserver
• adapt docker-compose.yml
• try to run it in the CI

Provide a drop-down to filter record list by type, in addition to free-from search.

SRV records start with an underscore, e.g. _matrix._tcp.example.org. This currently yields an input validation error.

currently only the google social provider in django-allauth is enabled. Add a setting to enable arbitrary other ones.

Currently only the first 20 search results are shown. Steal some code from b62ffb8.

The powerdns API only supports a single API key with full permissions and is thus not easy to use outside or even inside on organisation.

• per-user, per-tenant (and global?) API keys
• pagination
• read only zones and records
• write records
• write zones

Use django REST framework or come up with a good reason to use another scheme and use that.

Creating a zone or record with umlauts or other non-ascii characters currently yields an PowerDNS API error:

Could not create new record. PowerDNS error: Name '\195\182.asd.com.' contains unsupported characters

• punnycode zone names during creation
• punnycode record names during creation and editing

Signup is currently either disabled for everyone or enabled for everyone. Change this so it's disabled for everyone, but enabled for users from a list of domains (e.g. @company.com).

• add a DINO_VALID_SIGNUP_DOMAINS setting (type: list)
• add a documentation page about social signup, explaining security model behind this (we trust the social provider to only give us verified email addresses)
• check email address during signup in NoNewUsersAccountAdapter.clean_email
• give NoNewUsersAccountAdapter a new name ;)
• check that clean_email is actually called for social accounts (it's not.)
• implement a SocialAccountAdapter
• if DINO_VALID_SIGNUP_DOMAINS is set, ...
  • set SOCIALACCOUNT_EMAIL_VERIFICATION = False
  • set SOCIALACCOUNT_EMAIL_REQUIRED = True
  • set ACCOUNT_EMAIL_VERIFICATION = True
  • set ACCOUNT_EMAIL_REQUIRED = True
• add google config, if there is only one domain given (UX only, google doesn't enforce this):

SOCIALACCOUNT_PROVIDERS = {
    'google': {
        'AUTH_PARAMS': {
            'hd': DINO_VALID_SIGNUP_DOMAINS[0],
        }
    }
}

The django ADMINS config value allows determines where stacktraces get sent to. Add the env variable DINO_ADMINS to enable admins to set it.

if a tenant creates a zone, it is currently not associated with any tenant. This means that the tenant cannot edit the zone they just created.

Some users might have many look-alike zones. Introduce zone templates (a list of predefined records), allow basic templating within the values (e.g. zone name, current time), allow global and per-tenant templates. Optionally allow users to select a template creating a new zone.

Add a small button with an x. Clicking it clears all search inputs and shows the full list of records/zones.

Currently the search bar is case sensitive. This isn't that intuitive especially for the rrtypes.

Write down when one of the following happens:

• zone created/deleted
• record created/deleted

Display a searchable audit log

• global log for superusers
• per-tenant

Use either the system/models built into the django admin or one of these.

Display a link to /admin in the top-right corner, next to "Logout", if user may has staff permissions.

rst is more common in the python world and more easily imported into sphinx or pypi.

Our environment variable loading is currently a bit hacky. Try to find a django app or unrelated library to do the heavy lifting for us. If there is none, make up a better solution ourselves or at least move the current one into a different file for better testing.

PowerDNS requires the content of TXT records to be quoted and escaped properly. This can be confusing to users. Since we can fully automate the expected behavior, we should hide it from the user.

See https://doc.powerdns.com/authoritative/appendices/types.html#txt for details.

For TXT records, when saving

• add " around record context
• escape " as \"
• escape \ as \\

and when getting:

• reverse all of the above for display and editing

DeleteConfirmView currently implements success_message handling all on its own.

• look into replacing custom code with SuccessMessageMixin
• allow static success_messages

Tenant admins can specify one or more tenants when creating a zone. Add an edit button to change this afterwards.

Dino offers a number of configuration values, which can be set via the environment.

• add a doc site listing the names, default values, example values and a short description
• try to get that list from the code, so we don't duplicate it

The django TIME_ZONE config value sets ... the timezone used for logging, auditing and other things. Add the env variable DINO_TIME_ZONE to enable admins to set it.

Currently configuration can only be read from the process environment. While this is handy for docker-base deployments, setting values in a simple text file might be desiderable.

• Introduce a .env-dino or .dino-env key-value text file.
• Load these values and use them as defaults when there is no value in the process environment.
• Think about having multiple ones (e.g. global, in $HOME, cwd) and load them in a sane order.

Zone names are currently shown just like the PowerDNS API returns them. For zones containing non-ascii characters, the punnycoded form is shown.

• decode zone names when listing in frontend
• decode zone names when managing tenants in admin
• decode record names when listing

Editing punnycoded zones/records is a different beast and handled in #46.

Zones may not be present in the PowerDNS API when we expect them to. This may happen if some other system changed the data or when PowerDNS temporarily returns no or faulty data.

If we detect that a zone is present in our database, but not in API responses, present the user with a "this zone has vanished, want to delete?" screen. In case the user does not have permission to delete that zone, present a similar screen, asking them to contact their admin.

Add a DINO_FILES_ROOT variable, used to derive STATIC_ROOT (in .../static) and MEDIA_ROOT (in .../media) settings.

Permissions are currently enforced on the server side and indicated on the client site by disabling the respective buttons. The server side behavior is already implemented and tested.

• add a test for btn_perm
• test that the buttons in the respective views are actually disabled
  • delete zone
  • create zone
  • delete record
  • create zone

The test coverage currently ends at our pdns wrapper class. Add a new type of tests, spinning up an actual powerdns in docker and test a few basic workflows against it. A new powerdns instance should be used for each test case.

• create zone and check that it's in the list
• create zone with invalid zone name, check if error message is passed onto client
• delete zone
• create record and check that it's in the list
• delete record

enable users to create records at apex/root using the following as name:

• empty string
• the character @

Also consider . (a dot) and the domain name itself (e.g. example.com with or without the trailing dot).

• add zones to django-admin
• disable deletion
• list tenants

This is mainly to enable admins to get a list of tenants for a given domain.