Issue 12060

Summary: Interactive beanshell scripting menu needs tight binding
Product: General Reporter: duncan.foster
Component: scriptingAssignee: noel.power
Status: CLOSED FIXED QA Contact: issues <issues.openoffice.org>
Severity: trivial    
Priority: P3 CC: issues
Version: 644   
Target Milestone: OOo 2.0   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation on: ---
Developer Difficulty: ---

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
marking verified
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