PDNS checks that when a `CNAME` rrset is created that no other rrset of
the same name but a different rtype exists. When changing a record type
to `CNAME`, PDA will send two operations in one api call to PDNS: A
deletion of the old rrset, and the addition of the new rrset. For the
check in PDNS to pass, the deletion needs to happen before the addition.
Before PR #1201 that was the case, the first api call did deletions and
the second handled additions and changes. Currently the api payload
contains additions first and deletions last. PDNS applies these in the
order they are passed in the payload to the api, so to restore the
original/correct/working behaviour the order of operations in the api
payload has to be reversed.
fixes#1251
Allow the new domain name to be input absolute (with a dot at the end).
To keep the rest of the logic working as-is, remove it fairly early in
the function.
Would have loved to use `str.removesuffix()` but that's python v3.9+.
When clicking the changelog button for a record with the name
`foo-bar.example.org`, the url you get redirected to is
`/domain/example.org/changelog/foo-bar.example.org.-A`. Because of the
non-greedy behaviour of the path converter, the last part gets split at
the *first* hyphen, so the example above gets wrongly dissected into
`record_name=foo` and `record_type=bar.example.org.-A`. This results
for obvious reasons in an empty changelog.
As described in rfc5395 [0], types have to be alphanumerical, so its
converter is changed from path to string.
The hyphen is one of the few characters recommended by rfc1035 [1],
so it is a bad choice as separator. The separator is instead changed to
a slash.
Granted, this does not entirely solve the issue but at least makes it a
lot less likely to happen. Plus, a lot more and other things break in
pda with slashes in names.
[0] https://datatracker.ietf.org/doc/html/rfc5395#section-3.1
[1] https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1
Starting with the very first commit, the update was always done with
two api calls: one for DELETE and one for REPLACE. It is however
perfectly valid and save to do both at once, which makes it atomic, so
no need for the rollback. Plus it only updates the serial once.
There is no point in sending the full RRset data when deleting it, the
key attributes to identify it are enough. This also make the behaviour
consistent with the api docs [0] where it says "MUST NOT be included
when changetype is set to DELETE."
[0] https://doc.powerdns.com/authoritative/http-api/zone.html#rrset
Setting this attribute on a cookie marks it as non-cross-site, so it
is only send in requests to our own server. It is reasonable that no
one else should need our session or csrf data. Setting it explicitly
also prevents any issues from the ongoing change in browser behaviour [0]
when it is unset.
Seasurf supports the SameSite attribute starting with v0.3. As nothing
obviously broke, I used the opportunity and updated all the way to the
most recent version.
The SeaSurf default for SameSite is already `Lax`, so it only needs to
be set for the session cookie.
[0] https://developers.google.com/search/blog/2020/01/get-ready-for-new-samesitenone-secure
Setting these two options to True is recommended if (and only if) you
serve PDA via TLS. It will break things on plain-HTTP deployments.
For plain deployments these can be set in the flask config file, for
docker they have to be whitelisted to be set via env vars.
CSRF has been initialized *before* the app config was fully read. That
made it impossible to configure CSRF properly. Moved the CSRF init into
the routes module, and switched from programmatic to decorated
exemptions. GET routes don't need to be exempted because they are by
default.
