> On May 9, 2016, 11:12 a.m., Alexander Rukletsov wrote: > > src/master/http.cpp, line 2872 > > <https://reviews.apache.org/r/46784/diff/3/?file=1369724#file1369724line2872> > > > > Why don't we return `MethodNotAllowed` here? Same applies to the agent, > > actually : ) > > Jan Schlicht wrote: > Because `authorizeEndpoint` isn't supposed to create a `http::Response`. > Its purpose is to answer the question whether a principal is authorized to do > things and it's the caller's responsibility to create a HTTP response from > that answer. But to create the answer, the function needs informations that > it extracts from the HTTP request. Because these informations may be missing, > we need to handle that case here, hence we fail the `Future`. > > Alexander Rukletsov wrote: > So now we return "HTTP/1.1 503 Service Unavailable" in this case. Do you > think it's right? > > In retrospect, there was a mistake to move request parsing into this > function. You know check that the request is correctly formed in > `authorizeEndpoint()`, from where you can't return `Response`. I suggest to > split this function in two: one for parsing and another for mapping principal > to subject. > > Jan Schlicht wrote: > That's a good point! I'd would also aid in factoring out the > `authorizeEndpoint` function like you're suggesting above. Will work on that! > > Jan Schlicht wrote: > Hmm, but there's a reason why we pass an `http::Request` here: The first > version of `authorizeEndpoint` took an `endpoint` parameter. Because there's > no type for that or rather endpoints are a part of the string "path", this > parameter was passed as a `std::string`. That wasn't explicit enough, hence > we decided to extract the endpoint for the `Request.path` explicitly in this > function. The best solution would be to have an `Endpoint` type and > `authorizeEndpoint` uses that one. An `Endpoint` could be constructed from a > path using the same logic that we currenly apply in the function. > > Jan Schlicht wrote: > Regarding the `MethodNotAllowed`: IMO that's something that shouldn't be > returned by `authorizeEndpoint`, but needs to be validated by the routed > function before that. The current behavior (i.e. without authz) of for > example the "/flags" endpoint (and other endpoints as well) is not right: > Sending a POST request will create the same response as a GET request, > because the request method isn't validated. Method validation should become > part of _every_ endpoint, it doesn't even matter if that endpoint needs to be > authorized or not.
I've created (MESOS-5346)[https://issues.apache.org/jira/browse/MESOS-5346] for that, but will also add a method validation as part of this RR. - Jan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/46784/#review132228 ----------------------------------------------------------- On May 3, 2016, 2:42 p.m., Jan Schlicht wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/46784/ > ----------------------------------------------------------- > > (Updated May 3, 2016, 2:42 p.m.) > > > Review request for mesos, Alexander Rukletsov and Benjamin Bannier. > > > Bugs: MESOS-5297 > https://issues.apache.org/jira/browse/MESOS-5297 > > > Repository: mesos > > > Description > ------- > > Access to the '/flags' endpoint is authorized using > the 'GET_ENDPOINT_WITH_PATH' action. > > > Diffs > ----- > > src/master/http.cpp 4985f24b70a00116caa4bd0335ea51e55d878d19 > src/master/master.hpp 3e55114ee7866e06513071e86e15608099dae052 > src/tests/master_authorization_tests.cpp > 804b39a269c09df9f6c0bbdf6f8b53921ac09ce8 > > Diff: https://reviews.apache.org/r/46784/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Jan Schlicht > >