Grouper Developers Forum

[Tom Barton <>]

I advise us to not go down this path.

If there is a need for additional capabilities to be exposed in the WS 
interfaces, then we should provide them as bona fide methods. The 
approach you describe, although powerful, tightly couples WS clients 
with API version, undermining one of the values of using web services. 
It can make it harder for the group that operates the groups registry to 
upgrade since they might not know who is relying on this tightly coupled 
capability. And even if they do, an upgrade must be coordinated with all 
such clients.

Tom

Chris Hyzer wrote:
> Did we discuss this already?
>
>  
>
> How about this:
>
>  
>
> 1.       First of all this option would be default off, unless you are 
> an advanced user and turn it on
>
> 2.       We add 2 tables in the DB, which might get Grouper builtin 
> data, and custom entries for the institution:
>
>           GROUPER_GSH_WS_STATEMENTS
> ID: e.g. sdf6-sfd42-dsfer23-sfdsd23-234df
> NAME: e.g. memberRename
> STATEMENT: e.g.
>     grouperSession = GrouperSession.startRootSession();\n  
>     oldSubject = findSubject(?);\n
>
>     member = MemberFinder.findBySubject(grouperSession, oldSubject)");\n
>     newSubject = findSubject(?);\n
>
>     member.changeSubject(newSubject);\n
>
> PARAM_TYPES: e.g. STRING,STRING
>
>           GROUPER_GSH_GS_SECURITY
>
> STATEMENT_ID: e.g. sdf6-sfd42-dsfer23-sfdsd23-234df
> SUBJECT_ID: e.g. 8764563
> GROUP_ID: e.g. eirtyu-ersg-4235ef-sdf34
>
>  
>
> 3.       So we add a web service, where a user can pass the name of the 
> GSH statement to run (or batch up a bunch of them), and some params. 
>
> 4.       If that user is allowed to execute the statement, or if they 
> are in a group which is allowed to execute the statement, then the 
> params passed in are security escaped and substituted into the 
> statement, and the GSH is run. 
>
> 5.       The user gets the result of the GSH (either each line, or the 
> end-result of the last statement), and would know about any errors raised
>
> Basically we can open up the power of GSH (which is extremely powerful, 
> see the Java-BeanShell documentation, you can write methods, 
> conditionals, etc).  However, we are not executing scripts the web 
> service user uploads (the user doesn’t even see what script is 
> executing), those must be reviewed and placed in the table by the 
> administrator.  This includes reviewing them to make sure they cannot be 
> compromised (e.g. the question mark should not be in quotes for a string 
> param J ).  I think it could be fairly safe, and if you are wary, you 
> don’t have to enable it.  Im not exactly sure how returning data would 
> work, but we could do something like this:
>
>  
>
> GSH command: GrouperUtil.toXml(getMembers("penn:group"));
>
> Which would return:
>
> <set>
>
>   <member  id=”GrouperSystem” type=”application” source=”g:isa” 
> uuid=”2c05b28c-5b2a-46b5-865d-893937e7035f” />
>
>   <member id=”10021368” type=”person” source=”pennperson” 
> uuid=”f84d8d18-6148-48fe-99ee-ecbf8a166d4d” />
>
> </set>
>
>  
>
> I think it is an advantage that the script is stored in the Grouper DB… 
> if something changes with GSH, the grouper admin can update it when 
> updating grouper…  and knows which scripts to test when trying an 
> upgrade.  The upgrade problem is there for GSH or for normal web services…
>
>  
>
> Anyways, let me know what your thoughts are…
>
>  
>
> Chris

begin:vcard
fn:Tom Barton
n:Barton;Tom
org:University of Chicago;Networking Services & Information Technologies
email;internet:
title:Sr. Director for Integration
tel;work:+1 773 834 1700
version:2.1
end:vcard