nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

'developer scripts' vs 'end user scripts'

mabayona

According to:

http://forums.alfresco.com/en/viewtopic.php?f=36&t=12587#p41591

specifically, pmonks says:

That said, I understand the problem and can't help wondering if explicit identification of "developer scripts" and "end user scripts" might help. "Developer scripts" would only be able to be created by developers and would have the ability to "runas" etc., while "end user scripts" could be created by anyone but would remain locked down within the current scripting security sandbox.

Interestingly enough, in 2.1.3 this distinction has already started appearing - Javascript scripts loaded from the classpath are trusted (ie. are "developer scripts") and have full access (via Rhino's native Java integration) to Java APIs (including the Foundation Services API), while Javascript scripts loaded from the repository are not trusted (ie. are "end user scripts") and run within the scripting security sandbox. The only missing piece here would be to expose a "runas" Javascript API that's only available to "developer scripts" (Alfresco's existing Java "runas" API is not readily usable from Javascript due to the use of callbacks).

Anybody knows if this is available in alfresco 3?

I´m trying to implement a "developer script" as an action to access the Java API from javascript and I seem unable to specify the javascript script to be loaded from the classpath without success.

My web-client-config-custom.xml looks like:

<config evaluator="node-type" condition="mymodel:mytype">
   <actions>

      <action id="do_something_interesting">
          <permissions>
            <permission allow="true">Write</permission>
          </permissions> 
          <label>Do something interesting</label>
          <image>/images/icons/edit_form.gif</image>
          <script>classpath:alfresco/extension/scripts/do_something_interesting_using_Java_API.js</script>
      </action>
      
       <!– Actions Menu for Create in Browse screen –>
       <action-group id="browse_create_menu">
         <action idref="do_something_interesting" />
       </action-group>

   </actions>
</config>‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

However, no matter what combination use for:

<script>classpath:alfresco/extension/scripts/do_something_interesting_using_Java_API.js</script>

I get an error message.

Any idea on how specify the <script>..</script> to be read from the classpath?

Find more posts tagged with

Comments

mabayona

I get following error message:

javax.faces.FacesException: org.alfresco.error.AlfrescoRuntimeException: Invalid store ref: Does not contain :// classpath:alfresco/extension/scripts
caused by:
org.apache.jasper.JasperException: org.alfresco.error.AlfrescoRuntimeException: Invalid store ref: Does not contain :// classpath:alfresco/extension/scripts
caused by:
org.alfresco.error.AlfrescoRuntimeException: Invalid store ref: Does not contain :// classpath:alfresco/extension/scripts‍‍‍‍‍

kevinr

RunAs can be applied to any WebScript deployed on the classpath (i.e. those considered secure). Added to the webscript descriptor:
http://wiki.alfresco.com/wiki/Web_Scripts#Creating_a_Description_Document

Also scripts considered secure (again, only those deployed directly on the classpath!) may access the native Java APIs also - however this is only recommended in advanced cases where the JavaScript API does not do what you need.
http://wiki.alfresco.com/wiki/3.2_JavaScript_API#Native_Java_API_Access

The secure script concept extends to "standard" javascript i.e. simple .js files executable from the JSF client action configuration - but it is not yet possible to execute full WebScripts from the JSF client action configuration. We will add the ability to launch a WebScript from a JSF action in the future, as per your requested enhancement: https://issues.alfresco.com/jira/browse/ALFCOM-3232

Thanks,

Kev

mabayona

How can we reference a "secure" javascript (i.e. in the classpath?) from JSF?.

As I mention in my post, it seems that:

<script>/….</script> can only reference scripts in the repository and NOT in the classpath.

am I missing something?

am I doing something wrong?

kevinr

You are correct yes, that is a simple change to add script classpath: support to JSF actions and i will get it added for 3.3.

Thanks,

Kev

fresch

Warning, long post ahead!

I'm sorry to resurrect this thread, but I've recently hit this "feature" and can't find any justification for this separation. At least not for "simple" scripts living in Company Home/Data Dictionary/Scripts. To provide some context, these are the requirements I've got to work with:

I'm working with an Alfresco 3.2r installation where I have "admin" access to Alfresco Explorer. I have access to the machine Alfresco is running on, but this is basically only for reading "alfresco.log". Restarting Alfresco server is not possible, nor practical. Storing scripts in Alfresco's classpath is not possible, because of access permissions, and again not practical. That only leaves me access to "Data Dictionary" where I can upload scripts, dynamic models, workflow definitions and such (since I have admin access to Alfresco Explorer).

Regular users will be using Alfresco Explorer to manage documents. Most users will only contribute (upload) documents, which will then be reviewed and sorted into appropriate spaces by assigned editors. Most users won't have write access to most of the spaces, they'll only be allowed to add content to a few "inbox" spaces. All users will have the ability to flag a document for review.

On adding content to such an "inbox" space, the members of the group with the "Coordinator" role assigned to this space are then notified.

Flagging a document for review will move the document into a "review" space and will again notify the members of the group with the "Coordinator" role assigned to the space.

These were initially implemented with JavaScript and executed via content rules. For the flagging, it was initially implemented as an action in "web-client-configuration-custom.xml" that also executed JavaScript.

However, this will not work. In both of these cases, the appropriate scripts are run with the permissions of the user that added the content or initiated the action. As described, no users except editors have write permissions, and this is requirement is paramount! Even if everybody were to be "Contributor" for the "review" space, it would solve the problem only partially, and thus not at all. The flagged document would not be able to be moved, since this would also require write permissions in its parent space.

In the end, it was solved by creating advanced workflows for each of these. In workflows, it is possible to define an action that executes JavaScript and run it as a different user (<runas>). Thankfully, it's possible to define a workflow with just three nodes: start task node, a plain node that contains an action with script, and end task node. Interestingly, it's possible to use "<import resource>" in the "<script>" definition, and thus possible to import scripts from the repository. This and the imported script is then run as the person defined in "<runas>".

Finally, the workflow definitions were deployed in "/Company Home/Data Dictionary/Workflow Definitions", the corresponding models in "/Company Home/Data Dictionary/Models", and the scripts in "/Company Home/Data Dictionary/Scripts".

This strikes me as extremely roundabout and ridiculously complex. And it also seems to defeat the "developer script" vs "end user script" distinction. Which seems shakey to begin with, how are these roles defined, who is this "developer", and who is this "end user"?

The Alfresco setup initializes permissions for "Data Dictionary" so that only members of the "ALFRESCO_ADMINISTRATORS" have write access, and everybody else only read access.

Who is then supposed to be the malicious "end user" that adds and executes a repository destroying script? This "end user" must have write access to "Data Dictionary" in order to do so! And to get write access this user must be in the "ALFRESCO_ADMINISTRATORS" group!

Surely the administrators will do some basic checking before allowing write access to "Data Dictionary"? And even if they didn't, how is this going to prevent an "end user" from doing what I did (write a workflow, define action with "<runas>", execute script in repository)? Besides, this is definitely a usage problem, not something Alfresco developers could ever hope to fix.

And lastly, if I have access to "Data Dictionary/Models" and "Data Dictionary/Workflow Definitions", where I can define a workflow that can execute some script in the repository as "admin", why even sandbox the execution of scripts in "Data Dictionary/Scripts"? Can it not be assumed that the person that placed the scripts in "Data Dictionary/Scripts" had sufficient permissions to do so, and it was probably a script performing some administrative tasks?

jamen

@Kevin

Has there been any update on this? I'm on 3.3 Enterprise and the issue with the invalid storeRef on a classpath located JavaScript still exists.