Well, in my Java day job we use Spring Security, which I have to say works very well and is very flexible.<div>So I was trying to go with a similar approach and trying to figure out the best way to integrate it with the current twisted.web approach for CorePost:</div>
<div><br></div><div>a) a common security filter that intercepts incoming requests. Can be configured per URL pattern (e.g. "/services/rest","/services/operations" requires security, but "/services/public" does not)</div>
<div><br></div><div>b) a separate config for the security filter that defines required privileges (per sub root, e.g. "/services/rest" may require "ADMIN_USER", but "/services/rest" may require "OPERATIONS_USER")</div>
<div><br></div><div>c) additional optional feature where every REST method can be annotated with additional privileges (so a GET on a REST resource may need different privileges vs a POST, PUT or DELETE, etc.)</div><div><br>
</div><div>d) every incoming request creates a Principal (which is a user overriden type if necessary) that holds info about the current user making the REST request (e.g. name, roles, privileges, etc.)</div><div><br></div>
<div>I tried looking through twisted.web docs to see if there is a concept of a generic filter (that can be applied across multiple resources) but didn't really find anything.</div><div>Hence I implemented it manually myself in CorePost 0.0.11.</div>
<div><br></div><div>I will dig further to see how the Spring Security approach (which I like and it works very well on a huge complex SaaS platform we have) could maybe be applied on top of the current twisted.web APIs as part of CorePost.</div>
<div><br></div><div>Any suggestions, comments or pointers would be welcome. </div><div><br></div><div>Cheers</div><div>Jacek</div>