I just committed a change to CVS HEAD where LazilyLoadedCtor objects
that Rhino itself creates in initStandardObjects() will execute their
buildValue() in an AccessController.doPrivileged() block. That way,
lazy loading of standard lazy-constructed objects will work regardless
of what are t
On Feb 19, 7:45 am, Attila Szegedi wrote:
> If this is the security exception you're getting, then I'd wager
> there's a bug somewhere in the weblogic.utils.classloaders.* code.
> Either that, or it is not a bug, but they don't anticipate code source
> URLs from outside the app directory...
If this is the security exception you're getting, then I'd wager
there's a bug somewhere in the weblogic.utils.classloaders.* code.
Either that, or it is not a bug, but they don't anticipate code source
URLs from outside the app directory... what happens if your script's
code source URL poi
That's not how Java security works. The requested permission must be
possessed by all code on the stack (otherwise, a less privileged code
could escalate its privileges by calling more trusted code). Another
way to say this is that the effective set of permissions at the point
of execution
On Feb 18, 6:40 am, Attila Szegedi wrote:
> Probably the app server places additional restrictions on code in
> applications. It might be possible that you'd need to grant some
> additional privileges to js.jar when it's in app directory (and then
> we might need to augment Rhino to use doPr
Probably the app server places additional restrictions on code in
applications. It might be possible that you'd need to grant some
additional privileges to js.jar when it's in app directory (and then
we might need to augment Rhino to use doPrivileged() in few places
after you identify those
I have some code similar to the following that is used to call js code
from java.
ContextFactory contextFactory = new ContextFactory();
Context context = contextFactory.enterContext();
context.setSecurityController( new PolicySecurityController() );
Scriptable scope = context.initS
