Difference between revisions of "Talk:ESAPI Specification"

Revision as of 05:36, 17 June 2011

I tried to keep the specification as compatible as I can with the existing APIs, however there are definately places where existing users are going to have to modify their code - specifically where it deals with Encoding and Validation. I believe these changes are absolutely necessary however to establish a good cross-platform specification. I also believe the migration path allows for the smoothest transition for end-users (developers) to make the necessary changes without completely breaking their existing implementations. This is similar to the path that Spring-Security took with it's 2.0 -> 2.5 -> 3.0 path where they did a very similar thing and I used their experience as the basis for the proposed roadmap.

--Chris Schmidt 02:23, 16 June 2011 (EDT)

Proposed Roadmap

Does this seem like a realistic and smooth approach?

--Chris Schmidt 02:26, 16 June 2011 (EDT)

AccessController

Let's start with discussing the proposed changes to the AccessController.

Summary of proposed changes:

• Drop deprecated methods isAuthorizedForXXX, assertAuthorizedForXXX
• Replace (Object) Parameters with strongly typed StereoTypes

Thoughts?

--Chris Schmidt 02:26, 16 June 2011 (EDT)

I like the resource approach, I am imaginating there will be, lets say, a FileResource inheritated from Resource, so if a FileResource is passed to the method then only assessments against file resources will be done, am I right?

--Juan C Calderon 19:23, 16 June 2011 (CDT)

That is correct, however you could also have more complex resource types that integrate with a complex context object to create a context-based access control rule as well. This is an API that I have been silently working on (from a design standpoint) for the better part of a year so I am anxious to hear everyone's thoughts. The concept is simple - I want an API that can handle a simple Role-Based Access Control decision, a Data-Access Control Decision, and a Context-Based Access Control decision all with the same signature. I found this solution to be both elegant and simple to implement and use.

--Chris Schmidt 01:36, 17 June 2011 (EDT)

Logged in user, from where?

where is the logged in user information will come from? how is it going to be available for isAuthorized?

--Juan C Calderon 19:16, 16 June 2011 (CDT)

I personally like the Spring-Security approach - which is similar to the way ESAPI for Java currently does it - in that it uses a threadlocal; however - afaik there is no concept of ThreadLocal variables in PHP or ASP.Net. I think the best way to do this would be to borrow the concept of the SecurityContextHolder from the Spring-Security model and leave the actual implementation of how it is populated up to the implementation. So this would be a new interface called something like AuthenticationHolder or UserContextHolder with a method to getCurrentUser() which would return the currently logged in user.

--Chris Schmidt 01:32, 17 June 2011 (EDT)

Exceptions

The specification looks very "Java", that is, I am not pretty sure if you can handle structured exceptions in PHP, in Classic ASP is not possible, yet it could be emulated a little. Can we come to a representation that is more language neutral? (this is not a show stopper, just thinking on trying to be the more neutral possible)

--Juan C Calderon 19:21, 16 June 2011 (CDT)

I added this at the very end because it does feel very Java'ish to me as well. However, that being said - all of the languages have a concept of either an Error or an Exception. PHP has Exceptions and as far as I can tell in ASP.Net you can raise an Error event which accomplishes the same task. Unfortunately in modern OO languages the concept of Error has a completely different meaning than an Exception as we are using them. An error is generally a condition that cannot be recovered from whereas an Exception represents a state that can - hence the use of the Exception word.

--Chris Schmidt 01:32, 17 June 2011 (EDT)