1. 15 May, 2018 1 commit
  2. 15 Mar, 2018 2 commits
  3. 09 Mar, 2018 1 commit
  4. 12 Jan, 2018 1 commit
  5. 02 Jan, 2018 1 commit
  6. 15 Dec, 2017 1 commit
  7. 22 Nov, 2017 1 commit
    • Fallback to permission domain authorizer if it is not resolved on the permission target · 87aeb116
      This fixes a behavior of permission checks with ObjectIdentity.ALL targets, e.g.:
      
        @WithAuthorizer(MyProductAuthorizer.class)
        public class Product { .. }
      
        public enum ProductPermission<Product> { ADD, EDIT, ...; }
      
        // this works well, MyProductAuthorizer is resolved from product object
        plauAuthApi.isPermitted(ProductPermission.EDIT, product);
      
        // this failed to work because default ObjectIdentity.ALL does not have any metadata
        // now the AccessControlManager will fall back to resolve Authorizer from the
        // permission's class ProductPermission.ADD reflectively
        plauAuthApi.isPermitted(ProductPermission.ADD);
      Sergey Sokolenko committed
  8. 21 Nov, 2017 3 commits
  9. 14 Nov, 2017 1 commit
    • Fix permission implication to respect permission scopes · 5fa85940
      The given permission can only allow/imply other permissions if they're
      applied to the same target or the given permission is applied to a
      domain (isClassIdentity) rather than to a specific object.
      
      This rule ensures that more specific permission won't imply more generic ones, e.g.:
      
        "allow Block.EDIT(b1)" can imply "allow Block.SHOW(b1)"
         but NOT "allow Block.SHOW(b2)" or "allow Block.SHOW(*)"
      
      P.S. This fix does not affect the behavior of the DefaultAccessControlListVoter
      since it already performed proper checks.
      Sergey Sokolenko committed
  10. 20 Sep, 2017 2 commits
  11. 15 Sep, 2017 1 commit
  12. 22 Aug, 2017 1 commit
  13. 27 Jul, 2017 1 commit
  14. 14 Mar, 2017 1 commit
  15. 08 Mar, 2017 1 commit
  16. 07 Mar, 2017 1 commit
  17. 03 Mar, 2017 2 commits
  18. 21 Feb, 2017 1 commit
  19. 14 Feb, 2017 1 commit
  20. 06 Feb, 2017 1 commit
    • RASCHCM-3 Refactor play-cms in order to reduce static state and improve DI flexibility · bfff359e
      - Deprecate static CMS in favor of injectable CMSApi
      - Make Metrics non-static and injectable; also, had to remove metrics from BlockFinder as it cannot rely on DI
      - Move the "reset" logic into it's own class from CMSApi; the setup logic should be simplified further...
      - Move Formatters registration from CMSApi into injectable Provider as suggested by official play docs
      - Split DI modules into more fine grained modules for more flexiblity when overriding them in child projects
      - Add convenient default to multisite setup to make it less painful
      - Update to the latest stable playframework
      Sergey Sokolenko committed
  21. 10 Jan, 2017 3 commits
    • PLAY-8 Fix tests · 08806fe2
      Anton Orlov committed
    • HOTFIX Move DomainPermission.ALL to GlobalDomainPermission.ALL · e8d2e62b
      The static final member `ALL` in the interface `DomainPermission` was inherited by permission enums which lead to confusion when people see inherited
      `ALL` member among other enum constants, e.g. accessing PartyPermission.ALL will actually access DomainPermission.ALL and may lead to programming
      errors like assigning global superuser permission to unrelated party or role, e.g.:
      
          // allow cmsAdminRole to do everything on cms blocks
           acm.allowPermission(cmsAdminRole, BlockPermission.ALL)
      
       but actually we're getting
      
           acm.allowPermission(cmsAdminRole, DomainPermission.ALL)
      
       So, in this HOTFIX the `ALL` constant is moved to dedicated final noninstantiatable class `GlobalDomainPermission`, so `ALL` constant is no logner available among other enum constants and won't be misused as shown above.
      Sergey Sokolenko committed
  22. 09 Jan, 2017 1 commit
  23. 07 Jan, 2017 2 commits
  24. 23 Dec, 2016 1 commit
  25. 29 Nov, 2016 1 commit
  26. 23 Nov, 2016 2 commits
  27. 22 Nov, 2016 1 commit
  28. 17 Nov, 2016 2 commits
  29. 16 Nov, 2016 1 commit
  30. 15 Nov, 2016 1 commit
    • HTS-64 Refactor DefaultParty · 0e42e706
      The DefaultParty in play-cms had flawed "party preferences" implementation which lead to JPA errors (entity out of sync, etc), also the DefaultParty had other small issues like public class attributes, use of JPA APIs inside entity, etc. In this commit the major functionality related to preferences is refactored, and the following commits will fix found issues during testing.
      Serhii Sokolenko committed