Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
1.2.0
Version 1.2 has a few cosmetic changes: the tool item was removed by popular vote as the Help > Eclipse User Storage menu item was deemed sufficient; a stray separator was removed too.
Version 1.2 removes the login/password-based "session" authentication mechanism. Although this would normally be considered an API-breaking change, the Foundation's servers ceased supporting login/password in 2018. All known SDK consumers changed to use OAuth-based authentication in 2017.
Version 1.2 fixes some of its dependencies to pull in Apache HTTP Components using package imports instead of require-bundles.
Finally, the source code is now licensed under the Eclipse Public License 2.0.
The project leadership certifies that the APIs in this release are "Eclipse Quality".
UI relating to the login/password-based "session" authentication has been removed, though the underlying implementations should be simplified and refactored.
(Unchanged from 1.1)
Our approach exposes the OAuth Client Secret: To simplify the user experience, the USS SDK uses the Authorization Codegrant flow, where the OAuth client (the consumer of the USS SDK) provides a Client ID and Client Secret, rather than the Implicit flow which only requires the Client ID. The Authorization Code flow provides clients with a time-limited access token, a nonce that must be provided on each request, and a refresh token, which allows obtaining new access tokens. Clients using the Implicit flow only receive time-limited authorization tokens and do not receive a refresh token
The Authorization code flow is normally intended for server-style applications where the Client Secret can be kept secret. Eclipse plugins are more akin to mobile apps, as their compiled bytecodes are open to introspection to a determined attacker. But ultimately the implificit flow results in a poorer user exprience as the user must periodically re-affirm their authorization requests for the plugin to obtain a new access token (typically access tokens expire after an hour). For a mobile app, which is used periodically, but most Eclipse plugins will be long-lived.
As the USS is not suited to store private or confidential information, and user data is intended to be shared, the need for confidential client secrets is moot. And thanks to a contribution from Eike Stepper, and further improved by Carsten Reckord, we also provide a means to embed OAuth Client IDs and Secrets in a lightly-encrypted manner that can be committed to source repository. It adds a little bit of friction to an attempted crack.
(Unchanged from 1.1)
User documentation, primarily an Eclipse Wiki page, is admittedly sparse. The REST protocol is documented, but has not been published by the Eclipse Foundation.
OAuth authorization requires logging into the Eclipse Foundation web site, and is done through an internal web browser.
We receive occasional bug reports and fixes from our adopters, which now include a least one external project.
- Log in to post comments