JSP and Web Application Security

In Java EE form-based authentication, the login form must POST to j_security_check. This is a built-in servlet container endpoint that receives j_username and j_username parameters, authenticates the user against the realm, and redirects to the protected resource or error page. The other options (j_login, j_get_user, j_login_check, j_get_security) are not standard container-managed authentication endpoints.

Authorization is a server-side mechanism that determines whether an authenticated user has permission to access specific resources or perform certain operations. While authentication verifies identity (can be client-side), confidentiality and data integrity are broader security properties applicable to data in transit and storage, not specifically resource access control.

The element is required in a because it defines which resources (URL patterns) are being protected. The other elements ( goes in , goes in , is a separate top-level element, goes in ) serve different purposes or are in different sections of the deployment descriptor.

JSP pages using Java classes need the page directive with import attribute. The syntax is <%@ page import='java.util.Date' %>. Option B incorrectly uses 'class' instead of 'page' and 'import' as the directive name. Options C and D use include directive (for including files at translation time), not for importing classes.

When is false, both scripting expressions (<%= ... %>) and EL expressions (${ ... }) are allowed. Therefore, the JSP will successfully translate and execute both '10 x 5 = 50' (using EL) and '2 * 3 = 6' (using scripting expression). Setting it to true would disable scripting elements but not EL.