Question

I’m using Struts2+Spring+Hibernate in Tomcat.

I’m having an issue with users being able to type in a .jsp or .action url directly. Everything they need to access is accessible from the homepage so I want to block this access.

I’ve been looking for an answer and I’ve found some stuff, particularly pertaining to .jsp blocking. I’ve added

<security-constraint>
<web-resource-collection>
<web-resource-name>Deny Direct Access</web-resource-name>
<description></description>
<url-pattern>*.jsp</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>Denied</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<role-name>Denied</role-name>
</security-role>

to my web.xml but that doesn’t seem to do anything. Then I changed

<filter-mapping>
    <filter-name>struts2</filter-name>
    <url-pattern>*</url-pattern>
</filter-mapping> 

to

<filter-mapping>
    <filter-name>struts2</filter-name>
    <url-pattern>*.action</url-pattern>
    <url-pattern>*.html</url-pattern>
    <url-pattern>/index.jsp</url-pattern>
</filter-mapping> 

which blocks some .jsp files but not others. I’ve made sure not to put

<url-pattern>*.jsp</url-pattern>

in any of my security roles.

I’ve heard I can put all my jsps in /Web-inf but this seems like a big hassle as I’ll then have to change the paths in every instance of my application where I reference them.

I also can’t find anything involving blocking direct access to .action classes. If there is someone I can be pointed to find this information, it would be much appreciated. Thanks.

Answer 1

If you place your JSPs under the /WEB-INF directory, then they will not be accessible directly.

As for .actions, you’re out of luck there — you can’t stop someone from going directly to the URL for a web page (which is what an .action ultimately is).

Why would you want to stop people from going directly to an URL? Being able to link directly to things is a pretty fundamental part of the web.

Update

Since you’re looking for a way to control access, you could create an interface and then create an interceptor. In the interceptor, check if the current action implements the interface, and if so, invoke the method on the interface.

Here’s an example:

public interface SecurableAction {
  void checkSecurity();
}

public class SecurityInterceptor extends AbstractInterceptor {
  @Override
  public String intercept(ActionInvocation invocation) throws Exception {
    Object action = invocation.getAction();
    if (action instanceof SecurableAction) {
        ((SecurableAction) action).checkSecurity();
    }

    return invocation.invoke();
  }
}

Finally, in your action’s checkSecurity() method, check that the current user has access to invoke the action. If the user does not have access, throw an exception of some sort (I usually create one called AccessViolation and then map it to a custom error page).

public class YourAction implements SecurableAction {
  @Override
  public void checkSecurity() {
    if (!currentUser.hasPermission("MANAGE_OTHER_USERS")) {
      throw new AccessViolation();
    }
  }
}

Remember to add this new interceptor to your stack.

As an alternative to all of this, you could use the Preparable interface to provide all of this as well, but I find it nicer to have a separate method to encapsulate security checks.