Hi Casey, On Thu, Sep 8, 2016 at 10:49 PM, Casey Bodley <cbodley@xxxxxxxxxx> wrote: > Thanks for the extra background! You've convinced me that it makes sense to > extend the auth interfaces to support this instead of treating it as a > special case. But I still don't think that AuthEngine is the right place to > manage that state - mainly because each request will be trying to > authenticate against multiple different engines, and only one of them will > be successful. So with stateful AuthEngines, we'll have to construct and > destruct instances for all of the engines that fail, and then once we find > one that succeeds, we have to move or copy that instance to extend its > lifetime to that of the req_state. I don't see a generic way to do that > without an extra allocation. I see your concerns. I think we can deal with the issues of additional dynamic allocations and moving/copying memory as well. At the moment ::authorize() of the Swift API's handler instantiates multiple engines on stack only to form the array of interface-typed pointers. I'm pretty sure we can create them in the step-by-step manner and perform the real job having only one instance alive at the same time. The mockup of AuthStrategy::Visitor interface is designed to utilize this pattern. We can pair the step-by-step processing together with the static_ptr, that already has the emplace<ConreteClass>(ctor, args) machinery, to create AuthEngine instance directly in its final location. This way we can avoid creation of disabled auth engines, dynamic memory allocations, std::moving/copying between ::authorize() scope and req_state and even optimize the on-stack memory usage. > I pointed out AuthApplier (which is what we return from a successful call to > AuthEngine::authorize()) earlier, because it's an existing example of auth > state that we store with req_state for later access. That seems like a much > better pattern for something like AuthCompletion. I suggested combining this > with AuthApplier, because a) then we don't have to allocate the completion > state separately, and b) the completion is a noop for most auth engines. What makes me a bit uncomfortable with putting the authenticate_complete() into AuthApplier is mixing responsibilities. Applier operates in the area of identity - it verifies whether someone owns an account, has the admin status, loads its account info and so on. AuthEngine in turn is supposed to encapsulate the request authentication process. Verifying message integrity looks like a part of request authentication and thus conceptually seems to be the Engine's job. Regards, Radek -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
