1. AMP: Audiovisual Metadata Platform
2. Documentation
3. For Developers

Galaxy Workflow Editor

Summary of most relevant knowledge learned so far regarding WF editor (via reading Galaxy documentation, code, and experimenting with various customizations):

1. First of all, the conclusion from POC: yes, our current approach is feasible. We have some sample code to demo that we can edit workflows via Galaxy UI from AMP, in a secure way.
2. How authentication works in Galaxy:
   1. We currently use the default authentication mechanism, i.e. via username/password validation against local Galaxy DB. (see https://docs.galaxyproject.org/en/release)
   2. Most pages involving data/workflow operation require login (including WF editor). User will be redirected to login page if no active session is in place.
   3. The login page is requested via /root/login, along with the response body containing the UI content, there is an "options" json string which contains csrf-session-token.
   4. Upon submission of login, request /user/login is sent, payload contains username/password etc, and the csrf-session-token.
   5. If login succeeds, Galaxy sets up the current user session, and sends a new cookie galaxysession to client
   6. Any request after this point will use the current galaxysession cookie to authenticate.
   7. Upon logout, client sends /user/logout request, Galaxy expires current user session, and sends back a new galaxysession cookie.
3. How routing works in Galaxy:
   1. Both client and API routes are set up upon initialization of GalaxyWebApp.
   2. Some routes are handled purely by client code, in which case the URLs are simply registered as client_route, to distinguish those handled by backend controllers.
   3. The mappings between above client routes and components are defined in various *Router.js files for ex, workflow creation, listing etc).
   4. Many other client side URLs however, are not explicitly added as client_routes, rather, they are mapped implicitly via naming convention. Workflow editor is one such.
   5. The above implicit routes are handled by backend controllers: the controller python script filename and method name map to the URL directly (/filename/methodName), and the controller generates the UI HTML through some template file mounted with the corresponding VueJS component.
4. How GalaxySession and WebApp work:
   1. During login process, the options json containing all basic config info of galaxy app is sent to the client, with which client initializes the galaxyInstance.
   2. Once logged in, GalaxySession is created on backend, and galaxysession is used as the key to look up the current user session.
   3. The user session contains info about the current connection and the current user,
   4. By default, session is kept alive, and galaxysession has a 90 day expiration period.
   5. Galaxy instance is stored in each UI window, and synched upon changes and shared by all UI components.
   6. Many pages are also generated via webhook, which provides a simple way of inserting icons, links, or other HTML elements into predefined locations. For this Galaxy provides some entry points which can be used to extend the client with content. This content can consists out of simple HTML, JS or dynamically generated content from a python function. (see https://docs.galaxyproject.org/en/release_21.05/admin/special#:~:text=Galaxy%20webhooks%20provides%20a%20simple,content%20from%20a%20python%20function.)
5. How Galaxy workflow editor works:
   1. The editor page is reachable by directly enter URL /workflow/editor?id=) in browser, or via edit menu, or redirected from creation page.
   2. A workflow must exist in the DB before being loaded into editor. That's why there is an extra screen to enter workflow name etc when creating a new workflow.
   3. Upon requesting the editor page, a bunch of requests are sent to backend, including
      1. /workflow/load_workflow?_=true&id=&version=: Get the latest Workflow for the StoredWorkflow identified by `id` and encode it as a json string that can be read by the workflow editor web interface.
      2. /api/workflows/4a674c401d642590/versions: retrieve the list of all versions of the workflow with the ID
      3. other API requests relating to datatypes and liccence etc
   4. The editor page has left, center, right panels. with
      1. left being tool box,
      2. right being action menus and properties,
      3. and middle being the canvas
   5. Operations on the canvas alone doesn't generate any API calls. It changes canvas status purely on client side.
   6. Operations on the toolbox such as adding a new tool, will fire requests (ex /workflows/build_module)
   7. Operations on the right side menu such as Save also fires requests (POST /api/workflows/4a674c401d642590 and /api/workflows/4a674c401d642590/versions)
6. Access control on workflows
   1. Workflows in Galaxy can be shared with users, groups, roles.
   2. However, there is no refined permissions on what operations can be done on a shared workflow.
   3. If we use some super-user in Galaxy to edit workflows from AMP side, it's hard to use Galaxy access control to achieve AMP access control goals. We'll have to rely on AMP side checking most likely before allowing Galaxy operations.
   4. And this can be achieved along with the Galaxy Proxy (AMP-1660) which will filter out unauthorized Galaxy operations during an AMP session.

Document generated by Confluence on Feb 25, 2025 10:39