IBM Tivoli Access Manager for e-business: WebSEAL Administration ...

adds
junction
information
to
the
path
of
URLs
contained
in
the
page,
the
actual
size
of
the
page
becomes
larger
than
indicated
in
the
Content-Header.
WebSEAL
has
no
way
of
knowing
what
the
new
content
length
is
until
it
actually
writes
the
stream
to
the
client.
At
this
point,
it
is
too
late
to
insert
a
new
Content-Length
header.
WebSEAL
responds
to
this
situation
in
the
following
manner:
1.
WebSEAL
places
the
value
of
the
original
Content-Length
header
in
a
new
header
called
X-Old-Content-Length.
Any
applets
or
applications
written
to
look
for
this
header
can
have
access
to
the
original
(pre-filtered)
Content-Length
value.
2.
WebSEAL
logs
the
modified
(post-filtered)
Content-Length
value
in
the
request.log
file.
3.
The
Content-Length
header
no
longer
appears.
Limitation
with
unfiltered
server-relative
links
WebSEAL
provides
solutions
for
processing
client-side,
script-generated,
server-relative
URLs
to
resources
on
back-end
junctioned
application
servers.
These
server-relative
URLs,
generated
on
the
client-side
by
applets
and
scripts,
initially
lack
knowledge
of
the
junction
point
in
the
path
expression.
During
a
client
request
for
a
resource,
WebSEAL
can
attempt
to
reprocess
a
server-relative
URL
using
junction
cookies
or
a
junction
mapping
table.
However,
before
the
processing
takes
place,
the
request
actually
specifies
a
resource
located
on
the
local
Web
space
of
the
WebSEAL
server
itself.
The
corrective
reprocessing
of
the
URL
occurs
only
after
WebSEAL
receives
the
request
and
performs
an
ACL
check.
An
ACL
check
on
this
unprocessed
request
(specifying
an
incorrect
or
nonexistent
local
resource)
could
result
in
an
error
that
stops
the
fulfillment
of
the
intended
request.
For
example,
the
following
sequence
takes
place
during
processing:
1.
The
client
makes
a
request
for
a
resource
using
a
client-side,
script-generated,
server-relative
URL.
2.
The
server-relative
URL
is
received
by
WebSEAL
as
a
request.
The
unprocessed
URL
specifies
a
resource
located
in
the
Web
space
of
the
WebSEAL
server
itself
(obviously,
this
is
not
the
intended
resource).
3.
WebSEAL
performs
an
ACL
check
on
this
local
resource
specified
in
the
request
URL.
v
If
the
ACL
check
fails,
all
processing
of
the
request
stops
and
the
client
receives
a
403
error
(Forbidden).
This
error
occurs
because
the
ACL
check
was
performed
for
the
incorrect
(and
probably
nonexistent)
resource.
v
If
the
ACL
check
succeeds
and
the
resource
exists
in
the
local
Web
space,
it
is
returned.
This
error
results
in
the
client
receiving
the
incorrect
resource.
v
If
the
ACL
check
succeeds
and
the
resource
does
not
exist
in
the
local
Web
space,
WebSEAL
modifies
the
request
URL
(using
the
junction
cookie
or
junction
mapping
table
method)
and
performs
an
internal
reprocessing
of
the
request.
This
behavior
is
correct.
4.
WebSEAL
performs
another
ACL
check
on
the
modified
URL
that
contains
the
corrected
path
that
includes
the
junction
point.
This
modified
URL
now
allows
an
ACL
check
for
the
correct
resource.
Workaround
Chapter
10.
WebSEAL
junctions
291