@authorize-skip values for BasicEntities

2012-01-04
2012-09-09
  • I feel the following BasicEntties should have @authorize-skip values as view
    instead of the current default of false. This is because, these entities are
    so basic that they would be accessed for read in a lot of non-authenticated
    use cases:

    Enumeration

    EnumerationType

    Geo

    GeoAssoc

    GeoPoint

    Uom

    UomConversion

    This is only a suggestion.

     
  • David E. Jones
    David E. Jones
    2012-01-04

    In most cases these entities should be used by a screen or service that either
    doesn't require authorization or that has a permission setup for the user to
    access it.

    Is there a particular scenario that you're finding inconvenient for these?

     
  • The customer-facing website component has a few screens which are accessible
    with requires-authentication=false. In these screens, a list of GEOs (Country,
    State & City) need to be printed. To achieve this, I had to explicity add Auth
    params for these screens. But, in my opinion these entities are so basic that
    the developer should not be forced apply screen auths just for reading these
    entities.

     
  • Based on message#2, my inference is:

    When a screen has requires-authentication=false, auth-check on any
    entity access should not fail.

    If this inference is right, I noticed that my app is not conforming to this
    behaviour. I have my screen setup for no-authentication access. However, I am
    still getting auth exceptions in this screen.

     
  • David E. Jones
    David E. Jones
    2012-01-08

    I need think about this some more. It is an issue that a service that doesn't
    require authentication may use other resources, especially entities, that do
    still require authorization.

    You can get around this by calling the ec.artifactExecution.disableAuthz()
    method at the beginning of your method to disable authz (just for that
    thread), and then ec.artifactExecution.enableAuthz() to get authz going again.

    While this is a reasonable solution for services meant to be called without a
    user, it is somewhat cumbersome. A better option might be to consider the
    service to be running with an authorized user in this case, because
    disableAuthz() will also disable explicit denies which you may want to
    preserve.

     
  • David E. Jones
    David E. Jones
    2012-01-08

    In commit fecfb03 I've added options to the service.@authenticate attribute
    and methods to the ArtifactExecutionFacade API to consider the current
    artifact anonymously authorized for all actions or for view-only.

    Hopefully that will fill this feature gap (or resolve this annoyance). I may
    also add something to screens that is like the service.@authenticate
    attribute.