How do I list directory contents on a remote server using JSch?

By I Wayan Saryada in JSch 0 Comment

To list the contents of a directory on a remote server using JSch (a Java library for SSH), you need to establish an SSH connection and use the SFTP protocol to query the directory. Here’s how you can do it programmatically:

Steps to List Directory Contents:

  1. Establish a session: Connect to the remote server with the appropriate credentials (host, port, username, password/key).
  2. Access the SFTP Channel: Open and connect a ChannelSftp instance.
  3. Change to the Target Directory: Navigate to the directory you want to list.
  4. Retrieve Directory Contents: Use the ls method of ChannelSftp to get the directory listing.

Here’s example code for this:

package org.kodejava.jsch;

import com.jcraft.jsch.*;

import java.util.Vector;

public class SFTPListDirectories {
   public static void main(String[] args) {
      String host = "example.com";
      int port = 22; // Default SSH port
      String user = "username";
      String password = "password"; // Or setup key-based authentication
      String remoteDirectory = "/path/to/remote/directory";

      JSch jsch = new JSch();

      try {
         // Establish SSH session
         Session session = jsch.getSession(user, host, port);
         session.setPassword(password);

         // Avoid asking for key confirmation
         session.setConfig("StrictHostKeyChecking", "no");
         session.connect();

         System.out.println("Connected to the server!");

         // Open SFTP channel
         Channel channel = session.openChannel("sftp");
         channel.connect();
         ChannelSftp channelSftp = (ChannelSftp) channel;

         System.out.println("SFTP Channel opened and connected.");

         // Change to the remote directory
         channelSftp.cd(remoteDirectory);

         // List files in the directory
         Vector<ChannelSftp.LsEntry> fileList = channelSftp.ls(remoteDirectory);

         System.out.println("Files in directory:");
         for (ChannelSftp.LsEntry entry : fileList) {
            System.out.println(entry.getFilename());
         }

         // Disconnect the channel and session
         channelSftp.exit();
         channel.disconnect();
         session.disconnect();
         System.out.println("Disconnected from the server.");
      } catch (JSchException | SftpException e) {
         e.printStackTrace();
      }
   }
}

Explanation of the Code:

  1. Session and Configuration:
    • A Session object is created and authenticated using username/password.
    • Set "StrictHostKeyChecking" to "no" if you want to bypass host key verification for testing purposes (not recommended in production).
  2. ChannelSftp:
    • The ChannelSftp object is used to navigate and interact with files/directories on the remote server.
    • The cd method is used to change to the target directory.
    • The ls method returns a Vector of ChannelSftp.LsEntry objects representing the contents.
  3. Directory Listing:
    • The getFilename() method retrieves the name of the file for each entry in the directory.
    • You can list files, directories, or other details by iterating over the entries.

Key Points to Remember:

  • The ls method may return not just files but also . (current directory) and .. (parent directory). You can filter these out if needed.
  • If using key-based authentication, you can set your private key with JSch.addIdentity("path/to/private/key").
  • Use try-with-resources or ensure proper closing of sessions and channels to avoid resource leaks.

Output Example:

For a remote directory /home/user/data containing the files:

file1.txt
file2.log
subdir

The output will be:

Connected to the server!
SFTP Channel opened and connected.
Files in directory:
.
..
file1.txt
file2.log
subdir
Disconnected from the server.

Maven Dependencies

<dependency>
    <groupId>com.jcraft</groupId>
    <artifactId>jsch</artifactId>
    <version>0.1.55</version>
</dependency>

Maven Central

How do I use AsyncContext for asynchronous processing in servlets?

By I Wayan Saryada in Servlet 0 Comment

Using AsyncContext in servlets allows you to perform asynchronous request processing. This can improve scalability in situations where a request might involve long-running operations, such as external API calls or database queries, by freeing up server threads while those tasks are performed.

Here’s how you can use AsyncContext for asynchronous processing in a servlet:

1. Mark the Servlet to Support Asynchronous Processing

You need to mark the servlet explicitly as supporting asynchronous processing using the @WebServlet annotation or by defining it in web.xml.

package org.kodejava.servlet;

import jakarta.servlet.AsyncContext;
import jakarta.servlet.ServletException;
import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

import java.io.IOException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

@WebServlet(urlPatterns = "/asyncServlet", asyncSupported = true)
// Enable async processing
public class AsyncServlet extends HttpServlet {

   // Create a thread pool for processing
   private final ExecutorService executor = Executors.newFixedThreadPool(10);

   @Override
   protected void doGet(HttpServletRequest request, HttpServletResponse response)
           throws ServletException, IOException {

      // Start async processing
      AsyncContext asyncContext = request.startAsync();

      // Add a timeout if needed
      asyncContext.setTimeout(10000); // 10 seconds

      // Submit async task to executor
      executor.submit(() -> {
         try {
            // Simulate a long task
            Thread.sleep(2000);

            // Write response
            response.getWriter().write("Asynchronous processing completed!");
         } catch (Exception e) {
            asyncContext.complete();
            e.printStackTrace();
         } finally {
            // Mark the async context complete
            asyncContext.complete();
         }
      });
   }

   @Override
   public void destroy() {
      executor.shutdown(); // Shut down the executor when the servlet is destroyed
   }
}

Key Steps in the Code:

  1. Enable Asynchronous Processing:
    Use the @WebServlet annotation’s asyncSupported = true or explicitly configure it in web.xml.

  2. Start Asynchronous Context:
    Call request.startAsync() to start asynchronous processing. This detaches the request and response from the servlet’s typical request-response lifecycle.

  3. Set Timeout (Optional):
    Call asyncContext.setTimeout() to define a maximum time for asynchronous processing. If processing exceeds this time, the AsyncListener.onTimeout method will be triggered, which can be useful for handling timeouts.

  4. Perform Asynchronous Task:
    Use a dedicated thread, thread pool (ExecutorService), or an external resource to perform long-running tasks. This prevents blocking the server’s thread.

  5. Complete the Request:
    Once processing is completed, call asyncContext.complete() to end the asynchronous context, signaling the server to finalize the response.

  6. Handle Exceptions:
    Wrap asynchronous operations in a try-catch block to handle any errors properly and ensure asyncContext.complete() is always called.

2. Advanced Use: Integrate with AsyncListener

With the AsyncListener, you can listen to lifecycle events of asynchronous operations, such as completion, timeouts, errors, etc.

package org.kodejava.servlet;

import jakarta.servlet.AsyncContext;
import jakarta.servlet.AsyncEvent;
import jakarta.servlet.AsyncListener;
import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

@WebServlet(urlPatterns = "/asyncWithListener", asyncSupported = true)
public class AsyncServletWithListener extends HttpServlet {

   @Override
   protected void doGet(HttpServletRequest request, HttpServletResponse response) {
      AsyncContext asyncContext = request.startAsync();

      asyncContext.addListener(new AsyncListener() {

         @Override
         public void onComplete(AsyncEvent event) {
            System.out.println("Async operation completed");
         }

         @Override
         public void onTimeout(AsyncEvent event) {
            System.out.println("Async operation timed out");
         }

         @Override
         public void onError(AsyncEvent event) {
            System.out.println("Async operation error occurred");
         }

         @Override
         public void onStartAsync(AsyncEvent event) {
            System.out.println("Async operation started");
         }
      });

      asyncContext.start(() -> {
         try {
            // Simulate task
            Thread.sleep(2000);

            response.getWriter().write("Task processed with listener!");
         } catch (Exception e) {
            e.printStackTrace();
         } finally {
            asyncContext.complete();
         }
      });
   }
}

3. Important Notes

  • Thread Safety: Request/Response objects are shared among multiple threads in asynchronous processing. Avoid modifying shared data in a non-thread-safe way.
  • Clean-up Resources: Always ensure you complete the AsyncContext and close any resources used during async processing.
  • Timeouts: It’s a good practice to handle timeouts using AsyncListener to notify the client of any delays.

Using AsyncContext allows your servlet to better handle high concurrency and long-running tasks, improving the application’s scalability and performance.

Maven dependencies

<dependency>
    <groupId>jakarta.servlet</groupId>
    <artifactId>jakarta.servlet-api</artifactId>
    <version>6.1.0</version>
    <scope>provided</scope>
</dependency>

Maven Central

How do I log from a servlet using ServletContext.log()?

By I Wayan Saryada in Servlet 0 Comment

In Java servlets, you can use the ServletContext.log() method to log messages, exceptions, or context-specific information. The ServletContext object is available in your servlet and allows you to log messages to the server’s log file.

Here are the common ways you can log using ServletContext.log():

1. Logging a simple message:

You can log plain text messages with ServletContext.log(String message).

package org.kodejava.servlet;

import jakarta.servlet.ServletException;
import jakarta.servlet.ServletContext;
import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

import java.io.IOException;

@WebServlet("/logMessage")
public class MyLogServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        ServletContext context = getServletContext();
        context.log("This is a simple log message.");
        response.getWriter().println("Message logged.");
    }
}

2. Logging a message with an exception:

If you want to log an exception with additional context, you can use ServletContext.log(String message, Throwable throwable).

package org.kodejava.servlet;

import jakarta.servlet.ServletException;
import jakarta.servlet.ServletContext;
import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

import java.io.IOException;

@WebServlet("/logException")
public class MyLogServlet2 extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        ServletContext context = getServletContext();
        try {
            // Simulate an exception
            int result = 10 / 0;
        } catch (Exception e) {
            context.log("An exception occurred: ", e);
        }
        response.getWriter().println("Exception logged.");
    }
}

3. Including dynamic information:

You can include dynamic content in the log messages to make your logs more informative.

package org.kodejava.servlet;

import jakarta.servlet.ServletException;
import jakarta.servlet.ServletContext;
import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

import java.io.IOException;

@WebServlet("/logAccess")
public class MyLogServlet3 extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        ServletContext context = getServletContext();
        String userIP = request.getRemoteAddr();
        context.log("Access from IP: " + userIP);
        response.getWriter().println("Access logged.");
    }
}

Points to Remember

  1. Where the logs are written: The ServletContext.log() messages are typically written to the application server’s log file (e.g., catalina.out for Tomcat). This location depends on the server configuration.
  2. Severity levels: The ServletContext.log() does not natively support different log levels like INFO, WARN, or ERROR. If you need more advanced logging capabilities, consider using a logging framework such as SLF4J, Log4j, or java.util.logging.
  3. Thread Safety: The logging methods of ServletContext are thread-safe.

This is how you can log using ServletContext.log() in your servlet-based application.

Maven dependencies

<dependency>
    <groupId>jakarta.servlet</groupId>
    <artifactId>jakarta.servlet-api</artifactId>
    <version>6.1.0</version>
    <scope>provided</scope>
</dependency>

Maven Central

How do I authenticate with a username and password using JSch?

By I Wayan Saryada in JSch 0 Comment

To authenticate using a username and password with the JSch library (used for SSH connections in Java), you can follow these steps:

Add JSch Dependency

Make sure your project includes the JSch library. You can add it using Maven or Gradle if you’re using a build system.

For Maven:

<dependency>
    <groupId>com.jcraft</groupId>
    <artifactId>jsch</artifactId>
    <version>0.1.55</version>
</dependency>

For Gradle:

implementation 'com.jcraft:jsch:0.1.55'

Steps to Authenticate using Username and Password

Here is an example of setting up a basic authentication with JSch:

package org.kodejava.jsch;

import com.jcraft.jsch.JSch;
import com.jcraft.jsch.Session;

public class JSchUsernamePasswordExample {
   public static void main(String[] args) {
      String host = "example.com";
      int port = 22; // Default SSH port
      String username = "username";
      String password = "password";

      JSch jsch = new JSch();
      Session session = null;

      try {
         // Create a new JSch session
         session = jsch.getSession(username, host, port);

         // Set the password for authentication
         session.setPassword(password);

         // Configure session to skip strict host checking (not recommended for production)
         session.setConfig("StrictHostKeyChecking", "no");

         // Connect to the server
         System.out.println("Connecting to the server...");
         session.connect();
         System.out.println("Connected successfully!");

         // Add any additional logic for your session here
         // For example, opening channels, executing commands, etc.

      } catch (Exception e) {
         e.printStackTrace();
      } finally {
         if (session != null && session.isConnected()) {
            // Disconnect the session
            session.disconnect();
            System.out.println("Disconnected.");
         }
      }
   }
}

Key Points in the Code:

  1. Host & Port: Replace "example.com" with your SSH server’s address and modify the port if needed (default SSH port is 22).
  2. Username and Password: Replace username and password with valid credentials for the SSH server you are connecting to.
  3. StrictHostKeyChecking:
    • Setting "StrictHostKeyChecking" to "no" disables host key verification.
    • This is acceptable for development but not recommended for production as it bypasses security checks. For production, add the server’s public key to the known hosts file.
  4. Error Handling: Ensure you include proper exception handling for debugging and connectivity issues.

This code will establish an SSH connection using the provided username and password. Depending on your use case, you can then use the Session object to open channels for executing commands, transferring files, etc.

How do I secure servlets with declarative security in web.xml

By I Wayan Saryada in Servlet 0 Comment

Securing servlets with declarative security in the web.xml deployment descriptor is an essential practice in Java web applications. It allows you to define security constraints without writing specific code, instead leveraging the standard configuration mechanism in web.xml. Here’s how you can do it step-by-step:

1. Define a Security Constraint

The <security-constraint> element is used to define access rules (restrictions) for specific URL patterns or resources.

<security-constraint>
    <display-name>Protected Area</display-name>
    <web-resource-collection>
        <web-resource-name>ProtectedServlet</web-resource-name>
        <url-pattern>/protected/*</url-pattern>
        <http-method>GET</http-method>
        <!-- You can specify other methods like POST, PUT, DELETE, etc. -->
    </web-resource-collection>
    <auth-constraint>
        <!-- Specify user roles allowed to access these resources -->
        <role-name>ADMIN</role-name>
    </auth-constraint>
</security-constraint>
  • <web-resource-collection>: Defines which resources (e.g., servlet paths or URL patterns) are protected.
    • Include one or more <url-pattern> sub-elements for specific paths.
    • Use <http-method> if you want to secure specific HTTP methods (e.g., GET or POST).
  • <auth-constraint>: Specifies the roles allowed access to the protected URL patterns. Define roles in the <role-name> tag.

2. Configure the Authentication Mechanism

The <login-config> element specifies the type of authentication and the location of the login pages (if required).

<login-config>
    <auth-method>BASIC</auth-method> <!-- Can be BASIC, DIGEST, FORM, CLIENT-CERT -->
    <realm-name>MySecureRealm</realm-name>
</login-config>
  • Auth Methods:
    • BASIC: Uses the browser’s built-in login dialog.
    • FORM: Uses custom login and error pages defined in web.xml.
    • DIGEST: Similar to BASIC, but passwords are hashed.
    • CLIENT-CERT: Authenticates users via client certificates (SSL/TLS).

Example for FORM Authentication:

<login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
        <form-login-page>/login.html</form-login-page>
        <form-error-page>/error.html</form-error-page>
    </form-login-config>
</login-config>

3. Define Security Roles

Use the <security-role> element to list all the roles used in your application.

<security-role>
    <role-name>ADMIN</role-name>
</security-role>
<security-role>
    <role-name>USER</role-name>
</security-role>

These roles correlate with the roles you define in the <auth-constraint> section.

4. Example web.xml Configuration

A complete example with all the above steps:

<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee" version="5.0">
    <security-constraint>
        <display-name>Secure Admin Pages</display-name>
        <web-resource-collection>
            <web-resource-name>Admin Resources</web-resource-name>
            <url-pattern>/admin/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>ADMIN</role-name>
        </auth-constraint>
       <user-data-constraint>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>

    <login-config>
        <auth-method>FORM</auth-method>
        <form-login-config>
            <form-login-page>/login.html</form-login-page>
            <form-error-page>/error.html</form-error-page>
        </form-login-config>
    </login-config>

    <security-role>
        <role-name>ADMIN</role-name>
    </security-role>
    <security-role>
        <role-name>USER</role-name>
    </security-role>
</web-app>

5. Configuring Realm

a. Tomcat: tomcat-users.xml

In Tomcat, the tomcat-users.xml file (located in the conf folder) is the default User Realm. You can define users and their roles directly in this file.

Example tomcat-users.xml:

<tomcat-users xmlns="http://tomcat.apache.org/xml"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
              version="1.0">
    <role rolename="ADMIN"/>
    <role rolename="USER"/>

    <user username="admin" password="admin1234" roles="ADMIN" />
    <user username="user1" password="password" roles="USER,ADMIN" />
    <user username="guest" password="guest" roles="USER" />
</tomcat-users>
  • username: The username the user enters in the form.
  • password: The password used for authentication.
  • roles: The roles granted to this user. These roles must match the ones defined in web.xml (<security-role>).

When a user submits the form with j_security_check, the server matches their credentials against this file and determines whether they have the necessary role(s) to access the resource.

login.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Login</title>
</head>
<body>
<form class="login-form" method="post" action="j_security_check">
    <h2>Login</h2>
    <div class="error">
        <!-- Uncomment this for demonstration -->
        <!-- Invalid username or password -->
    </div>
    <label for="username">Username</label>
    <input type="text" id="username" name="j_username" placeholder="Enter your username" required>
    <label for="password">Password</label>
    <input type="password" id="password" name="j_password" placeholder="Enter your password" required>
    <button type="submit">Login</button>
</form>
</body>
</html>

error.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Access Denied</title>
</head>
<body>
<div class="error-container">
    <h1>Access Denied</h1>
    <p>Sorry, you are not authorized to access this page.</p>
    <a href="login.html">Return to Login</a>
</div>
</body>
</html>

Key Elements Explained:

  1. <security-constraint>:
    • Protects resources (e.g., /admin/* or /protected/*).
    • Specifies roles allowed to access resources.
  2. <auth-constraint>:
    • Specifies authorized roles for the secured resource.
  3. <login-config>:
    • Defines the authentication mechanism (BASIC, FORM, DIGEST, CLIENT-CERT).
  4. <user-data-constraint>:
    • Specifies transport security (e.g., CONFIDENTIAL ensures HTTPS is used).

Notes:

  • The actual user-role mapping is provided by the application server (through deployment descriptors, database configuration, or an external realm). How roles map to users is server-specific.
  • For FORM authentication, form-login-page is a path to your custom login page relative to the application’s context root.

This declarative approach is efficient for servlet security and follows the Jakarta EE standards.