Release 2.7.0

2.7.0 (September 20, 2019)

Email notifications, semantic version checking, bug fixes

What's New

• Email Notifications. OEMs may optionally enable real-time email notifications to be alerted when a new application version is ready for review on their SDL Server.
• Semantic Version Checking. If you happen to be running a pre-release version of SDL Server, the "About" page will no longer report that your SDL Server version is out-of-date.
• Bug Fixes. This release contains a critical bug fix to address some functional groups not being properly granted to applications based on their requested permissions.

If you have any questions about this release or about SDL Policy Server in general, please join us in the #sdl_server channel of our public Slack Organization.

Release 2.6.1

2.6.1 (May 1, 2019)

Hotfix

What's New

• App Auto-approval Confirmation Dialog. To clarify behavior of auto-approval, a new confirmation dialog will be shown when attempting to enable auto-approval for any application.

If you have any questions about this release or about SDL Policy Server in general, please join us in the #sdl_server channel of our public Slack Organization.

Release 2.6.0

2.6.0 (April 17, 2019)

App Services, Cloud & Embedded Apps, and more

What's New

• App Services. Apps may now request to be an App Service provider for Media, Weather, and/or Navigation purposes via the SDL Developer Portal. When an app requests to be an App Service provider, OEMs may choose which RPCs/events the application is allowed to receive through the application review process on their Policy Server. The configuration is then automatically reflected in generated policy tables.
• Cloud and Embedded Apps. App developers may now register their cloud/embedded applications on the SDL Developer Portal and define their websocket connection details. The connection details are cascaded to Policy Servers via webhooks, then automatically included in generated policy tables which are interpreted by SDL Core. Core then establishes a connection with the application's server (local or remote) at the appropriate time.
• Administrator Functional Groups. A new AdministratorGroup functional group has been added, containing RPCs for cloud app administration (and in the future, other admnistrative RPCs). By default, this group is not granted to any apps. To grant this functional group to an app, enable the Grant this app access to "Administrator" Functional Groups option on the application review page.
• Hybrid App Preference. Within the application review page, OEMs now have the ability to specify which platform group to prefer when an app attempts to connect to a head unit via two different platforms. This prevents duplicate apps from appearing on the head unit in scenarios where a driver has both the Android and Cloud versions of a particular app enabled, for example.

Miscellaneous

• Bug fixes

If you have any questions about this release or about SDL Policy Server in general, please join us in the #sdl_server channel of our public Slack Organization.

Release 2.5.0

2.5.0 (October 19, 2018)

Enhanced Webhooks, "About" tab, and more!

What's New

• "About" Tab. This new tab in the left-hand navigation reveals details about your SDL Policy Server's configuration. It's a simple way to see what version you're running, the webhook URL you should provide on the SDL Developer Portal, and whether or not various options are enabled such as SSL and caching. To learn more about the visual aspects of SDL Policy Server, please see the user interface documentation.
• Enhanced Webhooks. Now, when you approve or deny an application version in your SDL Policy Server, a webhook will be sent to the SDLC to track the application's state in a centralized location. In the future, this will allow the SDLC to provide third-party developers with a more seamless multi-OEM certification experience entirely from their dashboard on smartdevicelink.com. Additionally, webhooks now support administrative actions performed by the SDLC to ensure the prompt, automatic removal or blacklisting of problematic, malicious, or falsely registered applications.
• Blacklisted Applications Section. We've separated the applications you've blacklisted into their own "Blacklisted Applications" section on the "Applications" tab for improved organization. Now, each possible status of an application version has its own section.
• Auto-Approve New Applications. A new server configuration option has been added to the installation guide to allow all new applications received from SHAID to be automatically approved on the Policy Server. This option, when enabled, decreases the amount of ongoing effort required by OEMs to manage their Policy Server by trusting the SmartDeviceLink Consortium's app testing and validation process which all apps must pass prior to being distributed to Policy Servers.

What's Changed

• Start-up & Environment Variables. To better simplify the configuration and start-up process, we've deprecated the npm run start-pg-staging and npm run start-pg-production commands in favor of a new npm run start-server command. Related to this change, we also deprecated the STAGING_PG_* and PRODUCTION_PG_* environment variables in favor of a new, simpler DB_* structure. The old commands and environment variables will continue to work for SDL Policy Versions older than 3.0.0. For more information, please see the installation guide.

Miscellaneous

• Bug fixes

If you have any questions about this release or about SDL Policy Server in general, please join us in the #sdl_server channel of our public Slack Organization.

Hotfix for Policy Table Structure

2.4.2 (October 2, 2018)

Hotfix

What's New

• Policy Table Generation Hotfix. Parameter arrays in Functional Groups have been fixed to properly return an empty array in generated policy tables when parameters are available but none have been selected as part of the RPC/group. RequestType and RequestSubType properties have been added to each record in app_policies as required by SDL Core.

Hotfix for Short App IDs

2.4.1 (July 31, 2018)

Hotfix

What's New

• Short App IDs. Due to a discovery with head units currently in production being incapable of handling the length of full App IDs, the default behavior of the Policy Server has been updated to use "Short App IDs" (10 character, truncated, cleaned versions of full App ID). Instances of Core 5.0+ may indicate that the system supports full App IDs with the use of the full_app_id_supported: true key-value in the default Policy Table's module_config properties.

Caching, security, and more!

2.4.0 (May 24, 2018)

New features, improvements, and fixes!

What's New

• Optional policy table caching. We've added support for caching of the policy table using Redis to significantly increase the load capacity of a Policy Server. In a load test of 20 connections per second, we observed around a 10x performance improvement with caching enabled. Of course, performance will vary depending on your server/environment hardware, software, and network configuration. To learn how to enable caching, please see the installation documentation.
• Optional basic authentication. With this option, OEMs can configure a password to be required in order to access the administrative interface. Read more about enabling basic authentication here.
• Optional SSL certificate support. Read more about enabling SSL connections in the SDL Policy Server security documentation.
• Customizable pre_DataConsent and device Functional Groups. These Functional Groups can be used by OEMs to indicate permissions granted to a connected device both prior to the acceptance of any OEM-specific data consent terms (pre_DataConsent), and after (device).
• Application blacklisting. OEMs may now choose to ban all past, present, and future versions of an application by blacklisting it. To do this, we've added a Blacklist Application option in the status dropdown menu of Limited (Rejected) applications. See more about application states in the What's Changed section below.

What's Changed

• Application states. We've added and changed the names of application lifecycle states. When a new application (or a new version of an existing application) appears in your SDL Policy Server, it will be in a PENDING state. To move the application into the staging policy table, simply click Review, then change the application's state by clicking Test in Staging in the status dropdown menu. Then, if you wish to move the application version to your production policy table, just click Promote to Production from the state dropdown menu. At any time you may choose to reject an application version to revoke its requested access from both staging and production by clicking the Reject Application button in the state dropdown menu. When an application version is rejected, an option to Blacklist Application becomes available. Blacklisting an application prevents it from receiving any permissions and automatically rejects future versions of the application.
• Default Functional Group indicators. Default Functional Groups are now denoted with a "DEFAULT" label in the list view for improved discoverability.

Miscellaneous

• UI fixes for Firefox and Safari
• Bug fixes

As always, if you have any questions about this release or about SDL Policy Server in general, please join us in the #sdl_server channel of our public Slack Organization.

Bug Fixes and Documentation

2.3.3 (April 6, 2018)

Bug Fixes & Documentation

What's New

• Fixed how policy table is generated
• Changed some references to the policy server in the documentation

Bug Fixes & Cleanup

2.3.2 (April 4, 2018)

Bug Fixes & Cleanup

What's New

• Generalized default consumer messages and URLs
• Cleaned documentation references
• Minor bug fixes
• Policy table encryption/decryption passthrough functions

Policy Server UI and Administrative Enhancements (cont.)

2.3.0 (March 16, 2018)

Policy Server UI and Administrative Enhancements (cont.)

What's New

• Module Config UI
• Bug fixes
• SHAID app syncing auto-retry queue

Read more about this release at smartdevicelink.com.