----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27760/#review70863 -----------------------------------------------------------
src/authentication/cram_md5/authenticator.hpp <https://reviews.apache.org/r/27760/#comment116311> Shouldn't you still check if the authenticator has been initialized? An ignorant developer might try to call authenticate without calling initialize src/master/master.cpp <https://reviews.apache.org/r/27760/#comment116375> If we change `authenticator->terminate(pid)` to `future.discard()`, and the future has actually become Ready, will a call to future.discard() still call the onDiscard handler? Because what we really want is just to erase the session from the map so that the Owned pointer drops to 0 refs and the session self-destructs. src/master/master.cpp <https://reviews.apache.org/r/27760/#comment116378> Can we tie the authenticator's future to the master's `authenticating` future? Does that even make sense? Do they always have the same lifetime/effects? src/tests/cram_md5_authentication_tests.cpp <https://reviews.apache.org/r/27760/#comment116380> Did you mean "cancel the authentication process"? How about "discard..."? - Adam B On Feb. 3, 2015, 3:05 a.m., Till Toenshoff wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/27760/ > ----------------------------------------------------------- > > (Updated Feb. 3, 2015, 3:05 a.m.) > > > Review request for mesos, Adam B, Kapil Arya, Niklas Nielsen, and Vinod Kone. > > > Bugs: MESOS-2050 > https://issues.apache.org/jira/browse/MESOS-2050 > > > Repository: mesos > > > Description > ------- > > The initial design and implementation of the authenticator module interface > caused issues and was not optimal for heavy lifting setup of external > dependencies. By introducing a two fold design, this has been decoupled from > the authentication message processing. The new design also gets us back on > track to the goal of makeing SASL a soft dependency of mesos. > > > Diffs > ----- > > src/authentication/authenticator.hpp 460494a > src/authentication/cram_md5/authenticator.hpp d739a02 > src/authentication/cram_md5/auxprop.hpp b894386 > src/authentication/cram_md5/auxprop.cpp cf503a2 > src/master/master.hpp 337e00a > src/master/master.cpp 1005686 > src/tests/cram_md5_authentication_tests.cpp a356aa1 > > Diff: https://reviews.apache.org/r/27760/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Till Toenshoff > >
