Page 183 - DCAP512_WAP_AND_WML
P. 183
Unit 12: Secure Application
The Web browser and server implement the Basic Authentication scheme below the application Notes
layer. To understand how this works, let’s look at the communication pattern between the
browser and sever. The Web server generates a response code for each HTTP request that it sees.
Often this response code is “OK”, however, when the request is for a page that is protected, the
response code tells the browser to challenge the user for his identity.
This identity challenge tells the browser, HTML or WML, to prompt the user for his username
and password. The browser then sends this information back to the Web server immediately
and the server attempts to verify the information. When the user supplies authentic information
to the challenge, the Web server responds with the “OK” and the originally requested page.
When the user fails to supply a valid combination of username and password, the Web server
responds with the response code “Forbidden” and does not send the page.
In order to implement the Basic Authentication facility, the Web server requires a user directory.
This user directory might be unique to your Web application or a shared corporate directory.
Directory services vary widely between Web servers; Microsoft IIS integrates natively with the
Microsoft Active Directory, while Netscape Enterprise Server uses Netscape Directory Server.
Once authentication is successful, each subsequent request from the browser to the Web server
includes the username and password of the user. The Web server then creates an application
variable for the Web application called REMOTE_USER containing the name of the user.
In addition to using a manual authentication structure or Basic Authentication, you may be able
to take advantage of platform-specific identification information.
Example: The WAP gateway that Phone.com delivers sends an HTTP variable that is
unique to the wireless device making the request. This variable is named HTTP_X_UP_SUBNO
and is tied directly to the device; the gateway constructs it from the wireless connection. You
may be able to take advantage of this server variable in your application.
12.3.2 WML for Secure Applications
When creating WML decks, you have a few techniques available to ensure that sensitive
information does not leave the secure communication channel between the user and your
application. You can protect your decks from attacking applications using the access element
and the sendreferer attribute of the goelement.
WML allows you to tell the browser to keep other applications from linking into decks within
your application. That is, WML provides you the access element in which you specify where the
linking deck must live in order to reference your deck successfully.
You can add the access element to the <head> tag of any deck. The absence of the <access> tag
allows any deck to reference that deck. When configuring the element, you should specify
the path and domain attributes. The domain attribute controls the set of Web servers that can
link into your application.
The path attribute restricts access within a domain in order to thwart cross- application linking.
It permits any decks in a more specific path access.
The sendreferer attribute of the go element is quite simple to use – it can only be set to true or
false. This attribute instructs the browser to send along the HTTP variable describing the deck
that makes a request, when it is set to true. You can then decide, in you application logic,
whether to permit the linking deck access by checking this variable. Unfortunately, the sendreferer
attribute defaults to the false value, suppressing this valuable information.
LOVELY PROFESSIONAL UNIVERSITY 177
