The DispatchableWithRequestNoAuthz::userCanAccess() while trying to convoy the message that developers are completly by themselves when they use DispatchableWithRequestNoAuthz, it also comes with limitations: * it introduces a weakness in the dispatchable pattern: it comes with no guarantees that ::userCanAccess() will be called before ::process() so a state that would otherwise not be needed, needs to be kept by the implementors to ensure everything has been called in the expected order. This leads to either boilerplate code or no checks at all which break the promise initially made by the API. * it results in multiple entry and output points in the request handlers so customizing responses is harder. This is caused by the fact that DispatchableWithRequestNoAuthzAPI implementations tend to return more information than only a boolean when ::userCanAccess() is called. These use cases are legitimate you might not want to return a forbidden error when the resource can not be found for example. It will also be less easy to make this interface compliant with PSR-15 if we want to align Tuleap internals to PSR standards in the future. * with or without ::userCanAccess() developers still needs to think about access control has the default layer provided by \URLVerification is only high level. A lot of the existing implementations of DispatchableWithRequest in the codebase adds their own verifications without having a ::userCanAccess() method. This is part of request #12581: Git LFS error responses might be returned in a format that does not respect the specification Change-Id: I8d615dec352c8ee14b97da9aba2196c2a0141f7d

+422 −639

Author

Thomas Gerbet (tgerbet) 2018-12-18 17:30

Committer

Thomas Gerbet (tgerbet) 2019-01-24 15:13

Hash 6e0007e3c95d953f3fbc23f06e32461ec6e72f65

Parent 27011daa0b01c497df9afd12b3422d2a2f74db76

Reference git #tuleap/stable/6e0007e3c95d953f3fbc23f06e32461ec6e72f65