Database Reference
In-Depth Information
browser into believing the file is not XML. The following code fragment forces an
XML download:
response:stream-binary (
util:string-to-binary (
util:serialize ( <Hello/> , 'method=xml' ),
'UTF-8'
),
'application/octet-stream' ,
'download.xml'
)
• An XML fragment (here, simply <Hello/> ) is forced into a string via
util:serialize .
• This string is then forced into binary data via util:string-to-binary .
• This is passed to response:stream-binary with an Internet media type set to
application/octet-stream .
• A filename (in this example, download.xml ) is passed as the preferred filename
for storage (the user can change this).
As a result, the browser sees a binary response, which it cannot display. It therefore
asks the user where it should be stored.
Application Security
Unless you're creating a fully public website, your application will have to deal with
security. Such functionality may include creating and maintaining a user base, man‐
aging login and logout, and restricting access to parts of the application to certain
user groups.
The usual way to implement this for an eXist application is to concentrate the secu‐
rity checks in the central controller (see “URL Mapping Using URL Rewriting” on
page 194 ). The controller can check the user's identity, restrict access, map URLs to
different pages based on the user's credentials, and more. Because the controller han‐
dles it all, your other code can be relatively security-code-free and concentrate on
what it should be doing.
To make this all happen you need some kind of user/group administration system,
and you might be tempted to set up one of your own—just some XML file with users,
passwords, and additional information. There are several functions that take care of
this, allowing users to log in and storing the identity of the current user in the ses‐
sion. The application can work with this information when pages are requested to
allow or deny access.
Search WWH ::




Custom Search