Avaa Control Panel->System->Advanced->Environment options.
Muokkaa path muuttujaa lisäämällä loppuun ; ja Java asennushakemisto bin alihakemisto.
Käynnistä komentokehoite uudestaan ja testaa komennolla jar.

Lisäys win9X:ssa:

· "Start", "Run" sysedit klikkaa OK.

· Valitse ikkuna jossa lukee AUTOEXEC.BAT.

· Etsi PATH sana, jollei löydy niin lisää se seuraavasti:

PATH C:\WINDOWS;C:\WINDOWS\COMMAND;C:

\J2SDK1.4.1_<version number>\BIN

· Avaa komentokehoite ja aja c:\autoexec.bat.

Jollet ohjeista huolimatta saa SDK:n työkaluja käyttöön, katso http://java.sun.com/j2se/.

5.2 WAR ja web sovelluksen käsittely

Tässä kappaleessa käsitellään sovellusten levittäminen käyttäen WAR (web application archive) pakettia. WAR pakettiin sijoitat kaikki tarvittavat tiedostot (ja hakemistot) jotka sovelluksesi tarvitsee.

5.3 WAR paketin tekeminen

Monet Java työkalut (kuten NetBeans) mahdollistavat war-paketin tekemisen helpolla tavalla. Mikäli tällaista työkalua ei ole käytettävissä, joudut tekemään paketin Java SDK:n mukana tulevalla jar-työkalulla.

Paketin tekeminen vaatii oikeanlaisen hakemistorakenteen, eli samanlaisen kuin normaalilla web sovelluksella.

Kun olet saanut hakemistot luotua, lähdekoodit kirjoiteltua ja käännettyä, voit luoda sovellukselle war paketin käyttäen Java SDK:n jar työkalua seuraavasti: Mene ensin juurihakemistoon, eli hakemistoon jonka alta löytyy suoraan WEB-INF hakemisto ja anna seuraava komento:

jar cvf paketin_nimi.war

Paketti kannattaa tehdä kunnon työkaluilla (kuten Jbuilder), mikäli sinulta sellainen löytyy. Paketin luomisessa SDK:n työkaluilla ei ole mitään hankalaa, mikäli paketti toimii oikein. Paketin configurointi onkin sitten hankalempaa. Lisää war paketeista voit lukea

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/WebComponents3.html

5.4 WAR paketin asentaminen Tomcattiin

Tomcatissä sijoitat war paketin TOMCAT_HOME\webapps hakemiston juureen. Kun käynnistät tomcatin, puretaan war pakettisi ja web sovelluksesi on valmis käyttöönotettavaksi. Tomcatin ollessa käynnissä voit päivittää war-paketin uuteen versioon. Asetuksista riippuen Tomcat asentaa uuden version sovelluksestasi.

Toinen vaihtoehto asentaa WAR paketti on käyttää tomcatin manageri –apuohjelmaa, jota käyttäen asennus onnistuu selaimen avulla (voit asentaa sovelluksesi myös eri koneelta).

Seuraavalla komennolla asentaminen hoidetaan s.e contextiksi tulee uusi ja war-paketti on ollut hakemistossa c:\java\

http://localhost/manager/install?path=/tutor&war=jar:file:c:/java/tutor.war!/

Itse asiassa paketin voi asentaa miltä tahansa koneelta seuraavalla syntaksilla

war=jar:http://hostname:port/relativepath/warfile.war!/

esim.

http://192.168.23.20/manager/install?path=/testi&war=jar:http://192.168.23.19/java/testi.war!/

5.5 Tomcat manager

Tomcat manager ohjelman avulla voit hoitaa kaikki seuraavissa kappaleissa kuvatut tehtävät. Katso

http://localhost/manager/html/

5.6 Asennettujen web sovellusten listaus

Listaus tapahtuu komennolla

http://localhost/manager/list

5.6.1 Asennetun web sovelluksen uudelleen lataaminen (reload)

Web sovelluksen uudelleen lataaminen tapahtuu komennolla

http://localhost/manager/reload?path=/sovelluksen_nimi

esim.

http://localhost/manager/reload?path=/tutor

Tällöin kaikki servletit (myös JSP-sivuista käännetyt) ajetaan alas, ja niiden destroy metodit tapahtuvat. Servlettien käynnistyessä uudelleen (määritelty load-on-startup elementillä web.xml tiedostossa) tapahtuvat init-metodit.

5.7 Sessiotiedot

Web sovelluksen sessiotiedot saat selville

http://localhost/manager/sessions?path=/sovelluksen_nimi

5.8 Web sovelluksen pysäyttäminen ja käynnistäminen

Pysäyttäminen tapahtuu stop komennolla seuraavasti

http://localhost/manager/stop?path=/sovelluksen_nimi

Vastaavasti sovellus käynnistetään start komennolla

http://localhost/manager/start?path=/sovelluksen_nimi

5.9 Asennetun sovelluksen poistaminen

Sovelluksen poistaminen (undeploy) tapahtuu seuraavasti

http://localhost/manager/remove?path=/sovelluksen_nimi

Tällä komennolla ei kuitenkaan mitään tiedostoja tai hakemistoja poisteta. Sovellus vain poistetaan Tomcatin sisäisesti listasta, jolla ylläpidetään sovelluksia.

5.10 Security realms

Tomcatin uusiin piirteisiin (versiossa 4) kuuluu security realms, vapaasti suomennettuna turvallisuusalueet, joiden ansiosta Tomcat kestää vertailun entistä paremmin vastaavien kaupallisten tuotteiden kanssa. Tällä tekniikalla saadaan suojattua web sovelluksen resurssit.

Tomcatissä on kaksi eri realm-toteutusta valmiina.

5.10.1 Memory realms

Tomcatin käyttäjien roolit, käyttäjätunnukset ja salasanat on asetettu tällä tekniikalla. Tietoja pääset muokkaamaan TOMCAT_HOME\conf\tomcat-users.xml tiedostosta. Tiedosto on yksinkertainen XML notaatiota noudattava konfigurointitiedosto. Alla tiedoston sisältö

<?xml version='1.0' encoding='utf-8'?>

<tomcat-users>

</tomcat-users>

Kuten huomaat, tiedoston alussa on luotu rooleja <role> tagilla, ja myöhemmillä riveillä käyttäjiä. Käyttäjä voi kuulua moneen ryhmään. Tällöin ryhmien nimet erotellaan roles attribuutin arvossa toisistaan pilkulla. Admin ja Manager roolissa olevat käyttäjät voivat käyttää Tomcatin manager sovellusta, jonka graafisen käyttöliittymän saat näkyviin osoitteessa

http://localhost/manager/html/list

Admin roolissa olevat käyttäjät pääsevät lisäksi käsiksi Tomcatin administrointi sovellukseen:

http://localhost/admin/login.jsp

Oman sovelluksen suojaaminen MemoryRealm-tekniikalla

Seuraavaksi suojataan oma web sovelluksemme, tutor.

Lisää tomcat-users.xml tiedostoon uusi käyttäjä:

Avaa sovelluksen web.xml tiedosto, ja lisää sinne seuraavat rivit:

<security-constraint>

<web-resource-collection>

<web-resource-name>tutor webapp</web-resource-name>

<url-pattern>/*</url-pattern>

</web-resource-collection>

<auth-constraint>

<role-name>tutorUser</role-name>

</auth-constraint>

</security-constraint>

<login-config>

<auth-method>BASIC</auth-method>

<realm-name>tutor webapp</realm-name>

</login-config>

Reloadaa tutor webapp komennolla

http://localhost/manager/html/reload?path=/tutor

Yrittäessäsi käyttää jotain resurssia tutor sovelluksesta, saat eteesi seuraavan ikkunan:

Kuva 1. Autentikointi-ikkuna

5.10.2 JDBC Realms

Toinen tapa suojata sovelluksesi on JDBC Realms. Erona edelliseen on se, että käyttäjätiedot tallennetaan tietokantaan. Seuraavassa kerrotaan vaiheet jossa käyttäjätiedot tallennetaan MS Access kantaan (johtuen myöhemmistä vaiheista tietokantaratkaisu ei ole kovin hyvä).

Luo seuraavat taulut:

Kuva 2. Taulujen rakenne ja yhteydet

Aseta kenttien tyypit seuraavasti:

· user_name: varchar(12)

· user_pass: varchar(12)

· role_name: varchar(12)

Syötä rooleihin seuraavat roolinimet:

· tutorUser

· tutorDeveloper

· tomcat

· manager

· admin

Syötä user_name ja user_pass seuraavasti:

· user | password

· pekka | god

· tutor | god

Liitä käyttäjät rooleihinsa lisäämällä seuraavat tietueet (name | role) user_roles tauluun:

· user | tutorUser

· pekka | tutorUser

· pekka | tutorDeveloper

· pekka | manager

· pekka | admin

· tutor | tutorUser

Tallenna tietokanta nimellä tutorUsers.mdb.
Lisää alias nimellä tutorUsers (Windowsissa avaa Control Panel ->Administrative tools->ODBC datasources->Add ja valitse Microsoft access driver sekä kirjoittele seuraavat tiedot):

Kuva 3. Aliaksen luominen

Configuroi server.xml tiedostoa. Kommentoi kaikki muut <realm> elelementit pois ja lisää seuraava elementti:

<Realm className="org.apache.catalina.realm.JDBCRealm" debug="99"

driverName="sun.jdbc.odbc.JdbcOdbcDriver"

connectionURL="jdbc:odbc:tutorUsers"

userTable="users" userNameCol="user_name" userCredCol="user_pass"

userRoleTable="user_roles" roleNameCol="role_name" />

Käynnistä Tomcat uudestaan.

Mennessäsi http://localhost/tutor/ hakemistossa mihin tahansa resurssiin saat eteesi loggautumisikkunan.

JDBC Realmin edut

Ensiksi mieleen tulevia etuja ovat ainakin helpompi konfigurointi. Myös käyttäjien lisäys ”lennossa” on helpompaa, eikä muutosten jälkeen tarvitse käynnistää mitään uudestaan.

Käyttäjätietojen selvittäminen

Kun käyttäjä on autentikoinut itsensä (antanut käyttäjätunnuksen ja salasanan, loggautunut) on helppoa lukea käyttäjän tiedot käyttäen HttpServletRequest objektia. JSP sivulla käyttäjätunnuksen lukeminen tapahtuu seuraavasti

request.getRemoteUser();

5.11 Tomcat valves

Kyseinen tekniikka on tullut käyttöön vasta Tomcatin versiossa 4. Tekniikka mahdollistaa eräänlaisten esiprosessorien käytön (valve =venttiili) Tomcatissä versiossa 4.1.12 on valmiina neljä valvea.

Access log valve

· logi tiedostot käyttäjätiedoista mm.

o sivujen kävimäärät

o käyttäjien autentikointi tiedot

Remote address Filter

· Mahdollista rajata käyttäjiä IP-osoitteiden avulla (jokerimerkit sallittuja maskeissa, onneksi!).

Remote Host Filter

· Erona edelliseen on se, että verrataan käyttäjän IP:n jakaneen palvelimen (host) IP:tä, ei itse käyttäjän IP osoitetta.

Request Dumper Valve

· Voit ”dumpata” HTTP otsikkotiedot määritettyyn logiin tietyistä pyynnöistä.

5.12 Servlet filters

Servlettifiltterien[1] avulla pystyt tutkimaan ja muuttamaan sekä pyyntöjä että vastauksia (request/reply). Servlettifiltterit liitetään (mapataan) tiettyihin URL-osoitteisiin. Servlettifilttereitä on mahdollista ketjuttaa. Filtterit esiteltiin servletti spesifikaatioversiossa 2.3.

Filtterien avulla pystyt tekemään monia asioita. Niiden avulla voit esimerkiksi varmistaa autentikoinnin, upottaa vastauksen alkuun ja loppuun jonkin sisällön, muuntaa tulostuksen esim. XML-muotoon tai kryptata tulostuksen.

5.12.1Servlettifiltterin toteutus

Seuraavassa on toteutettu luokka, joka toimii servlettifiltterinä lisäten jokaiseen pyyntöön yhden attribuutin.

import java.io.IOException;

import javax.servlet.Filter;

import javax.servlet.FilterChain;

import javax.servlet.FilterConfig;

import javax.servlet.ServletContext;

import javax.servlet.ServletException;

import javax.servlet.ServletRequest;

import javax.servlet.ServletResponse;

public final class ExampleFilter implements Filter {

public void init(FilterConfig config) throws javax.servlet.ServletException {

System.out.println("ExampleFilter: init"); //debuggausta

}

public void destroy() {

System.out.println("ExampleFilter: destroy ");

}

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws java.io.IOException, javax.servlet.ServletException

{

System.err.println("ExampleFilter: ennen doFilter()");

request.setAttribute("alias", new String("jdbc:odbc:tutorUser"));

chain.doFilter(request, response); //kontrolli ketjun seuraavalle filtterille, //mikäli sellainen on

System.err.println("---->ExampleFilter: jälkeen doFilter()<----");

}

Sovelluksen web.xml tiedostoon lisätään seuraavat rivit, joilla filtteri ensin esitellään ja sitten määritellään osoitteet, joihin filtteri vaikuttaa (tässä filtteri käsittelisi kaikki jsp sivut).

<filter-name>Filter 1</filter-name>

<filter-class>ExampleFilter</filter-class>

</filter>

<filter-mapping>

<filter-name>Filter 1</filter-name>

<url-pattern>*.jsp</url-pattern>

</filter-mapping>

Testataan filtterin toiminta luomalla JSP sivu, jossa attribuutin arvo luetaan. Ensin kuitenkin web sovellus pitää ladata uudelleen. Filtterin toiminta testataan seuraavalla skripletillä (filterTest.jsp):

String attrib = (String) request.getAttribute("alias");

if( attrib == null )

out.println("Attribuuttia ei saatu luettua. Filtteri ei taida toimia");

else

out.println("Filtteri toimii. Attribuutin arvo on " + attrib);

String user = request.getRemoteUser(); //autentikoitu käyttäjä

if( user != null )

out.println("<BR>" + "Olet loggautunut käyttäjätunnuksella " + user);

Ole erittäin huolellinen käyttäessäsi servlettifilttereitä. Koodivirheet saattavat aiheuttaa sen, ettei koko sovelluksesi toimi.

[1] Tarkemmin http://java.sun.com/products/servlet/Filters.html