Home/ Questions/Q 9132181
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T08:16:04+00:00

We would like to hide some code features based on user login in Tomcat.

  • 0

We would like to hide some code features based on user login in Tomcat. We are using the basic authentications. Any suggestions?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    IF what you meant was just hiding some resources depending on whether the user is logged in or not then it is just a matter of restricting access to some pages (see the references below).

    IF you want to hide some feature based on the who is logged in, then one of the solutions is to check the user role right inside JSP and output the content accordingly.

    Primitive example:
    sample.jsp

    <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
<!DOCTYPE html>
<html>
<head>
    <title>Sample Page</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
    <c:choose>
        <c:when test="${pageContext.request.isUserInRole('admin')}">
            <p>Content for admin.<p>
        </c:when>
        <c:when test=${pageContext.request.isUserInRole('someRole')}">
            <p>Some content here</p>
        <c:when>
        <c:otherwise>
            <p>Another Content</p>
        </c:otherwise>
    </c:choose>
</body>
</html>

    NB!
    To be able to invoke methods with arguments using EL you must use minimum Servlet version 3.
    Quote from here: https://stackoverflow.com/tags/el/info

    Since EL 2.2, which is maintained as part of Servlet 3.0 / JSP 2.2
    (Tomcat 7, Glassfish 3, JBoss AS 6, etc), it’s possible to invoke
    non-getter methods, if necessary with arguments.

    Another way to hide / restrict access to some of your pages depending on the user role is to make security configurations in web.xml, or use annotations (minimum Java EE 5), or create your own Filter that checks the role of the user making request.

    To create your own Filter, create a class that implements javax.servlet.Filter interface and in the doFilter() method check the role of the user that made a request by using HttpServletRequest method isUserInRole().

    Here is a simple example of implementing custom Filter:
    RoleCheckFilter.java

    package com.example.filter;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;


/**
 * Servlet Filter implementation class RoleCheckFilter.
 * Its purpose is to check logged-in user's role and
 * and accordingly allow or prevent access to the web resources.
 */
public class RoleCheckFilter implements Filter {

    /**
     * @see Filter#init(FilterConfig)
     */
    public void init(FilterConfig filterConfig) throws ServletException {}

    /**
     * @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
     */
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
                throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) res;

        if (request.isUserInRole("admin")) {
            // user have the appropriate rights, allow the request
            chain.doFilter(request, response);
        } else {
            // user does not have the appropriate rights, do something about it
            request.setAttribute("error", "You don't have enough rights to access this resource");
            response.sendRedirect(request.getContextPath() + "/login.jsp");
            // or you could forward a user request somewhere
        }
    }


    /**
     * @see Filter#destroy()
     */
    public void destroy() {}

}

    Add the appropriate filter configuration in web.xml:

    <?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
    version="3.0">

    ...

    <filter>
        <filter-name>Role Check Filter</filter-name>
        <filter-class>com.example.filter.RoleCheckFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>Role Check Filter</filter-name>
        <url-pattern>/admin/*</url-pattern>
    </filter-mapping>

    ...

</web-app>

    Of course in your case, considering the fact that you use Basic Authentication, it is much easier to make security configurations right in web.xml (declarative security) or use programmatic security.

    Quote from the official Java EE documentation:

    Java EE security services can be implemented for web applications in
    the following ways:

    • Metadata annotations (or simply, annotations) are used to specify information about security within a class file. When the application is deployed, this information can either be used by or overridden by the application deployment descriptor.

    • Declarative security expresses an application’s security structure, including security roles, access control, and authentication requirements in a deployment descriptor, which is external to the application.
      Any values explicitly specified in the deployment descriptor override any values specified in annotations.

    • Programmatic security is embedded in an application and is used to make security decisions. Programmatic security is useful when declarative security alone is not sufficient to express the security model of an application.

    Check out official Java EE documentation related to securing Java EE applications (in your case pay attention to Specifying an Authorization Constraint part):
    Java EE 6: Securing Web Applications
    Java EE 5: Securing Web Applications

    Check out also examples from the official documentation:
    Java EE 6. Examples: Securing Web Applications
    Java EE 5. Examples: Securing Web Applications

    • 0