if your API is a fully documented public API then you're not really
bothered about revealing information to hackers as the API is fully
documented anyway. in this case returning a 404 to the user is not
helpful to enable them to debug reasons for failure, and returning
a 401 with a descriptive error is more useful
support a fail_render config option to allow users of the plugin to
return a custom status code and render json/text/etc when routing
fails due to has_priv/is/is_role failures
slight refactoring in args checking and helper initialization to
remove duplicate code
update perldoc to reflect above changes, add tests for this and also
add tests to check calling the plugin without config settings shows
expected errors
test coverage in this change is increased to full stmt, bran, and
sub coverage, cond coverage is increased from 45% to 70%:
if your API is a fully documented public API then you're not really bothered about revealing information to hackers as the API is fully documented anyway. in this case returning a 404 to the user is not helpful to enable them to debug reasons for failure, and returning a 401 with a descriptive error is more useful
support a fail_render config option to allow users of the plugin to return a custom status code and render json/text/etc when routing fails due to has_priv/is/is_role failures
slight refactoring in args checking and helper initialization to remove duplicate code
update perldoc to reflect above changes, add tests for this and also add tests to check calling the plugin without config settings shows expected errors
test coverage in this change is increased to full stmt, bran, and sub coverage, cond coverage is increased from 45% to 70%:
...ious/Plugin/Authorization.pm 100.0 100.0 70.5 100.0 93.3