En Java, ¿cómo me aseguro de que mi aplicación web sea segura para subprocesos?

Question

¿Cómo me aseguro de que mi aplicación web java servlets sea segura para subprocesos? ¿Qué debo hacer con respecto a las variables de sesión, las variables estáticas de una clase o cualquier otra cosa que pueda ser un problema de seguridad de subprocesos?

Answer 1

Hecho: hay sólo 1 instancia de un servlet en la webapp toda la vida. Se crea en el inicio de webapp y se destruye en el cierre de webapp. También vea this answer para una interpretación aproximada.

Por lo tanto, se ha compartido entre todas las solicitudes (hilos). Si asigna la solicitud o los datos del ámbito de la sesión como variable de instancia (o incluso peor, como static), definitivamente no es inseguro, ya que se comparte entre todas las solicitudes (subprocesos) de todos los usuarios (sesiones) de toda la aplicación. Solo tiene que asignarlos como variables locales de método para mantenerlos seguros. Entonces:

public class MyServlet extends HttpServlet { 

    private Object thisIsNOTThreadSafe; 

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { 
     Object thisIsThreadSafe; 

     thisIsNOTThreadSafe = request.getParameter("foo"); // BAD!! Shared among all requests! 
     thisIsThreadSafe = request.getParameter("foo"); // OK, this is thread safe. 
    } 
} 

Eso es básicamente todo lo que necesita tener en cuenta al desarrollar servlets con seguridad de hilo en mente.

Luego están los atributos de sesión (HttpSession) que pueden compartirse entre varias solicitudes del mismo usuario, pero en el mundo real no necesita preocuparse por sincronizar el acceso a la sesión. Por lo general, solo pone allí datos específicos del usuario, como el usuario que ha iniciado sesión, las preferencias específicas del usuario, la cesta de la compra, etcétera. Solo necesita asegurarse de no colocar datos con ámbito de solicitud pura en el ámbito de la sesión. Se reflejaría en múltiples ventanas/pestañas del navegador dentro de la misma sesión.

Entonces hay aplicación (ServletContext) atributos que son compartidos entre todos los usuarios applicationwide, pero que normalmente ponen únicas constantes y otros datos estáticos allí, como la configuración de aplicación web, la fábrica de DAO, contenidos DropDownList, etcétera.Todo esto, por cierto, se puede hacer con un ServletContextListener, también ver this answer para un ejemplo básico. Solo debe asegurarse de no colocar datos de ámbito de solicitud o sesión puros en el ámbito de la aplicación.

Answer 2

¿Quiere decir en contexto a diferencia de cualquier otra aplicación de Java? Realmente no hay mucha diferencia. Cada solicitud a un servlet hace que el contenedor emita un nuevo hilo para manejarlo, por lo que las variables de instancia dentro del servlet deben ser seguras para hilos. Es mejor manejar todo tu negocio con variables locales en los métodos doGet/doPost(). Hay un problema que puedo pensar. Con las variables de sesión, puede ser que el usuario tenga abiertas dos ventanas del navegador, ambas apuntando a su aplicación. En este caso, también deberá tener cuidado con la seguridad de los hilos con el alcance de la sesión.

Answer 3

Guau, esa es una pregunta cargada.

En pocas palabras, debe asegurarse de que el acceso a los datos compartidos esté cuidadosamente sincronizado. Por ejemplo, es posible que desee sincronizar el acceso a una variable estática con un mutex o una función sincronizada.

Tenga en cuenta que también puede necesitar sincronizar en niveles superiores si necesita transacciones atómicas que modifiquen múltiples recursos compartidos al mismo tiempo.

Diseñar una aplicación concurrente no es simple, y no hay una bala mágica (desafortunadamente). Recomiendo mucho el libro "Java Concurrency in Practice" para obtener más información sobre cómo escribir código concurrente seguro.

Answer 4

• no utilice variables de instancia de servlets y filtros
• no utilizan variables estáticas
• read this article on session thread safety
• piensan