zervnet/pdns

PowerDNS

pdns's Issues

Rest API Feature: cryptokeys POST

Feature

Implement the POST Method for cryptokeys.
Description: Link

• Implement feature
• Implement test

pdnsutil and REST API implement redundant functionallity

The REST API and the pdnsutil command line tool both implement the same functionality, this leads to heavy code redundancy.

You can see that ws-auth.cc (REST API) and pdnsutil.cc feature the same code in quite some cases. For examples see:

• deleteZones in pdnsutil to the corresponding code from line 797 in ws-auth
• createZones in pdnsutil to the corresponding apiServerZones in ws-auth

We would propose to implement an underlying Interface that encapsulates the needed functionallity. This would lead to less code redundancy and a more uniform way to interact with the software as the REST API and the pdnsutil tool would use the same interface.

Any input would be highly appreciated.

TODO for PR

• api_spec.md
• 200 OK
• json formatierung
• change 'CryptoKey' to 'Cryptokey' to be consistent (or vise versa in ws-auth.cc)
• dnsseckeeper.hh
• 165/166 change return of addKey to bool and add &key_id as parameter for addKey
• dbdnsseckeeper.cc
• 97 throw runtime_error("Wrong bit size!"); more specific error
• pdns/ws-auth.cc
• 564 wrong intend
• pdns/ws-auth.cc
• GET/PUT/DELETE Code redundancy / consistent return codes
• 553 whitespace
• 598 why do you have inquireKeyId in the param list and then check for key_id in req->parameters too?
• 758 PUT returns 204
• 606 DELETE change to 200 no body
• 633Change 'can't'
• 631/637 No '!'
• 668 delete tmpAlgo and assign into algorithm
• 676 space try' '{
• 700 add &
• 701 key format could not be paresed. please make sure your key is correct
• 674 insert else and throw exception for wrong/unknown algorithm else if (providedAlgo != NULL)
• 732 aufräumen
• 685 POST change behavior in case of: just content given -> change api_spec
• 780 space
• docs/markdown/httpapi/api_spec.md
• POST change additional fiels in case 'content == null'
• 732 grammar issue
• 717 Change to 200
• 738 Change json type
• regression-tests.api/test_cryptokeys.py
• 26 grammar issues
• 26ff change to test just return 200
• split the test function per each comment that you wrote.
• change 'Cryptokeys.zone' to 'self.zone'
• 43 change to 'self.assertNotIn(zonename, out)'
• 53 just 200
• 85 grammar
• 258 what's z for?
• pdns/pdnsutil.cc
• 1748 delete '!'
• modules/bindbackend/binddnssec.cc
• 332 add more context to exception (failed to execute last query)
• pdns/backends/gsql/gsqlbackend.cc
• 667ff missing ASSERT_ROW_COLUMNS() to prevent reading out of bound (custom queries !!!)

Update Rest Api Documentation

Update the rest api documentation for the features:

• #3 Rest API Feature: cryptokey_id PUT
• #2 Rest API Feature: cryptokeys POST
• #1 Rest API Feature: Create the possibility to delete cryptokeys by id using rest api.

Specify this features in a way that goes conform to powerdns documentation.

Rest API Feature: cryptokey_id PUT

Allow the update of a single CryptoKey by its ID.
TODO in api_sec.md: cryptokey_id PUT

PUT will solely be used to activate or deactivate a cryptoKey, given it's ID

• Find schematics for JSON representation of data
• Find corresponding backend functionality
• update api_spec .../cryptokeys/:cryptokey_id PUT
• Implement test cases
• Implement feature

REST API Feature: Create the possibility to delete cryptokeys by id using rest api.

Feature

This feature should delete cryptokeys by their id.

The link leads to the TODO in the api_spec.md from pdns repo.

For protocol guidelines i would recommand this:

DELETE specification

DELETE is pretty easy to understand. It is used to delete a resource identified by a URI.

On successful deletion, return HTTP status 200 (OK) along with a response body, perhaps the representation of the deleted item (often demands too much bandwidth), or a wrapped response (see Return Values below). Either that or return HTTP status 204 (NO CONTENT) with no response body. In other words, a 204 status with no body, or the JSEND-style response and HTTP status 200 are the recommended responses.

HTTP-spec-wise, DELETE operations are idempotent. If you DELETE a resource, it's removed. Repeatedly calling DELETE on that resource ends up the same: the resource is gone. If calling DELETE say, decrements a counter (within the resource), the DELETE call is no longer idempotent. As mentioned previously, usage statistics and measurements may be updated while still considering the service idempotent as long as no resource data is changed. Using POST for non-idempotent resource requests is recommended.

There is a caveat about DELETE idempotence, however. Calling DELETE on a resource a second time will often return a 404 (NOT FOUND) since it was already removed and therefore is no longer findable. This, by some opinions, makes DELETE operations no longer idempotent, however, the end-state of the resource is the same. Returning a 404 is acceptable and communicates accurately the status of the call

Project schedule week 10

These goals should be reached until 20.06 12:15 pm.

• Create a good Wiki here for the docker development envrioment #8
• Create all docker backend files #7 (everybody)
• Test backends for the add Key #4
• Change 501 error in cryptokeys.
• Add backend test solution to Docker
• Submit big PR

Edit this Issue to take a task. Set your name behind a task. I would recommend to create a new issue when working on an goal.

Backend Test Schemata / Docker Container / conf

This has to be done for all backends:

High Priority:

• Generic MySQL
• Generic ODBC no cool solution for linux
• Generic PostgreSQL
• Generic SQLite3
• BIND

Lower Priority:

• Generic Oracle
• GeoIP
• LDAP
• MyDNS
• OpenDBX
• Oracle
• Pipe
• Random
• Remote
• TinyDNS

Create a pull request for all enhancements of the rest api

See here for guidelines.

• #1 Delete
• #2 Post
• #3 Put

Let addKey return the id of the inserted key

This has to be done for all backends:

High Priority:

• Generic MySQL tested
• Generic ODBC tested
• Generic PostgreSQL tested
• Generic SQLite3 tested
• BIND tested

Lower Priority:

• Generic Oracle
• GeoIP
• LDAP
• MyDNS
• OpenDBX
• Oracle
• Pipe
• Random
• Remote
• TinyDNS

Create a Wiki entry in PowerDNS Wiki page.

• We should ask the PowerDNS people to invole our development envrionment solution in thier repository.
• Create a short Wiki here for the docker development envrioment

Project schedule week 9

These goals should be reached until 20.06 12:15 pm.

• Finish docker development envrioment scripts (benj-zen)
• Create a docker Pull request or ask for integration (MrM0key)
• Create a short Wiki here for the docker development envrioment #8
• Finish Put/Patch Tests (zervnet)
• Create all docker backend files #7 (everybody)
• Test backends for the add Key #4
• Add POST api-spec #5 (MrM0nkey)
• What is csk ? (MrM0nkey)

Edit this Issue to take a task. Set your name behind a task.

Project schedule week 11-13

These goals should be reached until 14.07 12:15 pm.

• Create BIND/Sqlite docker backend files #7 (zervnet)
• Add backend test solution to Docker
• Prepare a presentation for the project
• Submit big PR (everybody)

Edit this Issue to take a task. Set your name behind a task. I would recommend to create a new issue when working on an goal.