Class hierarchy - class should only called by another class - swift

Question

I try to implement a Security class and a Secret class. In my whole project the Secret class should only called by Security.getSecretInstance().doSomeSecretAction()
So Secret.doSomeSecretAction() should throw an compile error.
I need the Security.getSecretInstance() for an authentication process.
I'm searching for a good pattern or something else, but I think my searching keywords are too bad or my requirement is stupid/or not possible.
At the moment I call Security.getSecretInstance() it returns a singleton instance of Secret, but I could call Secret.doSomeSecretAction() too. There is no difference.
Do you have some pattern, keywords or snippets for me?
Edit
My definition of awesome would be that I have one method like this:
Security.isAuthorized { secret in
secret.doSomeSecretAction
}, failure {
print("permission denied")
}
And I can get secret only with this .isAuthorized-Method

Answer 1

What I would recommend doing is declare Secret nested inside Security, make Secret private and create non-private methods inside Security that can access Secret. Something like this:
class Security {
class func doSomeSecretAction() {
Secret.doSomeSecretAction()
}
private class Secret {
class func doSomeSecretAction(){
print("Private method called")
}
}
}
Security.doSomeSecretAction()
Here, Security.doSomeSecretAction() can be called from outside the Security class, but Secret.doSomeSecretAction() can only be called inside the Security class.
Update based on comments:
A feasible solution would be declaring the initializer of Security private, so it can only be called from inside the Security class and declaring a computed variable (for now I called it shared) which is the only access point to the initializer. This computed variable either returns nil or a new instance of the Secret class based on Security.isAuthorized. This way, every time a function of Secret is called, the authorisation status is checked and the function can only be called if the status is authorised, otherwise the shared variable returns nil and hence the method is not called.
class Security {
static var isAuthorized = false //change this when the authorisation status changes
class Secret {
static var shared: Secret? {
if Security.isAuthorized {
return Secret()
} else {
return nil
}
}
private init(){} //a new instance of Secret can only be created using the `shared` computed variable, the initializer cannot be called directly from outside the Secret class
func doSomeSecretAction(){
print("Private method called")
}
}
}
Security.Secret.shared //nil
//Security.Secret.init() //if you uncomment this line, you'll get an error saying all initializers are inaccessible
Security.Secret.shared?.doSomeSecretAction() //nil
Security.isAuthorized = true
Security.Secret.shared?.doSomeSecretAction() //function is called
Security.isAuthorized = false
Security.Secret.shared?.doSomeSecretAction() //nil

Answer 2

I was working on this answer while Dávid was editing his; I didn't realize he'd posted an update awhile ago. There's a lot of overlap in our answers, so this is just another style of the same approach.
First, I want to be clear that what you're describing can only implement encapsulation, not "security." I mean that you can build a system that makes it easy for developers to use it correctly and difficult to use it incorrectly. That's pretty straightforward. But you won't be able to stop a developer from extracting the secret and running any code they want. It's their machine and you're giving them the code. They can always run it. They have a debugger; you're not going to hide anything.
But, preventing accidental misuse is a fine goal, and pretty straightforward. The first thing is that you should work with instance methods, not class methods. Class methods makes all of this harder than it needs to be. A solution to your problem will look something like this, relying on fileprivate for most of the access control.
class Security {
enum Error: Swift.Error {
case unauthorized
}
// This feels like it should be nested in Security, but doesn't have to be
class Secret {
// No one outside this file can instantiate one of these. It's likely
// that you'll be passing some parameters here of course.
fileprivate init() {}
// I'm assuming you want these to be single use, so people can't store
// a reference to them an reuse them. This is one simple way.
fileprivate var isAuthorized = true
private func validate() {
// I'm treating this kind of reuse as a programming error and
// crashing. You could throw if you wanted, but it feels like it
// should never happen given your design.
guard isAuthorized else {
fatalError("Secrets can only be used once")
}
}
func doSomeSecretAction() {
// Every "protected" method (which may be all of them) needs to
// call validate() before running.
validate()
print("SECRET!")
}
}
// Public so we can test; obviously this would at least private(set)
var isAuthorized = false
func withAuthorization(execute: (Secret) -> Void) throws {
guard isAuthorized else { throw Error.unauthorized }
// We create a new Secret for every access and invalidate it after.
// That prevents them from being stored and reused.
let secret = Secret()
execute(secret)
secret.isAuthorized = false
}
}
// -- Some other file
let security = Security()
security.isAuthorized = true // For testing
var stealingTheSecret: Security.Secret?
do {
try security.withAuthorization {
$0.doSomeSecretAction() // This is good
stealingTheSecret = $0 // Try to steal it for later use
}
} catch Security.Error.unauthorized {
print("Unauthorized")
}
stealingTheSecret?.doSomeSecretAction() // Let's use it: Crash!
In principle you could get rid of the validate() boilerplate by allocating the memory for Secret directly with UnsafeMutablePointer and destroying it at the end, but this is probably more trouble than it's worth to avoid one extra line of code.
(Note that allocating the memory yourself still wouldn't protect you against the caller saving the object; they can always make a copy of the memory and re-instantiate it with .load; any unsafe thing you can do, so can the caller. This also allows them to circumvent validate() by directly modifying the boolean or copying the object before you invalidate it. There is no technique that will prevent unsafe memory access; this is why you cannot protect secrets inside code.)

Answer 3

After research I find a good and simple solution for me:
class SecurityLayer {
private static var authorized: Bool = false
static func makeAuthorizeCheck() -> API2? {
if authorized {
return API2()
}
return nil
}
}
Second class (not subclass)
class Secret {
func test() {
print("test")
}
fileprivate init() {
}
}
Examples
SecurityLayer.makeAuthorizeCheck()?.test() //working
Secret() //forbidden
Secret.test() //compiler find this method, but there are no permissions to use this one
When the constructor inside Secret is private this wouldn't work anymore. For me the benefit of fileprivate is obvious now.
!The classes have to be in one file!