Why is it not a good practice to write your JavaScript code in JSP / Servlet Page?

JavaScript is one of the easy as well as difficult par of a GUI developers coding life. It’s a very handy tool when mastered can be very useful. But if you don’t understand it well or if you are trying your hand at it for the first time you can really have nightmares.

 Lets discuss a security exploit very commonly targeted in JavaScript. Sites dealing in financial information, client secure data etc should be extra careful when using JavaScript. The simplest mistake most developers do is to write the script methods in the JSP / Html / Servlet Files (You can extend this to Asp client side scripting as well).

 Basically this way of coding allows users to see your code and along with it unwanted information and  security holes in your code. If application uses JavaScript intensively it is imperative that most of its GUI bugs will be in its JavaScript. And if your site has a reasonably good visibility, hackers will be prowling around WebPages for any information/data.  Show it is always best to separate your javascript as a js file and use it in the code. This also keeps your main webpage clean.

 A simple way to import javascript file in JSP is

 <SCRIPT language=”JavaScript” src=”/src/lib/test.js” “></SCRIPT>

 Many developers use a JSP include  of other JSP files(which at times contains solely javascript). Even this practice is not advisable as this might keep your code clean, but still will expose your code.

What are the JSP implicit objects ?

The Objects available in any JSP without any need for explicit declarations are implicit Objects. All of these objects have atleast page page level scope.

pageContext:The context for the JSP page. Provides access to various objects including:
servletContext: The context for the JSP page’s servlet and any web components contained in the same application. See Accessing the Web Context.
session: The session object for the client. See Maintaining Client State.
request: The request triggering the execution of the JSP page. See Getting Information from Requests.
response: The response returned by the JSP page. See Constructing Responses.

Apart from the above objects some more functionality is provided by following objects

param: Maps a request parameter name to a single value
paramValues: Maps a request parameter name to an array of values
header: Maps a request header name to a single value
headerValues: Maps a request header name to an array of values
cookie: Maps a cookie name to a single cookie
initParam: Maps a context initialization parameter name to a single value
Finally, there are objects that allow access to the various scoped variables described in Using Scope Objects.

pageScope: Maps page-scoped variable names to their values
requestScope: Maps request-scoped variable names to their values
sessionScope: Maps session-scoped variable names to their values
applicationScope: Maps application-scoped variable names to their values
When an expression references one of these objects by name, the appropriate object is returned instead of the corresponding attribute. For example, ${pageContext} returns the PageContext object, even if there is an existing pageContext attribute containing some other value.