Apache OpenOffice (AOO) Bugzilla – Full Text Bug Listing
|Summary:||Interactive beanshell scripting menu needs tight binding|
|Status:||CLOSED FIXED||QA Contact:||issues <issues.openoffice.org>|
|Target Milestone:||OOo 2.0|
|Issue Type:||DEFECT||Latest Confirmation on:||---|
Description duncan.foster 2003-03-05 11:29:53 UTC
Set security permissions to "always" "show warning". open a doc containing scripts. Select the interactive beanshell scripting. Warning dialog for document is displayed. Workaround: tight binding for beanshell menu item. requires_documentation: need to document this behaviour as part of the security doc.
Comment 1 Unknown 2003-03-05 11:47:43 UTC
Assign to Tom: Workaround make the InteractiveBeanshell script have at least the location specified in addition to the logical name. Would not be an issue if on document open the permissions could be checked for the document.
Comment 2 tomaisoc 2003-03-05 12:13:53 UTC
Added location=user to the Interactive.BeanShell entry in all of the menubar.xml files.
Comment 3 Unknown 2003-03-06 09:53:23 UTC
Issue with Function Provider not being created on Doc New/ Open If interactive BeanShell script deployed to user area is run and the current docuemtn contains script and the security settings are set to warn the user about running macros from documents they will still get a security warning dialog, even thoough they are running the script from the user area. Problem is that in the Diaspatch call the Fucntion PRovider is being created, which results in a new storage beign created for the current document. It is this creation that triggers the security manager and causes the warnign dialogs to be presented to the user. Workaround until Function Provider is created on document open/ new is as follows: In Dispatch call check to see if location=document is specified on the scriptURI. IF NOT, then add the NODIALOG: string to the doc URI as it is passed into the Function Provider constructor. This will ensure that the security manager will only display the warnign dialgos if location=document. [Note: safer to check for location=document as this is setup by the IDE when deploying to the document - will result in correct behavior for unqualified scriptURI's i.e. just logical name specified, located in the user and share area]
Comment 4 Unknown 2003-03-06 09:54:22 UTC
Reassing to Noel to put in workaround
Comment 5 tomaisoc 2003-03-06 10:09:20 UTC
Just to clear up a point from Johns note, the IDE does not add thelocation=document string when deploying a script to a document. It just adds the script files and updates the manifest file. location=document only gets added if you create a binding which is done in the Assign dialogs. Don't know if this effects the workaround.
Comment 6 Unknown 2003-03-06 10:58:30 UTC
As Tom points out the IDE has nothing to do with setting up bindings. Anyway - there is no way to guarantee that a user couldn't setup a document menu binding without the location=document specified. Still using the current framework and Assign dialogs this will not normally happen - the user will need to manually edit the configuration files to make it happen. We should doc for the user how to setup document bindings, so they aren't tempted to go and hand edit the files. Setting up Document Bindings: Use the IDE to delpoy a script e.g. foobar.bsh to a document test .sxw Open up test.sxw in SO Open up Assign dialog - say Key binding Select document in location combo box Select document script and Assign key combo to it [will gernerate a scriptURI script://foobar.bsh?language=Java&function=foobar.bsh&location=document] Exit Assign dialog. Open Tools/Configure -> Key Tab Click on Save When prompted enter the document name test.sxw Say it's ok to overwrite You now have a key binding saved in the document to the script foobar.bsh and the location has been set to document so it will work with the above security issue workaround. requires_documentation
Comment 7 noel.power 2003-03-06 12:05:46 UTC
Fixed, workaround introduced ( will need removal when FunctionProvider is created by document )
Comment 8 robert.kinsella 2003-03-27 11:25:35 UTC
Comment 9 noel.power 2005-01-07 11:24:49 UTC
closed - no longer relevant, security not handled by scripting framework anymore, this code is removed