Is this key-oriented access-protection pattern a known idiom?

Question

Matthieu M. brought up a pattern for access-protection in this answer that i'd seen before, but never conciously considered a pattern:

class SomeKey { 
    friend class Foo;
    SomeKey() {} 
    // possibly make it non-copyable too
};

class Bar {
public:
    void protectedMethod(SomeKey);
};

Here only a friend of the key class has access to protectedMethod():

class Foo {
    void do_stuff(Bar& b) { 
        b.protectedMethod(SomeKey()); // fine, Foo is friend of SomeKey
    }
};

class Baz {
    void do_stuff(Bar& b) {
        b.protectedMethod(SomeKey()); // error, SomeKey::SomeKey() is private
    }
};

It allows more fine-granular access-control than making Foo a friend of Bar and avoids more complicated proxying patterns.

Does anyone know whether this approach already has a name, i.e., is a known pattern?

Answer 1

Thanks to your other question it looks like this pattern is now known as the "passkey" pattern.

In C++11, it gets even cleaner, because instead of calling

b.protectedMethod(SomeKey());

you can just call:

b.protectedMethod({});

Answer 2

It seems that this idiom like one mentioned in another SO question here. It is called Attorney-Client idiom and described in more details there.

Answer 3

some boring man like me would make the fowllow code：

int FraudKey=0;
b.protectedMethod(reinterpret_cast<SomeKey&>(FraudKey));

Answer 4

Its pretty close to this:

http://minorfs.wordpress.com/2013/01/18/raiicap-pattern-injected-singleton-alternative-for-c/

Basically if you consider a reference to an object of well designed class to be provide the access control you need to implement any access control policy that actually makes sense, applying this pattern to anything other than the constructor does not seem to make that much sense.

So as the article states, if you use this key in conjunction with those constructors for what access control might make sense, objects that represent significant parts of scares resources, that in C++ would generally be implemented as RAII objects, than the name RAIICap or RAII-Capability would indeed make sense.

http://www.eros-os.org/essays/capintro.html

Alternatively you could refer to it with a more general name like construct authority.

The implementation in the article is a bit to much main centered, that is, main needs to create all the authority keys. You can extend on it and make it more flexible by adding an additional public constructor for the key itself:

template <typename T>
class construct_authority {
  public:
    construct_authority(construct_authority<void> const&)
    friend int main(int,char **);
  private:
    construct_authority(){}
};

That way main could delegate the key creation to other parts of the program.

Personally I think the RAIICap name is quite appropriate for the useful part of this pattern.

A while ago I proposed that this simple template above could be added to the standard library.

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/p_v-aYIvO1E

Unfortunately there are issues with the idea that there can be one main fingerprint that constitutes a computational root, so something like this apparently can't have a place in the standard library. Having said this, at least for the use with the constructor of RAII classes, this pattern seems to be quite useful.