v1.5.0

1.5.0 (2024-11-14)

Features

• Adds JSON Renderer for Globus Embeds (#262) (dfd7aa0)

Globus-embedded JSON files will now use a JSON tree view renderer. The JSON Renderer will be used automatically when the embedded file returns an application/json Content-Type.

v1.4.0

1.4.0 (2024-11-14)

Features

• Improves JSON rendering via react-json-view (#260) (59b6fc1)

The new render is used to render field definitions that resolve to JSON objects, the raw search result panel (pictured below), and error details.

v1.3.1

1.3.1 (2024-11-14)

Fixes

• Includes https://*.globusonline.org in default CSP (#258) (ebd5fe3)

v1.3.0

1.3.0 (2024-11-12)

Features

• Improves "globus.embed" behaviors (#253) (57a5a25)

Fixes

• Updates "globus.embed" fields to prompt for authorization when no session is found (#255) (bd25b05)

v1.2.0

1.2.0 (2024-11-08)

Embedding Globus-Sourced Assets

With this release, we've included a beta release of rendering Globus-sourced assets as a field on search and result pages.

If you have any issues or feedback related to this new feature, please feel free to open an issue!

Using "type": "globus.embed"

The derived value for the globus.embed field definition should be either:

• The Globus HTTPS Path, with options.collections¹ configured in the static.json file.
• Or, a compatible options object.

Using a property Lookup

In the example below, a preview_url property has been added to the search result – this property is the Globus HTTPS URL of the asset we want to display on the result.

By using the property configuration and a JSON path lookup, we can dynamically source the value from the result. Since we can't derive the Collection from this HTTPS URL, options.collection must also be configured in the field definition. This implementation works well if all of the content in your search index is hosted on the same collection.

// Result Excerpt
{
  "entries": [
    {
      "content": {
        "preview_url": "https://m-eef34f.fa5e.bd7c.data.globus.org/home/globus-shared-user/joebott/file-types/status-chunky-pause.svg"
      }
    }
  ]
}
// Field Definition
{
  "label": "Preview",
  "property": "entries[0].content.preview_url",
  "type": "globus.embed",
  "options": {
    // Providing the collection is REQUIRED to ensure proper authorization for the asset can be programmatically initiated.
    "collection": "996383e6-0c85-4339-a5ea-c3cd855c2692"
  }
}

When your assets are hosted across many collections, and/or you want more control on the options provided to the globus.embed field, an alternative is to use a JSON path lookup to an object. The provided object will then be passed as options. The example below demonstrates this.

// Result Excerpt
{
  "entries": [
    {
      "content": {
        "embed_preview": {
          "collection": "996383e6-0c85-4339-a5ea-c3cd855c2692",
          // When using this options method, you only need to supply the relative `path` to the asset, **not** the HTTPS URL.
          "path": "/home/globus-shared-user/joebott/file-types/status-chunky-pause.svg"
        }
      }
    }
  ]
}
// Field Definition
{
  "label": "Preview",
  "property": "entries[0].content.embed_preview",
  "type": "globus.embed"
}

Using a Hardcoded value

An asset can be "hardcoded" into a field by using value instead of property.

{
  "label": "Embedded Asset",
  "value": "https://m-eef34f.fa5e.bd7c.data.globus.org/home/globus-shared-user/joebott/file-types/status-chunky-pause.svg",
  "type": "globus.embed",
  "options": {
    "collection": "996383e6-0c85-4339-a5ea-c3cd855c2692"
  }
}

Supported Content Types

The default renderer will introspect the Content-Type returned by the asset and do its best to render the result to the screen for the user. Our initial implementation uses the <object> tag for embedding, content type support will be determined by the user's browser.

Plotly Support

We've also introduced the ability to render these Globus-sourced assets as a Plotly chart or graph using the Plotly JavaScript Open Source Graphing Library.

To use this functionality options.renderer should be set to plotly and the sourced asset should be a JSON object that is compatible with Plotly.newPlot single configuration object parameter.

{
  "label": "Plotly Chart",
  "value": "https://m-eef34f.fa5e.bd7c.data.globus.org/home/globus-shared-user/joebott/file-types/plotly/data.json",
  "type": "globus.embed",
  "options": {
    "collection": "996383e6-0c85-4339-a5ea-c3cd855c2692",
    "renderer": "plotly",
    "width": "985px",
    "height": "100%"
  }
}

1. This is currently required to ensure proper programatic authorization for the asset can occur. ↩

v1.1.0

1.1.0 (2024-11-01)

Features

• Adds support for features.requireAuthentication – this will update built-in routes to prompt for authentication before any information is displayed. This feature is useful for mostly/completely private Globus Search indicies. (abdd9cf)

Fixes

• OAuth: Ensures users are redirected back to the path they initiated a "Sign In" request from. (#236) (abdd9cf)

v1.0.0

1.0.0 (2024-11-01)

⚠ BREAKING CHANGES

The portal will now store authorization tokens in memory (previously localStorage) by default. This change underlines our commitment to providing a "secure by default" implementation.

How is In-Memory Storage More Secure?

When using our GitHub Template Repository to create a portal, your portal is automatically configured to deploy to GitHub Pages. Without a custom domain configuration, your application will be deployed to {username}.github.io/{repository-name}. Due to the same origin access policies of localStorage this means any application you¹ deploy to GitHub pages would have access to items placed in localStorage by the portal. We believe this default behavior is the less secure option and can lead to unexpected behavior based on your GitHub account usage.

Explaining the Breaking Change

With this new default, the end-user experience around authorization will change to requiring users to authenticate when the portal's browser window is closed. Due to the nature of this change we have flagged this change as a "breaking change", resulting in a major version bump. While we do believe most users should update without making changes to their static.json file, we have included the ability to opt-in to the previous behavior of storing authorization information in localStorage. Before enabling this functionality, we recommend being aware of security best practices related to localStorage, using a custom domain for your portal to better lock down origin access, or having policies in place to avoid unintended access when using the default GitHub Pages domain.

To opt out of this change, a new property in the static.json has been added to enable localStorage storage of authorization data (data.attributes.features.useLocalStorage).

{
  "_static": {
    "generator": {
      "name": "@globus/static-search-portal"
    }
  },
  "data": {
    "version": "1.0.0",
    "attributes": {
      "features": {
        "useLocalStorage": true
      }
    }
 }
}

Features

• Use in-memory based storage for authorization tokens, by default. (#235) (427d9e7)

Fixes

• Improves result rendering to account for 404s on hard refresh. (#233) (2dc2bbc)

1. localStorage is only available to applications on the same origin, which includes subdomain; Access is only shared with GitHub Pages applications or sites on the same account, not other GitHub account's deployments. ↩

v0.12.0

0.12.0 (2024-10-22)

Features

• Transfer: Adds stat integration for files added to the Transfer list. (#219) (e3d27f5)

v0.11.0

0.11.0 (2024-10-11)

Features

• Adds support for rendering fields a links. (#212) (889d966)
  Using "type": "link" will render a field value as a link in Result and ResultListing components.

{
  "label": "Documentation",
  "property": "entries[0].content.documentation",
  "type": "link"
},
{
  "label": "More Details",
  "value": "https://www.globus.org",
  "type": "link"
}

Supports absolute and relative links.

v0.10.1

0.10.1 (2024-10-10)

Fixes

• include basePath in publicRuntimeConfig (0e4585f)