What are security proxies?

Zope3 has been designed with security as a major priority for web based access. Each object/component that is exposed through the web gets wrapped in a 'Security Proxy'.

It is possible to remove the proxy - in code - but usually it should not be necessary(!)

Whenever you hit a problem with a method that can not be accessed it is usually the security mechanism that kicked in because you did not expose the method through an interface.

Section lifted from TransitionToSecurityProxies:

Security proxies surround objects to prevent unauthorized access. Untrusted code is only allowed to access basic objects, such as strings and numbers, or security proxies.

When an object is passed to untrusted code, it is wrapped in a security proxy unless it is already wrapped. Security proxies mediate all accesses to the wrapped object. Operations on security proxies return security proxies as well. Security proxies passed from untrusted code to trusted code remain wrapped, so untrusted code can't trick trusted code into performing operations that the untrusted code could not perform.

With care, trusted code can explicitly unwrap security proxies and gain additional access. In particular, security proxies cannot be stored in the Zope object database. If an object wrapped by a security proxy is to be stored in another object, the security proxy must be removed.

When a method is accessed in a security proxy, the method attribute access results in the method wrapped in a security proxy. If the return value is a simple value, like a string or number, it is returned as usual, otherwise, the value will be wrapped in a security proxy and returned.

When an operation, such as call or item access is performed on a security proxy, then access to the corresponding Python special method is checked. For example, for a call operation, the __call__ method will be checked. The return value from the operation is treated in the same way as for function calls.