R
Rade Todorovic
Our Web applications use a custom COM class serving as an "object
cache": it can consume an object (and return a random "ticket"), and
can later retrieve the object (assuming the "ticket" is provided). Any
instance of this class accesses a global cache of objects (on the
level of the in-proc server). The main reason is to allow different
Web pages to reuse the same objects, under condition that they can
communicate the "tickets" to each other (i.e. we don't want to
circumvent any security model inherent to IE).
We have noted that, if an object is put into the cache on one Web
page, and then retrieved on another, the "permission denied" exception
is thrown upon the first usage of the retrieved object on the second
page. This behavior has been detected with XP SP2 build 2026 (with
JScript code). The object being put is some custom COM object (not
related to the browser). Setting FEATURE_OBJECT_CACHING to zero in
Registry solves this problem. However, the same problem does not even
arise in XP SP2 build 2149 (i.e., our object caching normally works
and permission is not denied).
Any explanations? Also, what will be the behavior of the final SP2
release (like build 2026? like build 2149? something else?)?
cache": it can consume an object (and return a random "ticket"), and
can later retrieve the object (assuming the "ticket" is provided). Any
instance of this class accesses a global cache of objects (on the
level of the in-proc server). The main reason is to allow different
Web pages to reuse the same objects, under condition that they can
communicate the "tickets" to each other (i.e. we don't want to
circumvent any security model inherent to IE).
We have noted that, if an object is put into the cache on one Web
page, and then retrieved on another, the "permission denied" exception
is thrown upon the first usage of the retrieved object on the second
page. This behavior has been detected with XP SP2 build 2026 (with
JScript code). The object being put is some custom COM object (not
related to the browser). Setting FEATURE_OBJECT_CACHING to zero in
Registry solves this problem. However, the same problem does not even
arise in XP SP2 build 2149 (i.e., our object caching normally works
and permission is not denied).
Any explanations? Also, what will be the behavior of the final SP2
release (like build 2026? like build 2149? something else?)?