This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "ESAPI Framework Strategy"
(New page: the esapi should be defined such that it can be used on behalf of applications by frameworks including containers (unless the nature of the functionality is such that it can only work fro...) |
|||
Line 6: | Line 6: | ||
leverage the access control primitives (e.j. Java permissions) employed by the underlying framework or runtime environment | leverage the access control primitives (e.j. Java permissions) employed by the underlying framework or runtime environment | ||
+ | |||
+ | where api must be embedded in app, consider separation of the specification of the logical effect of what must be achived (in the app) from the details of how it will be accomplished, such that different mechanisms can be bound to achieve the effect, such as the case with Java Annotations. |
Revision as of 14:46, 11 December 2008
the esapi should
be defined such that it can be used on behalf of applications by frameworks including containers (unless the nature of the functionality is such that it can only work from the application). another way this was said, is such that the api is compatible with ioc.
share the representations of authentication state employed by the underlying framework or runtime environment.
leverage the access control primitives (e.j. Java permissions) employed by the underlying framework or runtime environment
where api must be embedded in app, consider separation of the specification of the logical effect of what must be achived (in the app) from the details of how it will be accomplished, such that different mechanisms can be bound to achieve the effect, such as the case with Java Annotations.