Download dag 2 (Pim Lemmens) - Technische Universiteit Eindhoven

TU/e
technische universiteit eindhoven
Web Server Programming
2. Applications
/ architecture of information systems
http://wwwis.win.tue.nl/
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
webserver-side-specific development issues
Differences with “traditional” software applications:
• client/server “ping pong”
=> need for session management
• user interface is webpage based
• various access control / identification issues
• special issues with resource control
• issues with debugging and testing
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
webserver-side-specific development issue:
Differences […]
• […]
• […]
=> need for
session management
• […]
• […]
• […]
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
session management
webserver applications are inherently multi-user!
HTTP is stateless (requests are separate)
=>
sessions are not automatic
example: tic-tac-toe
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
multiuser tic-tac-toe
r
p
rp's move
aux. files
rp's new position
webserver
pl's move
tic-tac-toe script
pl's new position
p
l
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
session management: techniques
• stateless “session”:
server doesn’t remember any state but puts it
in HTTP request/response (see tic-tac-toe)
• session: server remembers state, only puts pointer
in HTTP request/response
• client may also remember state (e.g. cookies)
• client and server can store state across sessions
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
session management and HTTP
options to communicate state info
(the full state, or a pointer to it) with HTTP:
• encode state (or pointer to it) in URLs
• use extra POST info (when URL grows too big)
• use cookies (e.g. to persist across sessions)
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
designing session management with URLs
• a user action activates a URL
• the application generates pages with URLs to itself
state machine
1. determine the application state machine
state:
transition:
2. define a mapping: URLs -> transitions
3. make the hyperlinks in the output page
implement this mapping
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
session management with cookies
• a request arrives that isn’t part of a session yet
• the server generates a “cookie” with state info
• the server sends it with the document (in a HTTP
response header)
• the client remembers it (in memory / on disk)
• the client sends it along with subsequent URLs (in a
HTTP request header)
• the server identifies the client by the cookie
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
multiuser tic-tac-toe
r
p
rp's move
aux. files
rp's new position
webserver
pl's move
tic-tac-toe script
pl's new position
p
l
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
URLs vs. cookies
• URLs must be short,
cookies can be somewhat longer
• URLs are public (can be guessed)
• URLs are always supported by the client
• cookies can be unsupported
or refused by the client
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
webserver-side-specific development issues
Differences with “traditional” software applications:
client/server “ping pong”
=> need for session management
• user interface is webpage based
• various access control / identification issues
• special issues with resource control
• issues with debugging and testing
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
the Web as an interface layer
Webservers can be used to interface with
• other webservers (proxies, rewriting proxies)
• FTP-servers, other Internet services
• databases
• mail servers, mailing lists
• any application
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
web-based user interface issues
• “standard” web user interface: formatted text +
images + hyperlinks + forms (special hyperlinks)
=>
URLs for input (+ some extras)
HTML for output
• (optionally) dynamic pages
(Javascript, Flash, Java applets)
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
WWW = URLs + HTTP + HTML
documents
URL
HTTP
scripts
HTML
webserver
web browser
web protocol
webserver
TCP/IP (Internet)
support
TCP/IP (Internet)
protocols
TCP/IP (Internet)
support
operating system
low-level protocol
operating system
computer
hardware
cables
computer
hardware
database
/ architecture of information systems
/ department of mathematics and computer science
another
webserver
TU/e
technische universiteit eindhoven
HTML != HTML
candidate document formats to send to the client:
• HTML (versions: 2.0 , 3.2 , 4.0 , 4.01, XHTML)
• CSS 1 , CSS 2
• Javascript
• plugins: Java applets, Flash,
Real/Quicktime/WMP
• non-embeddable: any other file format
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
HTML != HTML (2)
all web browsers have bugs, quirks, missing bits
and their own special features in their support of
• HTML
• CSS
• Javascript
• various image formats
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
webserver-side-specific development issues
Differences with “traditional” software applications:
client/server “ping pong”
=> need for session management
user interface is webpage based
• various access control / identification issues
• special issues with resource control
• issues with debugging and testing
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
resource control
overflow of resources
(CPU; memory; hard disk; network bandwidth)
•
set predefined limits on resource use
(if the software supports it)
•
automatic cleanup
•
manual checking / monitoring
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
debugging and testing
Options for testing:
• run program outside webserver environment
• use webserver facilities for debugging
• set up test webserver
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
webserver-side-specific development issues
Differences with “traditional” software applications:
client/server “ping pong”
=> need for session management
user interface is webpage based
• various access control / identification issues
special issues with resource control
issues with debugging and testing
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
access control
a.k.a security:
making sure someone/something can only use those
resources you want them to use
issues for the web:
• server-side authorization of client-side users
• client-side authorization of server-side providers
• securing the connection
• separating multiple users/services on the server
• separating multiple users on the client
• copyright
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
multiuser tic-tac-toe
r
p
rp's move
aux. files
rp's new position
webserver
pl's move
tic-tac-toe script
pl's new position
p
l
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
server-side authorization of client-side users
A service provider wants to identify a user. Why?
• personalization: remembering user preferences
• assigning legal responsibilities to the user
• purchase (Amazon)
• liability for use of services (e.g. in a chatbox)
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
server-side authorization of client-side users
A service provider wants to identify a user. How?
• by Internet host (unreliable)
• by something the user told you (not 100% reliable)
e.g. username/password
• by external identification (not 100% reliable)
e.g. credit card number; chip card
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
server-side authorization of client-side users
How does username/password identification work?
• “new user” screen: user selects name and possibly password
• if assigning liability demand external identification data (e.g. name home
address e-mail address)
• use it to send them some unguessable data (usually by sending e-mail with a
special sign-on URL)
• “confirm registration” screen: users enters unguessable data
• store user registration data on the server side
• “log in” screen: user enters data – server matches user and starts session
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
server-side authorization of client-side users
Username/password transmission technology:
• put user+password in URLs (very unsafe)
• web passwords (“basic authentication”)
(unsafe connection: eavesdropping on the network)
• https / SSL with password
(safe connection; public key cryptography)
• SSL without password (third party authority)
(e.g. “het elektronische paspoort”)
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
server-side authorization of client-side users
A service provider wants to identify a user. How?
How to use external verification?
• exchange external identification data on the web (e.g.
web-based payment) – data may be compromised so this
requires trust from both parties
• exchange data through another means (e.g. don’t offer
web-based payment) – cumbersome; requires trust in
alternative communication media
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
client-side authorization of server-side providers
A user wants to identify a service provider. How?
• provide external identification data (name;
address; phone; etc.)
• SSL without password (electronic identification
certificates via third-party authority)
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
securing the connection
The connection can be prevented from being
compromised (e.g. SSL).
The server can not prevent the client from being
compromised.
The client can not prevent the server from being
compromised.
You can have a safe pipe but the ends may leak.
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
separating multiple users/services on the client
Two users can use the same computer.
They have access to each other’s data.
e.g. TU/e electronic voting blooper
The server end cannot prevent this! The user is
responsible. The user must know this.
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
separating multiple users/services on the server
Two services can use the same webserver.
They must not have access to each other’s private
data.
-> security restrictions on server-side programs
The webserver provider is responsible. The service
provider / programmer must accept this.
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
copyright
A somewhat related issue: “users steal my content!”
• page content (once they have it they can spread it)
• software code (one reason for keeping it server-side)
Everything you put on the web is
• copyrighted
• easy for the user to steal
What to do:
• don’t place value on your copyrights / waive them)
• don’t publish anything for which this is impossible
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
access control
a.k.a. security:
issues for the web:
• server-side authorization of client-side users
• client-side authorization of server-side providers
• securing the connection
• separating multiple users on the client
• separating multiple users/services on the server
• copyright
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
whole documents vs. holes
server-side: how to generate the documents?
with a regular programming language:
code generates (headers+)content (usually through CGI)
“template” HTML languages:
document+ special tags
with program code (SSI, ASP, PHP, JSP, Template::Toolkit etc.)
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
programming languages and tools
• which programming languages to use?
• interpreted vs. compiled
• portability
• available libraries
• available frameworks
• prototype applications
• use HTML + hole technology?
• program / server interface?
• CGI
• server module with prog. language support
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
Web applications with Java servlets
Combinations of servlets and web pages
Common context: data and resources
• User authorization and registration
• Databases
• Hit counters
Initial application parameter
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
JAVA Web Application
Folder META-INF
• Manifest file
Folder WEB-INF
• Folder classes
• Folder lib (.jar files)
• File web.xml (configuration file)
Folder resources (data files)
JSP pages
Documents
Reinier
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
Servlet Context
A web application has one or more servlet
containers
A servlet container contains:
Initial parameters (fixed)
Attributes (dynamically created)
Servlet
as specified by the web application configuration
file
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
Context Management
Location & initial parameters of resources
(databases, external data)
Data to be shared between tasks of application
Miscellaneous data (encryption keys, etc.)
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
Context Management Objects
Initial parameters
• getInitParameterNames()
• getInitParameter()
Attribute objects
•
•
•
•
setAttribute()
getAttributeNames()
setAttribute()
removeAttribute()
Event listeners in attribute objects
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
Session & User Management
User IDs & passwords
Global session data (e.g. session ID, last contact
time)
Session state
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
Session & user management
Session:
• URLs
• Cookies
User:
• Cookies
• Databases: JDBC
demo code: sessiondemo.html
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
HttpSession Class
Session = client * web application * time frame
Life cycle management:
• getSession()
• Time out
• Invalidate()
Session state
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
HttpSession State
Attribute objects
• setAttribute()
• getAttributeNames()
• getAttribute()
• removeAttribute()
Session events
• Objects implement listeners
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
Listeners
Interface HttpSessionActivationListener
• sessionDidActivate()
• sessionWillPassivate()
Interface HttpSessionAttributeListener
• attributeAdded()
• attributeReplaced()
• attributeRemoved()
There are comparable interfaces for context attributes
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
Filters
Operate on requests and/or responses
May be chained
Configuration through config file
Uses e.g.:
• Authentication, Logging and Auditing
• Image conversion & data compression
• Encryption
Interfaces Filter, FilterChain & FilterConfig
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
Application Deployment
Configuration file: web.xml
Context:
• context root name
• context root path
• parameters
Servlets:
•
•
•
•
servlet name (alias path)
servlet class
URL pattern
initial parameters
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
How to use
Via URL:
http://server/webapp/servlet/pathinfo?nr=123
As server side include in HTML page:
<servlet code=“someServlet”>
<param name=“nr” value=“123”>
</servlet>
/ architecture of information systems
/ department of mathematics and computer science
TU/e
technische universiteit eindhoven
Assignment 2
Study the wild cards application.
Change the state management mechanism to use
cookies.
Use listeners to register user scores.
/ architecture of information systems
/ department of mathematics and computer science