SCWCD Notes - Web App Deployment

Tag Files- Must be deployed in WEB-INF/tags folder or subfolder. In case of jar it should be in META-INF/tags folder or subfolder.
If tag file is put anywhere else the container will recognise it as a static content.

Library Dependencies - In WAR file, META-INF/MANIFEST.MF is used to declare the library dependencies. It gives the deploy-time check for whether the container can find the packages and classes our app depends on.
Even if we dont put the META-INF directory in WAR, after deployment when the WAR is exploded, then META-INF and MANIFEST.MF is created inside that.

Server returns 404 Page not found error, if anything inside META-INF or WEB-INF is requested by client. But we can keep here active contents which can be included or forwarded by other jsp page, but client cannot request them directly.

Container will always looks for classes in WEB-INF/classes directry then it will go to WEB-INF/lib directory for jars.

classloader's getResource() and getResourceAsStream() methods can be used to access a resource (text file, JPEG etc) that's also inside a JAR. These methods are also inServletContext, but they work only for the resources which are not deployed in the jar file.

Servlet Mapping - <servlet-name>is mapped to <url-pattern>. <servlet-name>is the key and every request is come to <url-pattern>which picks the servlet associated with <servlet-name>
Three types of url pattern are their. The container looks for the matches in the given below order of match-pattern. First it chooses exact match, if its not found then opts for directory match and after al last it goes for extension match.

1. Exact Match: Must begin with slash(/), may have an extension but not mandatory. e.g.<url-pattern>/beer/selectBeer.do
2. Directory Match: Must begin with an slash(/). The directory can be real or virtual. It ends with slash(/) or *. e.g. <url-pattern>/beer/*.
3. Extension Match: Must begin with an * (never with slash) . After the * it must have an dot(.) extension. e.g. <url-pattern>*.do.

Lastly the most specific match wins. for example request for /foo/bar/mystuff.do will also matc /foo/bar/* and /foo/*. But the first one will be selected because its more specific to the request.

Configuring Welcome files in DD: welcome files are default page, they appear when only name of website is given in URL without specifying any URL. For example entering <a href="http://www.yahoo.com/">http://www.yahoo.com/</a> will take to yahoo home page, here home page is welcome file of the yahoo web application.

The files in the <welcome-file>do not start with a slash. Multiple welcome files <welcome-file>go in a single DD element <welcome-file-list>.<welcome-file-list>
<web-app...>
<welcome-file>
<welcome-file-list>
<welcome-file>index.html </welcome-file>
<welcome-file>deault.jsp </welcome-file>
</welcome-file-list>
</web-app>

Now if the web-app is having diffenerent direcotries, we don't need to specify default html or jsp pages for them separately. All default pages will be specified in on place in <welcome-file-list>and container will choose first page matching to the request. For every request container first looks for servlet url mapping, if iti doesnot finds any match then opts to scan <welcome-file-list>

webapps/MyTestApp/index.html
webapps/MyTestApp/search/default.jsp
webapps/MyTestApp/registration/index.html
webapps/MyTestApp/registration/newMember/foo.txt

Request: <a href="http://localhost:8080/MyTestApp/">http://localhost:8080/MyTestApp/</a>
Container: Choice: MyTestApp/index.html
Request: <a href="http://localhost:8080/MyTestApp/registation">http://localhost:8080/MyTestApp/registation</a>
Container: Choice: MyTestApp/registration/index.html
Request: <a href="http://localhost:8080/MyTestApp/search">http://localhost:8080/MyTestApp/search</a>
Container: Choice: MyTestApp/search/default.jsp(if index.html and default.jsp both would be in search direcotry then container will take index.html)
Request: <a href="http://localhost:8080/registration/newMember">http://localhost:8080/registration/newMember</a>
Container: Choice: When no files from <welcome-file-list>is specified the behaviou r vendor specific. Tomcat shows directory list, another container may shoe 404 error.

Configuring Error Pages in DD: Used to display freindly message when any error/exception happens.

catch-all error page: applies to everything in web app- not just in jsps. Anything thatsThrowable can be declared in <exception-type>
<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/errorPage.jsp</location>
</error-page>
(this can be overridden in original jsp by adding a page directive with an errorPage attribute)
Explicit exception error page: for example, follwing error page will be called only when there's ArithmeticExcption, for all other exceptions te first error page will be called (Throwable)
<error-page>
<exception-type>java.lang.ArithmeticException</exception-type>
<location>/arithmeticError.jsp</location>
</error-page>
HTTP statuc code error page: for example, following error page will come when the status code for the response is 404. HttpServletResponse.sendError(402) can also be used to send own response code and pull the pages from <error-page> tag.
<error-page>
<error-code>404</error-code>
<location>/arithmeticError.jsp</location>
</error-page>
response.sendError(HttpServletresponse.SC_FORBIDDEN); and response.sendError(403); are same.

Note: We cannot have both status code and exception type in single <error-page>tag.

</web-app>Configuring Servlet initialization in DD: Servlets are initialized at first request. So when the first client requests a servlet, class loading, instantiation and initalization happens of a servlet, before service() method can be invoked.

To load servlet on deploy time <load-on-startup> element is used in DD.

<servlet>
<servlet-name>one</servlet-name>
<servlet-class>com.sanjeev.One</servlet-class>
<load-on-startup>2</load-on-startup>
</servlet>

<servlet>
<servlet-name>two</servlet-name>
<servlet-class>com.sanjeev.Two</servlet-class>
<load-on-startup>2</load-on-startup>
</servlet>

Now the servelt one will be loaded first then servlet two will be loaded durig deployment. Any number greater than zero in <load-on-startup> element assists the servlet to be initailized during deployment.

Writing XML compilant JSP:

1. <%@page import="java.util.*" %> --- <jsp:directive.page import="java.util.*" />
2. <%! int y=3; %> ---- <jsp:declaration>int y=3;</jsp:declaration>
3. <% list.add("Hoop"); > ---- <jsp:scriptlet>list.add("Hoop");</jsp:scriptlet>
4. There is no spoon ---- <jsp:text>There is no spoon</jsp:text>
5. <= it.next() %> ---- <jsp:expression> it.next() </jsp:expression >

Refering EJBs in web-app:

Local Beans : <ejb-local-ref>
<ejb-ref-name>ejb/Customer</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<local-home>com.java.customerHome</local-home>
<local>com.java.Customer</local>
</ejb-local-ref>

Remote Beans :<ejb-ref>
<ejb-ref-name>ejb/Customer</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>com.java.customerHome</home>
<remote>com.java.Customer</remote>
</ejb-ref>

Env Entry: <env-entry>
<env-entry-name>rates/discountRate</env-entry-name>
<env-entry-type>java.lang.Integer<env-entry-type>
<env-entry-value>10</env-entry-value>
</env-entry>

<env-entry-name>- This will be used in code to lookup entry.
<env-entry-type>- It can be any type that takes a single String as a constructor parameter or a single character if the type is java.lang.Character.
<env-entry-value>- It will be passed in as String or a single character if the is java.lang.Character.

Note that its not only primitive type or wrapper type. It can be any type which have single String as parameter constructor.

Configuring Mime type mapping: mapping between extension and the mime type.

<mime-mapping>
<extension>mpg</extension> <!-- do not include the dot "." -->
<mime-type>video/mpeg</mime-type>
</mime-mapping>

SCWCD Notes - Security

Type of Bad guys (for whome securiy is needed) -

1. Impersonator- Pretends to be some exsisting user and breaks into the system.
2. Upgrader - Existing user, breachs security and upgrades his rights to avail more facility.
3. Evasdropper - They steal information of clients and misuse them for example stealing credit card info and using.
   

Four Points in Servlet Security-

1. Authentication (user/password) - Validates identity of user and is meant for Impersonators.
2. Autherization - Filters the rights/accessibility of users and is for Upgraders.
3. Confidentiality- Securing data e.g. encryption. Used to foil evasdroppers.
4. Data Integrity - Used to foil evasdroppers.
   

Authentication in HTTP: how browser and web server communicate?

1. Browser requests for "update.jsp". After receiving the request container finds the
   URL in security table.
2. If entry found in security table, server checks if the resource is constrained.
3. Constrained yes then server
   send 401("Unauthorized"), with a www-authenticate header and realm info.
4. Browser gets 401 and after getting realm info asks for username password.
5. Browser again asks for "update.jsp" but with security HTTP header and username and
   password. Container receives the request and checks the URL in security table.
6. If URL found in security table, that resource is constrained and checks for username and password to make sure they match.
7. If username password matches container checks for role i.e. authoraization and returns
   "update.jsp" if role has access to the page. Otherwise 401 is returned.
   

Implementing Security in web-app
Who:
Servlet Provider : No need to bother about security.
Administrator: Determines the type of roles and descriptions. For example Guest, Member,Admin. Authentication is done by admin.
Deployer: Determines which role will access which resource/servlet. Last three i.e. authorization, confidentiality and data integrity are done by deployer.

Authentication: A users can't be authorized until he is authenticated. Servlet spec doesn't talk about how the container should implement authentication, its all vendor dependent how to keep data of username and password.
realm: This is the place where where authentication info(user/password table) is stored. For example tomcat keeps all authentication data in conf/tomcat-users.xml and it applies to all web apps deployed in the servler. this file is not kept in any web-app directory. This is called as memory realm because tomcat loads this file in memory at startup.
&lt;tomcat-users&gt;
&lt;role rolename="Guest"/&gt;
&lt;role rolename="Member"/&gt;
&lt;user name="Bill" password="coder" roles="Member, Guest" /&gt;
...
&lt;/tomcat-users&gt;

Remember, this is not part of DD.

Enabling Authentication: If you want container to ask user name and password, following need to be written in DD.
&lt;login-config&gt;
&lt;auth-method&gt;BASIC&lt;/auth-method&gt;
&lt;/login-config&gt;