AboutSupport
Docs

End-of-life notices

Suggest Edits

openfin-notifications npm package deprecated in favor of @openfin/workspace/notifications package

06-Oct-2023

OpenFin is replacing the openfin-notifications package with the @openfin/workspace/notifications package. We will continue to support openfin-notifications until July 2024.

The notifications.register() function in Workspace is also significantly changed. You now call this function to start Notification Center on users' desktops. In previous versions, Notification Center started automatically when you imported the openfin-notifications package.

Why is OpenFin making these changes?

The new approach lets you control when Notification Center starts on users' desktops.

When are these changes effective?

As of the publication of this notice, these changes are now in effect.

Who is affected by these changes?

Anyone who works with Notification Center.

We work with the openfin-notifications package now. What do we need to do?

You can continue to work with the old approach, but no updates will be made to openfin-notifications after July 2024.

We work with the @openfin/workspace/notifications package now. What do we need to do?

Be aware that the notifications.register() function now behaves differently. See the developer guide on registering notifications for more information.

@openfin/node-adapter npm package replaces openfin-adapter package

14-Sep-2023

OpenFin is updating its @openfin/core and openfin-adapter packages to simplify their usage contracts and improve the developer experience for our package consumers.

This initiative is being driven by significant improvements in our OpenFin type system, released in OpenFin 30. In OpenFin 30.110.74.8 (and its corresponding packages), we released improvements to ensure more accuracy, robustness and semantic types.

OpenFin is leveraging this opportunity to pair these improvements in our types with improvements in the way they are exposed and consumed in our public NPM packages.

When are these changes effective?

As of the publication of this notice, these changes are now in effect.

Who is most likely to be impacted by this change?

Consumers of the openfin-adapter npm package.
This package will remain available but will no longer receive further updates.

We leverage @openfin/core package today. What can be expected going forward?

@openfin/core

The @openfin/core package's structure now provides a single entry file format.
This means that there is a single JavaScript file included in the package, as opposed to the previous package structure, in which files are broken up into many common JS modules.

These changes allow for an improved API and type discoverability via code suggestion and type inspection, a reduction in the dependency size, and a clearer, more dependable usage contract for package consumers.

Impact to consumers of @openfin/core

Explicit imports from arbitrary files within the module directory ("@openfin/core/*") are no longer supported in new versions of @openfin/core. For example:

import { fin } from '@openfin/core/src/mock'; // no longer supported

However, until further notice, older versions of the @openfin/core package are future-proof with newer versions of the OpenFin Runtime.
Package consumers using the default entry point, as instructed in the usage guide, are unaffected by this change:

import OpenFin, { fin } from '@openfin/core'; // supported in old and newer versions

All current exports exposed via the @openfin/core main entry point are unaffected.

openfin-adapter

In order to clarify usage and improve discoverability, the openfin-adapter package is being replaced with the @openfin/node-adapter and @openfin/core packages.

Customers who consume the openfin-adapter package solely for the types should move over to the new @openfin/core package instead.

The openfin-adapter package is still compatible with newer OpenFin Runtime versions; however it will no longer receive further updates.

Both @openfin/node-adapter and @openfin/core have a single entry point. This means that all the functionality supported by this library will be easier to discover via code suggestion and type inspection.

Please note that arbitrary imports from within the included src folder are not supported in the replacement packages.
These single entry points improve discoverability and protect consumers of the package from internal changes to the structure of the package.

Migration Guides

If you use openfin-adapter to connect to OpenFin from a node.js or node-like environment, use @openfin/node-adapter instead. Please review the migration guide.

If you use openfin-adapter to get a type for the fin object, use @openfin/core instead.

OpenFin and Chromium ending support for Windows 7 and Windows 8/8.1

07-Mar-2023

Chromium is ending support for Windows 7 and 8/8.1 with Chrome 109. Starting with version 110, Chrome will no longer receive updates for the Windows 7 and 8/8.1 operating systems. This step is coupled with Electron’s decision to end support for these operating systems as well.

OpenFin version 30 is the first version of OpenFin to be built utilizing Chrome 110 and Electron 23. Consequently, OpenFin version 30 does not support Windows 7 and 8/8.1.

Why is support ending now for Windows 7 and 8/8.1?

Microsoft officially ended its free support for Windows 7 bug fixes and security updates in January 2020. Microsoft extended its ESU (Extended Security Updates) offering to January 2023 for customers unable to migrate to Windows 10 by the January 2020 timeframe.

How does this change affect OpenFin?

OpenFin software is built on Chromium and is dependent on the Chromium code base for security updates. With these changes, OpenFin will no longer be able to address any vulnerabilities that are discovered that relate to Chromium on Windows 7 and 8/8.1.

Who is affected?

Application providers are affected who distribute their OpenFin-based applications to end-user machines running Windows 7 and 8/8.1.

What do you need to do?

If you are an application providers who targets Windows 7 or 8/8.1 machines, you can continue to remain on OpenFin versions built on Chromium 109 and earlier; in other words, you can remain on OpenFin version 29 and earlier.

When is Chrome ending support for Windows 7 and 8/8.1?

Chrome 110, released in February 2023.

What is the last version of OpenFin that supports Windows 7 and 8/8.1?

OpenFin version 29, based on Chromium 108, released 30 January 2023.

Can applications remain on OpenFin version 29 while continuing to migrate to Windows 10?

Yes.

Please be advised that security features, enhancements and bug fixes from the Chromium, Electron and OpenFin teams will be applied only to future versions of OpenFin.

If you have questions about OpenFin’s Windows 7 and 8/8.1 support, please contact us at [email protected] and we can arrange a session to discuss these changes in greater detail.

Behavior Change for Secured APIs in OpenFin 24

31-Jan-2022

We are informing you of an upcoming behavior change to the Secured API defaults in our upcoming OpenFin 24 release, targeted for February 2022.

With targeted release OpenFin 24, OpenFin is further tightening our API Security stance by requiring Application Providers utilizing OpenFin 24 and a Secured API to also have RVM 6.5, or newer, on the end-user’s desktop. If an Application attempts to use a Secured API in OpenFin 24 and an RVM older than 6.5 is on the machine, the application’s attempt to use the Secured API will fail. Similarly, if an OpenFin runtime is attempted to be used directly without an RVM present then Secured APIs will not be available.

Why is OpenFin making this change?

Security is OpenFin’s top priority for both Application Providers and Desktop Owners. We work closely with IT Security teams to ensure OpenFin meets rigorous security standards. Through these collaborations we’ve collectively agreed to address a migration path for OpenFin’s APIs with a higher security profile.

OpenFin’s continued commitment to a security-first environment

At the direction of our customers' security teams, OpenFin first introduced API Security in July 2019 with OpenFin 12. With OpenFin 16 (May ‘20), and then again OpenFin 20 (June ‘21), we further tightened controls around Secured APIs while enabling customers an opportunity to plan and adapt to these changes.

OpenFin 24 is the next step in ensuring applications are Secure by Default.

Who is impacted?

Application Providers who upgrade to OpenFin 24 and leverage one or more of our Secured APIs (i.e. video, audio, launchExternalProcess).

My application is dependent on a Secured API, what do I need to do?

Application Providers wishing to upgrade to OpenFin 20+ (including OpenFin 24) and leveraging a Secured API continue to have the following options for their applications to access Secured APIs:

Desktop Owner Settings Management

Desktop Owners can manage an OpenFin DOS file to enable Secured API usage. See Desktop Owner Settings for further details.

End-user Click Thru

In the event neither a DOS file nor a Global Allow Listing has been established, OpenFin prompts the application end-user for authorization to use the Secured API (similar to “Ask before accessing” option in Chrome’s privacy and security settings).

Additionally, OpenFin 24+ will require that RVM 6.5+ is also present on the desktop when wishing to use a Secured API.

When are these changes being implemented?

OpenFin 24, March 2022

Can applications continue to use Secured APIs on older OpenFin versions?

Yes. Secured APIs will continue to work in OpenFin versions 19 and older until we have the larger OpenFin community ready to turn on backwards enforcement. You still need to declare Secured API usage in your application manifest, and Desktop Owners will continue to have the ability to prevent usage if they so choose by disabling those APIs across their desktops.

Please be advised that security features, enhancements and bug fixes from the Chromium, Electron and OpenFin teams will be applied to future versions of OpenFin.

Behavior Change in Workspace 4.0

17-Nov-2021

An upcoming behavior change to OpenFin Workspace will require necessary changes for Workspace customers to upgrade to 4.0. These behavior changes will impact how OpenFin Home retrieves its views, applications and workspaces.

With the release of Workspace 4.0, OpenFin is enhancing the mechanics for how Workspace customers retrieve their Workspace content. Today, this is accomplished via the Content Discovery Service, which will no longer be used directly by OpenFin Home in 4.0. Instead of OpenFin Workspace calling the Content Discovery Service, content will instead be supplied programmatically by a Workspace CLI Provider. We will be providing more details on the Workspace CLI Provider as part of our developer documentation with this release.

The intention of this notice is to ensure our customers are not negatively impacted by automatically consuming the 4.0 release. Customers can ensure they remain on a Workspace version < 4.0 by setting their Desktop Owner Settings file to a specific Workspace version.

Why is OpenFin making this change?

Previously, OpenFin Home made direct calls to the Content Discovery Service to retrieve app definitions. This approach has three limitations:

  • Significant complexity to share session cookies for the authenticated user

  • Some customers had difficulty configuring for CORS

  • Many customers want to provide app definitions per End User and to apply other business rules not supported by the Content Discovery Service.

The new approach solves these problems by delegating the search to your authenticated app via client-side APIs that are part of Workspace SDK. This eliminates the need to share session cookies as well as the need for CORS configuration. Additionally, your app can now apply all business rules as it performs the search for app definitions.

Who is impacted?

Workspace customers not setting a specific Workspace version in their Desktop Owner Settings file or any customer upgrading to Workspace 4.0+.

When is the Workspace CLI Provider being implemented?

Workspace 4.0: 24-Nov-2021

Will OpenFin provide details on how to migrate to Workspace Provider CLI?

Yes. OpenFin will provide developer documentation on how to migrate to the Workspace Provider CLI. Additionally, OpenFin intends to pair these developer docs with a reference implementation to assist with the transition. This reference will include a change to how Workspace is initiated.

Behavior change for secured APIs

09-Feb-2021

An upcoming behavior change to the security defaults in OpenFin 20 release, targeted for June 2021, may require changes to your configuration.

With targeted release OpenFin 20, we are further tightening our API security stance by changing from a “default allow” paired with a block list to a “default prevent” coupled with an allow list. Any Application using a Secured API need to be allowed in order to use the API. If an application attempts to use a secure API and that usage has not been allowed, the callback for the API returns an error.

Why is OpenFin making this change?

Security is OpenFin’s top priority for both Application Providers and Desktop Owners. We work closely with IT security teams to ensure OpenFin meets rigorous security standards. Through these collaborations we’ve collectively agreed to address a migration path for OpenFin’s APIs with a higher security profile.

OpenFin’s continued commitment to a security-first environment

OpenFin introduced its initial layer of API security in OpenFin 12, requiring Application Providers to declare usage of a secured API via its application manifest. The upfront affirmation assisted desktop owners by informing them of an application’s intent to use a secured API. Additionally, desktop owners have the ability to disable an application’s usage of an API via a permissions configuration in their DOS file.

In OpenFin 16, we tightened API security by adding sensitive web APIs to our secured API designation (audio, video, geolocation, etc.) and requiring applications to declare intent to use a sensitive web API in their application manifest as well as providing desktop owners the ability to manage an application’s usage of these APIs.

OpenFin 20 is the next step in enhancing application security.

Who is affected?

Application Providers who upgrade to OpenFin 20 and leverage one or more of our secured APIs (e.g., launchExternalProcess).

My application is dependent on a secured API. What do I need to do?

Application Providers wishing to upgrade to OpenFin 20 and leveraging a secure API have the following options:

Desktop owner settings management

End-user click-through

  • In the event neither a DOS file nor global allow listing has been established, OpenFin prompts the application end-user for authorization to use the secured API (similar to the “Ask before accessing” option in Chrome’s privacy and security settings).

Additional details on the specific changes in the Desktop Owner Secure API will be provided prior to the release.

When is enhanced security being implemented?

OpenFin 20, June 2021

Can applications continue to use secured APIs on older OpenFin versions?

Yes. Secured APIs will continue to work in OpenFin versions 19 and older until we have the larger OpenFin community ready to turn on backwards enforcement. You still need to declare secured API usage in your application manifest, and desktop owners will continue to have the ability to prevent usage if they so choose by disabling those APIs across their desktops.

Please be advised that security features, enhancements and bug fixes from the Chromium, Electron, and OpenFin teams will be applied to future versions of OpenFin.

Flash Support Ending

30-Sep-2020

This communication is to inform you of upcoming changes OpenFin is implementing for Flash.

Chromium is ending support for Flash in Chromium 88, due out in Jan 2021. As a result, OpenFin 18 (built on top of Chromium 87) is the last version of OpenFin on which Flash applications will be able to run. OpenFin 18 is targeting a delivery date of Nov 2020.

Please visit Chromium’s Flash Roadmap for additional information.

Who is impacted?

Application Providers running Flash content directly on OpenFin.

What if I am using just OpenFin’s Adobe Air Adapter?

Harman has taken over ownership of Adobe Air. The OpenFin Adobe Air Adapter is not impacted and should continue to work. This allows you to run Flex/Flash content in Adobe Air while connecting back into the rest of the OpenFin environment on the desktop. The OpenFin Air Adapter will not get further investment (no new API features, etc.) and we will work with you to make sure you have the right support.

What do you need to do?

Application Providers wishing to Upgrade to OpenFin 19 (Chromium 89) will need to take the necessary steps to migrate any Flash applications / dependencies out of their applications.

When is Flash support ending?

Chromium 88 - JAN 2021

What is the last version of OpenFin that will support Flash?

OpenFin 18 (Chromium 87) - Nov 2020

Can my applications remain on OpenFin 18 while migrating away from Flash?

Yes. Please be advised that security features, enhancements and bug fixes from the Chromium, Electron and OpenFin teams will be applied to future versions of OpenFin.

Layouts v1, FDC3, and Notifications APIs

18-Sep-2020

This notice is to inform you of changes OpenFin is implementing.

  • End-of-Life for the Layouts v1 API which has been replaced by the Platform API. The Platform API includes more advanced layouts capabilities and significantly improves on the Layouts v1 API.

    • Final Runtime Version supported is 15.80.50.34

    • End of Support Date is May 9, 2021

  • Change-of-Life-Cycle for our Notifications and FDC3 APIs which will no longer be managed as Services (the APIs will remain unchanged)

    • Service Life-Cycle for both APIs will no longer be supported as of March 1, 2021

  • Deprecation of fin.Notifications legacy API which is being replaced by the Notifications API.

    • Marked as Deprecated in Runtime Version 17.85.55.*

    • End of Support as of March 1, 2021

Who is impacted?

Application Providers leveraging any of the following OpenFin APIs:

Why are these changes happening?

These changes are being made in response to broad customer feedback. A summary of each is below. Please don’t hesitate to contact us if you’d like additional information.

Layouts

The Layouts v1 API has been replaced with our Platform API (previously known as Layouts API 2.0). This change is being made to:

  • Significantly improve performance and maintainability

  • Provide default tab support, customization, and complex layout support

  • Correctly integrate with standard Operating System functions such as Alt + Tab Preview, Move + Left/Right arrow keys, and z-order

FDC3

The FDC3 API now ships by default with the Runtime and does not need to be invoked as a Service. This has the following benefits:

  • FDC3 API is versioned in tandem with the other OpenFin APIs

  • Simplified app upgrade process: FDC3 API changes can be made and tested once as part of upgrading the Runtime version

  • Eliminates conflicts from different apps using different versions of the Service

  • Eliminates conflicts from compatibility issues between Runtime versions and Service versions

Notifications

The Notifications Center’s lifecycle will be managed by the Notifications API and will no longer need to be invoked as a Service as of version 1.0 which is scheduled for release in Q4 2020. This change is being made to:

  • Avoid visual collisions from multiple versions of Notification Center on the same desktop

  • Enable Desktop Owners to control the version of Notification Center for both internal and 3rd- party apps

fin.Notification

The fin.Notification API has been superseded by the Notification API. This change is being made to:

  • Significantly improve end user experience when more than one application is generating notifications

  • Provide visual consistency and customization across notifications

  • Keep notifications history available to end users

What do you need to do?

Application Providers should migrate as soon as possible. In all cases, we are here to help and assist teams with their migration plans.

Layouts v1 API

FDC3 API

  • Configure your Application Manifest to add the FDC3 API to your Application and remove the FDC3 Service from your Application Manifest as part of upgrading to OpenFin 17.85.55.* and beyond

Notifications API

  • Remove the Notifications Service declaration from your Application Manifest as part of migrating to a version of the OpenFin-Notifications NPM package that supports the new lifecycle management. (Version 1.0+, release date Q4 2020).

fin.Notification API

Can my applications continue to use OpenFin Services and fin.Notification API?

Yes — OpenFin strongly advises all customers to move to the respective alternative approaches as soon as practicable. If continuing to use the Services and the fin.Notification API, be advised that no patches will be applied for any discovered bugs and any Chromium Security patches must be consumed in later versions of OpenFin.

Updated 10 months ago