POST method on /api/1.x/federations does not work

[ocket8888]

No matter what you put in this endpoint (provided it's valid JSON), it always returns a success while actually not doing anything.

Example

Consider a Traffic Ops instance where the only existing federation is given by this output from a GET request to /api/1.4/federations:

{ "response": [
	{
		"mappings": [
			{
				"ttl": 300,
				"cname": "blah.blah."
			}
		],
		"deliveryService": "demo1"
	}
]}

Now I send a POST request to that endpoint to create resolvers for this federation (logged in as the 'admin' user):

POST /api/1.4/federations HTTP/1.1
Host: trafficops.infra.ciab.test
User-Agent: curl/7.47.0
Accept: */*
Cookie: mojolicious=...
Content-Length: 74
Content-Type: application/json

{
	"deliveryService": "demo1",
	"resolve4": ["0.0.0.0"],
	"resolve6": ["::"]
}

... and the resulting API response:

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods: POST,GET,OPTIONS,PUT,DELETE
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: application/json
Date: Mon, 03 Dec 2018 16:02:00 GMT
Server: Mojolicious (Perl)
Set-Cookie: mojolicious=...; expires=Mon, 03 Dec 2018 20:02:00 GMT; path=/; HttpOnly
Vary: Accept-Encoding
Whole-Content-Sha512: dXg86uD2Un1AeBCeeBLSo2rsYgl6NOHHQEc5oMlpw1THOh2HwGdjwB3rPd/qoYIhOxcnnHoEstrEiHmucFev4A==
Content-Length: 63

{"response":"admin successfully created federation resolvers."}\0

but a request to api/1.4/federations/1/federation_resolvers shows that no such thing took place:

{
	"response": []
}

Note that api/1.4/federations/1/users shows that the 'admin' user is, in fact, associated with the federation identified by 1:

{ "response": [
	{
		"fullName": null,
		"email": null,
		"id": 2,
		"role": "admin",
		"company": null,
		"username": "admin"
	}
]}

Input Doesn't Matter

Even more troubling, the actual payload of the request appears to have no impact on what takes place, except that POSTing invalid JSON will result in an error and a large HTML document being returned to describe it. For example, sending the payload: {"foo":"bar"} will give the same successful message - again without actually doing anything:

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods: POST,GET,OPTIONS,PUT,DELETE
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: application/json
Date: Mon, 03 Dec 2018 16:03:37 GMT
Server: Mojolicious (Perl)
Set-Cookie: mojolicious=...; expires=Mon, 03 Dec 2018 20:02:00 GMT; path=/; HttpOnly
Vary: Accept-Encoding
Whole-Content-Sha512: dXg86uD2Un1AeBCeeBLSo2rsYgl6NOHHQEc5oMlpw1THOh2HwGdjwB3rPd/qoYIhOxcnnHoEstrEiHmucFev4A==
Content-Length: 63

{"response": "admin successfully created federation resolvers."}\0

Intended Behavior

I'm not actually sure what this is meant to do, since the api/1.x/federations/{{federation ID}}/federation_resolver and api/1.x/federation_resolvers endpoints appear to duplicate the intent specified in the documentation. It seems like there's no real use-case for this endpoint (at least not using POST), and the name is unclear at any rate - I would expect it to create a federation, not a federation resolver.

[ocket8888]

Note that I've also directly checked the database, and truly nothing is being created in the *federation* tables in response to these requests - so the issue is definitely with this POST and not the subsequent GETs.

Also, I've noticed that the success message doesn't depend on any federations actually existing with which a new resolver might be associated. Nor, then, does it depend on any federations being assigned to the specified Delivery Service, or being associated with any particular user.

[rawlinp]

It looks like your POST request body is not right per https://traffic-control-cdn.readthedocs.io/en/latest/api/v12/federation.html:

{
  "federations": [
    {
      "deliveryService": "ccp-omg-01",
      "mappings": {
        "resolve4": [
          "255.255.255.255"
        ],
        "resolve6": [
          "FE80::0202:B3FF:FE1E:8329",
        ]
      }
    }
  ]
}

The code iterates over 0..N federations and returns a 200 as long as it doesn't encounter an error. So what it appears to be doing is giving you back a 200 since you're not giving it any federations to iterate over. Can you try structuring your request like this and see if that works as expected? We should probably also change the message to say "no federation resolvers were created", but I'm not sure we can change the status code from a 200 since that's how the endpoint has always worked.

[ocket8888]

Actually, that worked I was mislead by the 'request parameters' table.
Ideally it'd return a 400 Bad Request and an error message saying that keys were missing. Whatever the case, it definitely shouldn't say something happened if it did not, in fact, happen.

[rawlinp]

Yeah, we need better API validation of the request body in that endpoint. Do you mind closing this one out and opening a new one for those issues?

[ocket8888]

sure