0

I'm reading a book on design patterns. On proxy pattern the code are following:

class SensitiveInfo:

    def __init__(self):
        self.users = ['nick', 'tom', 'ben', 'mike']

    def read(self):
        nb = len(self.users)
        print(f"There are {nb} users: {' '.join(self.users)}")

    def add(self, user):
        self.users.append(user)
        print(f'Added user {user}')


class Info:
    """protection proxy to SensitiveInfo"""

    def __init__(self):
        self.protected = SensitiveInfo()
        self.secret = '0xdeadbeef'

    def read(self):
        self.protected.read()

    def add(self, user):
        sec = input('what is the secret?')
        self.protected.add(user) if sec == self.secret else print("That's wrong!")

There are several security flaws in this as book mentioned. For example clear-text password. I know how to deal with this.

But nothing prevents the client code from bypassing the security of the application by creating an instance of SensitiveInfo directly.

The book mentioned to use abc module to forbid direct instantiation of SensitiveInfo. I don't know how. Seems to me creating a abstract class then another inherent from it still been able to create an instance of the child class therefore access users.

1 Answer 1

3

Using python abstract base classes is super-easy (if you compare it to any other language): https://docs.python.org/3/library/abc.html

In the case you mentioned, the proxy pattern allows you to decouple (read as hide) the SensitiveInfo class from the code that needs access to that info through Info class. This is not a matter of security but rather code dependencies. Also, please note since this is Python, that nothing restricts you from accessing the .protected or .secret member in your client code.

And about information security, you might make a confusion here. To restrict access to a "users" database table you should implement some API that requires authentication / authorization. The design-patterns are just industry best practices related to code structure for a specific outcome (most often code decoupling or dependency inversion).

3
  • Florin i don't think your answer is what I'm looking for. I know how to use abstract class but here I don't know how to use it to stop client bypassing security like the book mentioned. That's the original words of the book.
    – Yehui He
    Jan 12 at 15:18
  • What author is asking is to protect client from reading SensitiveInfo.users by using abstract class. I can make class SensitiveInfo(metaclass=ABCMeta). Therefore stop client making instance of SensitiveInfo. But I still have to write an implementation class inheriant SensitiveInfo. Then from there I can make an instance to access super's users anyway
    – Yehui He
    Jan 12 at 15:27
  • 1
    I cannot argue with a book. Either you are misinterpreting the text of the book either the author is making the security confusion. Let me be clear: there is no way to prevent data access. To some extent, the word "protect" can be used in the sense that you can provide your own "SensitiveInfo" implementation, or replace it in the future without affecting the client code that uses the "Info". So the protection is against rebuild/redeploy and not against access.
    – Florin C.
    Jan 13 at 14:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.