1. 27 Dec, 2018 1 commit
  2. 26 Dec, 2018 1 commit
  3. 25 Dec, 2018 1 commit
  4. 17 Dec, 2018 1 commit
  5. 14 Dec, 2018 1 commit
  6. 04 Dec, 2018 1 commit
  7. 23 Nov, 2018 1 commit
    • Leave in DefaultParty minimal set of constrains · 6740287d
      Anton Sudak authored
      Java Validation API attempts to validate constrains on all fields in
      hiearchy. But in certain circumstances this might lead to false-positive
      constrain violations, e.g. if password field in DefaultParty would be
      marked as required it and in children class it would be overriden to
      bring new constrains validation would always throw error.required on the
      parent's field.
      
      Another reason to of constrains removal is that there is no way to
      override them. Instead overriding we append new constrains, even if we
      use the same annotation. This caused by the way how Java handles
      annotations.
  8. 06 Nov, 2018 1 commit
  9. 04 Oct, 2018 1 commit
  10. 02 Oct, 2018 1 commit
  11. 01 Oct, 2018 1 commit
    • Replace PartyManager with PartyRepository · 180050ac
      Anton Sudak authored
      This change also introduces few utilities that provides better way for
      the party management:
      * PartyService - provides typesafe work with the party classes. Allows
      to make basic crud operations and form manipulations
      * SmartFormFactory - finally allows to use SmartForm via DI.
      SmartForm also get upgrade in order to bring support of validation
      groups.
      Please be aware that PartyManagerModule is disabled by default due to
      PartyManager deprecation. It still could be enabled by adding following
      line to configs:
      play.modules.enabled += "ch.insign.playauth.inject.PartyManagerModule"
  12. 21 Sep, 2018 1 commit
  13. 20 Jul, 2018 1 commit
  14. 03 Jul, 2018 1 commit
  15. 26 Jun, 2018 3 commits
  16. 20 Jun, 2018 1 commit
    • Refactor AccessControlListVoter and related functinality · 7284fe54
      Sergey Sokolenko authored
      - make sure SID/OID metadata is not written to the cache
      - cleanup old or complicated code at AccessControlListVoter class
      - add some docs to the DefaultPermissionManager class
      - make SID/OID and DefaultDomainPermission look nicer when printed to console
      - etc.
  17. 11 Jun, 2018 1 commit
    • Implement ability to remove users · c882bec6
      Anton Sudak authored
      Add actions column to users list with remove link. Add remove user confirmation dialog. Clean up user related data on removal.
  18. 07 Jun, 2018 1 commit
    • PLAY-111 Optimize AccessControlEntry storage layout · 2d731fe9
      Sergey Sokolenko authored
      This commit smashes separate allow/deny DomainActionEntry collections into single json serialized fields on AccessControlEntry, thus dramatically reducing the number of total db records and avoiding extra JOIN queries.
  19. 29 May, 2018 1 commit
  20. 25 May, 2018 1 commit
  21. 15 May, 2018 1 commit
  22. 15 Mar, 2018 2 commits
  23. 09 Mar, 2018 1 commit
  24. 12 Jan, 2018 1 commit
  25. 02 Jan, 2018 1 commit
  26. 15 Dec, 2017 1 commit
  27. 22 Nov, 2017 1 commit
    • Fallback to permission domain authorizer if it is not resolved on the permission target · 87aeb116
      Sergey Sokolenko authored
      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);
  28. 21 Nov, 2017 3 commits
  29. 14 Nov, 2017 1 commit
    • Fix permission implication to respect permission scopes · 5fa85940
      Sergey Sokolenko authored
      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.
  30. 05 Oct, 2017 1 commit
  31. 29 Sep, 2017 2 commits
  32. 20 Sep, 2017 2 commits
  33. 15 Sep, 2017 1 commit