Custom Authorization check in rules

Splash Forums Rewrite Users Custom Authorization check in rules

This topic contains 3 replies, has 2 voices, and was last updated by  Christian Kaltepoth 4 weeks, 1 day ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #27420



    I need to perform some custom authorization checks and either allow the user to see the page or redirect to an access denied page. I want, for example, to check if the user owns a “unit” before letting them see the edit screen.

    I currently have something like this and it works but I would like to know if this is the correct way to go about this or if there is an easier/cleaner way.

            return ConfigurationBuilder.begin()
                    .addRule().when(Direction.isInbound().and(Path.matches("/unit/edit/{id}").withRequestBinding().and(new HttpCondition() {
                          public boolean evaluateHttp(HttpServletRewrite event, EvaluationContext context) {
                              final Parameter<?> parameterized = DefaultParameterStore.getInstance(context).get("id");
                              final String value = DefaultParameterValueStore.getInstance(context).retrieve(parameterized);
                              if (StringUtils.isNumeric(value)) {
                                  return !editUnitController.checkOwnership(Long.parseLong(value));
                              else {
                                  return false;



    Hey Craig,

    your code looks good. I agree that this kind of authorization checking isn’t very easy to do with Rewrite. And to be honest, I’m actually not sure whether it should be done using Rewrite. I typically do such authorization checks in the JSF page action because it is much simpler to do there.

    One thing you could do to make your configuration provider more readable is to extract the creation of the custom HttpCondition to a method.

    Something like:

    public HttpCondition isAccessAllowed() {
      new HttpCondition() {
        // ...


    Thanks for your comment. I had considered doing it in a controller class but had thought it might be easier to do in rewrite so had a go 🙂 If you’re doing it in a controller how would you then force the redirect to an access denied page? Just a redirect in a PostConstruct method?

    When I first started looking at it I had hoped to be able to annotate a method in the controller to be run as that would allow all the logic to be contained in the controller.

    maybe something like:

    public boolean hasFailedCustomAuthorisation() {}




    I also tried to handle authorization with Rewrite for some time. But it tends to be very difficult. Especially if you do more fine permission checks on object level.

    I usually have a helper class like this:

    public class FacesRequests {
      public static void sendForbidden() {
        sendStatusCode( 403, null );
      public static void sendForbidden( String msg ) {
        sendStatusCode( 403, msg );
      public static void sendNotFound() {
        sendStatusCode( 404, null );
      public static void sendNotFound(String msg) {
        sendStatusCode( 404, msg );
      public static void sendStatusCode( int status, String message ) {
        try {
          FacesContext context = FacesContext.getCurrentInstance();
          HttpServletResponse response = (HttpServletResponse) context.getExternalContext().getResponse();
          if( message != null ) {
            response.sendError( status, message );
          else {
            response.sendError( status );
        catch( IOException e ) {
          throw new IllegalStateException( "Could not send redirect", e );

    And then I do permission checks in my JSF page actions like this:

    public class SomePageBean {
      // page action
      public void load() {
        if( !permissionService.isCanViewThisSpecificPage() ) {
        // ....
      // ....

    This works very well. You can use some service or helper class for permissions checks on object level and then simply use a static method to handle the result in case of failures. Instead of sending a 403, you could also simply send a redirect. This shouldn’t be too hard.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.

Comments are closed.