Skip to content
This repository has been archived by the owner on Dec 12, 2018. It is now read-only.

Latest commit

 

History

History
905 lines (576 loc) · 45 KB

changelog.md

File metadata and controls

905 lines (576 loc) · 45 KB
Raw

Change Log

2.0.4-okta

  • fixed config issue breaking javadocs generation

2.0.3-okta

  • Updated to make all email sending operations async

2.0.2-okta

  • Use POST when updating Accounts and Custom Data to allow for partial updates
  • Include default Okta properties in web.stormpath.properties for the Servlet integration

2.0.1-okta

  • Added revoke refresh token on logout

2.0.0-okta

  • Always UID when sending verification email, to avoid cacheing issues

2.0.0-okta-rc3

  • Newly created Accounts can be automatically assocated with a given group, if property okta.application.groupId is set.
  • Basic auth calls were making multiple requests, which could cause a rate limiting error, they now correctly make only one
  • EmailService is now exposed as a Spring bean, as well as a new sendEmail method.

2.0.0-okta-rc2

  • Email templates can be loaded as a resource via a file: or classpath: prefix
  • Group HREFs are now fully qualified
  • Add subject, issuer, and issuedAt date to client credential JWT

2.0.0-okta-rc1

Okta specific release for teams migrating from Stormpath to Okta. The Spring, Spring-Boot, and Servlet integrations are now all using Okta APIs. Read more about it on the Okta GGetting Started Guide.

1.5.5

  • Refactored the /oauth/revoke endpoint to remove cookies

See 1.5.5 closed issues

1.5.4

  • Fixed a bug whereby Account with MCF password is not properly created via Directory when the RegistrationWorkflow is specified

1.5.3

  • Fixed a bug whereby Account with MCF password is not properly created via Directory
  • Fixed a bug whereby Factor.getMostRecentChallenge would materialize the wrong type

See 1.5.3 closed issues

1.5.2

  • Added static default page with Logout button for empty Spring Boot projects, such as those created by start.spring.io
  • Updated to Spring Boot 1.5.1 and removed workaround exclusions
  • Fixed runtime bug whereby exception was thrown when dealing with non-resource maps

See 1.5.2 closed issues

1.5.1

  • Removed unnecessary throws in AccountStoreVisitorAdapter

See 1.5.1 closed issues

1.5.0

  • Added passwordPolicy to registration json model to support Client API
  • Upgraded to Spring Boot 1.5.0 as well as upgrading a number of other dependencies to latest versions
  • Allow for configurable maxAge setting for access token and refresh token. Default is still based on OAuth Policy, but can be set to an explicit value
  • OAuth2 revocation support has been completed, a new /oauth/revoke endpoint has been added
  • Fixed issue where not all of our integrations could be disabled by means of stormpath.enabled = false (additionally, this property has more visibility in our documentation now)
  • Fixed issue where not all of our integrations were properly reacting to stormpath.spring.security.enabled = false
  • Added support for Pre/Post Login/Register handlers in IDSite
  • Now Spring Boot with Spring Security applications will start properly even if they lack a WebSecurityConfigurerAdapter configuration
  • Added support for the state token in grant_type=stormpath_factor_challenge requests
  • Fixed issue where IDSite and SAML callbacks were not performing to spec
  • Updated SAML IdP code to use forceAuthn property to determine if a user has to re-authenticate

See 1.5.0 closed issues

1.4.1

  • Fixed problem with HttpClient that caused cookies send by server to be stored and sent in every request.

See 1.4.1 closed issues

1.4.0

  • Refactored Google Authenticator MFA support to streamline and simplify
    • Fixed a Google Authenticator bug whereby it was not respecting the createChallenge setting on request
  • Fixed a bug whereby id_token was not being included in the DefaultTokenResponse
  • Fixed CORS support to play nice with spring boot starter parent

See 1.4.0 closed issues

1.3.1

See 1.3.1 closed issues

1.3.0

This release has a number of feature additions and bug fixes. Of note:

  • Added Documentation sections for Spring WebMVC and Zuul integrations
  • Updated Zuul integration forward a highly configurable authentication assertion
    • Can be raw JSON or a JWT
    • Can use a variety of signing algorithms, including HMAC, RSA and Elliptic Curve families
  • Put the Stormpath Spring Security Filter in front of the Stormpath Filter (critical fix for stability and future Spring Security work)
  • Upgraded to Spring Boot version 1.4.3
  • Upgraded to Spring Security 4.2.0
    • Enables the auto-loading of the StormpathWebSecuriytConfigurer for Spring Boot apps alleviating the need to use the .apply(stormpath()) pattern
  • Added a BOM (Bill of Materials) module enabling developers to include a single master dependency without having to specify a version for each stormpath module they want to use. Also enables Stormpath to be listed on start.spring.io
  • Added PUT to the default list of supported CORS methods
  • Added SAML idP (identity Provider) support to the SDK
  • Added Twitter Social support to the SDK
  • Added generic OAuth2 support to the SDK
    • This enables us to use nearly any external provider that supports OAuth2
  • Bug Fixes
    • Disabling Spring Security via properties was not working
    • Spring Security was making two authentication attempts

See 1.3.0 closed issues

1.2.5

See 1.2.5 closed issues

1.2.4

This release fixes a bug whereby an Account would be cached with UNVERIFIED status which would interfere with a user logging in when the Account Status had been updated on the backend.

See 1.2.4 closed bugs

1.2.3

This release fixes a bug whereby new passwords that violate the password policy were showing the wrong error on the forgot password flow.

See 1.2.3 closed bugs

1.2.2

This release fixes two bugs. Both are fixes to avoid RuntimeException when resolving external provider of an application.

See 1.2.2 closed bugs

1.2.1

This release fixes four bugs. We are adding one more supported grant_type to the AccessTokenController, also enhancing the signature validation of access/refresh tokens and improving error handing when required fields are missing in the token endpoint.

See 1.2.1 closed bugs

1.2.0

This release has a number of feature additions and bug fixes. Of note:

  • Support for Account Linking
  • Support for Application WebConfig - critical to interacting with the soon-to-be released Stormpath Client API
  • Support for OAuth2 revocation in the SDK as well as in all integrations exposed at the /oauth/revoke endpoont
  • Support for Cross Origin Resource Sharing (CORS) entirely by configuration in all integrations using these properties:
    • stormpath.web.cors.enabled
    • stormpath.web.cors.allowed.originUris
    • stormpath.web.cors.allowed.headers
    • stormpath.web.cors.allowed.methods
  • Idiomatic support for the passwordModifiedAt field in the Account interface in in search criteria on Accounts

See 1.2.0 closed issues for a complete list of changes.

1.1.7

See 1.1.7 closed issues

1.1.6

This release fixes a bug whereby an Account would be cached with UNVERIFIED status which would interfere with a user logging in when the Account Status had been updated on the backend.

See 1.1.6 closed bugs

1.1.5

This release fixes two bugs. The first is a fix for the LinkedIn Social login integration. Login with LinkedIn was failing under certain conditions. The second is a fix for enabling the confirmPassword form field.

See 1.1.5 closed issues for a complete list of changes.

1.1.4

This release has a bug fix for custom registration fields.

See 1.1.4 closed issues for a complete list of changes.

1.1.3

This release has a bug fix for Spring Security that was causing unnecessary API calls.

See 1.1.3 closed issues for a complete list of changes.

1.1.2

This release includes a fix for the next parameter when deployed at a non-root context and a change in the JSON structure of the /me endpoint (now returns groups.items instead of groups).

See 1.1.2 closed issues for a complete list of changes.

1.1.1

See 1.1.1 closed issues for a complete list of changes.

1.1.0

This release includes support for multi-factor authentication, Spring Cloud Zuul, a stormpath_social grant type for OAuth, and improved documentation.

See 1.1.0 closed issues for a complete list of changes.

1.0.3

Notes:

  • Please see the 1.0.3 issues list for more information

1.0.2

Notes:

  • Please see the 1.0.2 issues list for more information

1.0.1

Notes:

  • Please see the 1.0.1 issues list for more information

1.0.0

This release includes updates in the Core SDK and Servlet, Spring, Spring Boot and Spring Security integrations.

Specifically, the following major updates are included in this release:

  • SPA (Single Page Application) support across all integrations
  • Content Negotiation rules across all integrations to determine whether to return JSON or HTML responses
  • Social login and registration support for Google, Facebook, Linkedin and Github across all integrations
  • SAML Service Provider support across all integrations
  • Support for OAuth2 client_credentials grant type across all integrations
  • Support for Stormpath’s SSO service - ID Site - in the Servlet integration (ID Site is already supported in the other integrations)
  • Support for Pre and Post login and register handlers across all integrations
  • Support for custom fields on the Registration view across all integrations (non-standard fields are stored as Custom Data)
  • Added /me endpoint to return profile information for authenticated users across all integrations

Additionally, the following dependency and code updates are included in this release:

  • removed support for JDK 6
  • removed all code and docs for previously deprecated interfaces
  • upgraded all external dependencies to latest versions, including Spring Boot 1.4.0
  • Significant Spring Security performance improvements
  • Internationalization (i18n) support / improvements
  • A number of default properties have been added, changed or removed in conformance with the sdk spec and the framework spec. Details can be found in the Changes and Additions Guide.

Notes:

  • Please see the 1.0.0 issues list for more information

1.0.RC9.2

Notes:

  • Please see the 1.0.RC9.2 issues list for more information

1.0.RC9.1

Notes:

  • Please see the 1.0.RC9.1 issues list for more information

1.0.RC9

Notes:

  • Please see the 1.0.RC9 issues list for more information

1.0.RC8.6

Notes:

  • Please see the 1.0.RC8.6 issues list for more information

1.0.RC8.5

Notes:

  • Please see the 1.0.RC8.5 issues list for more information

1.0.RC8.4

Notes:

  • Please see the 1.0.RC8.4 issues list for more information

1.0.RC8.3

Notes:

  • Please see the 1.0.RC8.3 issues list for more information

1.0.RC8.2

Notes:

  • Please see the 1.0.RC8.2 issues list for more information

1.0.RC8.1

Notes:

  • Please see the 1.0.RC8.1 issues list for more information

1.0.RC8

Notes:

  • Please see the 1.0.RC8 issues list for more information

1.0.RC7.7

Notes:

  • Please see the 1.0.RC7.7 issues list for more information

1.0.RC7.6

Notes:

  • Please see the 1.0.RC7.6 issues list for more information
  • Note: 1.0.RC7.5 was not a viable release and was immediately replaced with 1.0.RC7.6

1.0.RC7.4

Notes:

  • Please see the 1.0.RC7.4 issues list for more information

1.0.RC7.3

Notes:

  • Please see the 1.0.RC7.3 issues list for more information

1.0.RC7.2

Notes:

  • Please see the 1.0.RC7.2 issues list for more information

1.0.RC7.1

Notes:

  • Please see the 1.0.RC7.1 issues list for more information

1.0.RC7

Notes:

  • Please see the 1.0.RC7 issues list for more information

1.0.RC6

Notes:

  • Please see the 1.0.RC6 issues list for more information

1.0.RC5.3

Notes:

  • Please see the 1.0.RC5.3 issues list for more information

1.0.RC5.2

Notes:

  • Please see the 1.0.RC5.2 issues list for more information

1.0.RC5.1

Notes:

  • Please see the 1.0.RC5.1 issues list for more information

1.0.RC5

Notes:

  • Please see the 1.0.RC5 issues list for more information

1.0.RC4.5

Notes:

  • Please see the 1.0.RC4.5 issues list for more information

1.0.RC4.4

Notes:

  • Please see the 1.0.RC4.4 issues list for more information

1.0.RC4.3

Notes:

  • Performance enhancements, bug fixes and collection iteration optimization.

  • The previous Spring Security support project now resides in this project codebase and will have the same versions of the Java SDK moving forward.

  • Please see the 1.0.RC4.3 issues list for more information.

1.0.RC4.2

This release adds the capability for the ID Site URL to be constructed following the base url obtained from the application href.

Please see the 1.0.RC4.2 issues list for more information.

1.0.RC4.1

This release adds ID Site functionality for Spring Web and Spring Boot applications.

Please see the 1.0.RC4.1 issues list for more information.

1.0.RC4

This release adds the following:

  • Spring and Spring Boot support!
  • Collection resources now report total size across the entire collection via aCollectionResource.getSize().
  • Ability for an Account to retrieve the Applications it may log in to
  • A Directory can now access its PasswordPolicy via directory.getPasswordPolicy().
  • various other bug fixes and enhancements.

Please see the full list of completed issues

1.0.RC3.1

This is a minor patch release that allows the Stormpath Servlet Plugin to work in Jetty and other servlet containers that do not support web fragment artifacts in /META-INF/resources/WEB-INF/classes.

Resolved Issues

  • Issue 136: Change i18n.properties file location.

1.0.RC3

This is a large interim release on our way to 1.0 final. It introduces substantial servlet container-based webapp support as well as a number of bug fixes and enhancements.

Resolved Issues

  • Issue 47: Fix for ResourceReference instances getting out of sync.
  • Issue 60: Fixed issue when trying to cache account verification responses.
  • Issue 62: Methods that return an Iterator for a Collection now return a new Iterator on every method call.
  • Issue 70: Issue preventing version.properties file to be properly read.
  • Issue 76: SSO/Logout Support and Result Listener for ID Site.
  • Issue 88: Servlet container webapp support
  • Issue 89: Added the ability to track integrations with the SDK by means of the User-Agent http header to aid in support/troubleshooting.
  • Issue 90: Fixed issue requiring a class from the impl module (ProviderAccountResultHelper) to be cached. The class has been removed altogether.
  • Issue 93: Custom Data for Application / Directory / Tenant
  • Issue 102: JavaDoc fix for Application AccountStores
  • Issue 103: We have added three convenience methods to simplify the addition of Account Stores: app.addAccountStore(String), app.addAccountStore(DirectoryCriteria) and app.addAccountStore(GroupCriteria).
  • Issue 106: Creating an account or group from a Directory now returns the created resource.
  • Issue 107: Added the ability to resend Account Verification Emails.
  • Issue 109: The Tenant Resource now provides operations for retrieving accounts and groups.
  • Issue 112: Fixed issue where Collection limits and offsets were being ignored.
  • Issue 117: Added support for Github OAuth.
  • Issue 119: Added support for LinkedIn OAuth.
  • Issue 121: Specify AccountStore when sending a password reset email
  • Issue 124: NullPointerException bug fix in HttpClientRequestExecutor
  • Issue 130: Connection timeout is now configurable (see Clients.builder().setConnectionTimeout(int))

1.0.RC2.1

This is a patch / bug-fix release that resolves a thread-safety issue in the data store that may impact some customers.

ID Site Logout Functionality

A user who has an open session with ID Site wanting to logout from it will add the forLogout() method when constructing the {@code callbackUri} using the IdSiteUrlBuilder. For example:

String callbackUri = application.newIdSiteUrlBuilder().setCallbackUri("http://localhost:8080/index.jsp").forLogout().build();
response.setHeader("Cache-Control", "no-store, no-cache, must-revalidate, post-check=0, pre-check=0");
response.setHeader("Pragma", "no-cache");
response.sendRedirect(callbackUri);

To execute this operation the application will create a signed request to the internal logout endpoint in Stormpath (i.e. /sso/logout). If successfully executed, the user will be redirected to the {@code callbackUri} indicating that the account has been properly logged out.

When users logs out, their session with the ID Site is no longer valid for every application pertaining to this domain. They will be required to log in again when trying to access any of those applications.

1.0.RC2.1

This is a patch / bug-fix release that resolves a thread-safety issue in the data store that may impact some customers.

1.0.RC2

Stormpath Java SDK 1.0 Release Candidate 2

ID Site Functionality!

This is one of the big features that we wanted to ensure was supported in the SDK before 1.0 final: your own hosted white-labeled Identity Site, what we call an 'ID Site'!

You can have a 100% customizable white-labeled site, for example, https://id.awesomeapp.com or https://my.awesomeapp.com, hosted and served securely by Stormpath. Your ID Site provides your end-users with a hosted and secure registration, login, and password reset functionality, and completely hands-off integration with Google and Facebook!.

Your white-labeled ID Site is beautiful and 'just works' out-of-the box and requires no development effort, but if you want to customize it in any way, you can easily fork our default GitHub repo and customize it as you desire, and we'll serve your fork securely just the same.

All that is required for this to work is that your application redirects your end-user to your secure ID Site URL and, when the user is done, can receive a redirect back to your application. This 1.0.RC2 release includes these two additional functions so you don't have to code that yourself.

See the Application interface's newIdSiteUrlBuilder method (for redirecting end-users to your ID Site) and the newIdSiteCallbackHandler method (for hanling the return reply from your ID Site) for code examples!

1.0.RC

  • Issue 52: Removed unnecessary Provider setters.
  • Issue 55: Account's password can now be reset along with the password reset token, in one API call.
  • Issue 56: Method chaining for Resources.

Stormpath Java SDK 1.0 Release Candidate

New Features & Enhancements

Secure your REST API using OAuth 2!

The Stormpath Java SDK can now act as an OAuth 2 Provider with full API Key management support!

You can now use the Java SDK to create and manage API Keys for your end-users so they can authenticate with your own REST API. You can create, delete, enable/disable as many API Keys as you want for each of your end-user Account resources. See the Account interface's createApiKey* and getApiKeys* methods.

Now for the really powerful stuff: the Stormpath Java SDK implements OAuth2 provider functionality. Your end-users can use these API Keys to make OAuth 2 requests to your REST API, and the Stormpath Java SDK will authenticate the requests via OAuth as you wish. This includes both OAuth 2 access token requests (e.g. the /oauth/token endpoint) as well as resource requests (e.g. /movies/1234). At no point do you ever need to see, touch, or write OAuth code! The Stormpath SDK does it for you.

See the Application interface's authenticateApiRequest and authenticateOAuthRequest methods for lots of detailed information.

Resource method chaining

All resource mutator methods can now be chained for less verbose object construction. For example, instead of:

Account account = client.instantiate(Account.class);
account.setGivenName("John");
account.setGivenName("Smith");
account.setEmail("jsmith@gmail.com");
account.save();

one might choose to write instead:

client.instantiate(Account.class)
  .setGivenName("John").setSurname("Smith").setEmail("jsmith@gmail.com").save();
Client Tenant Actions

The Client and Tenant interfaces now both extend a new TenantActions interface that represents common tenant behavior. This allows you to perform this common tenant behavior directly via a Client instance without having to call the intermediate client.getCurrentTenant() method first.

For example, instead of:

client.getCurrentTenant().createApplication(anApp);

you may now write:

client.createApplication(anApp);

which is likely more intuitive.

Password Reset Cleanup

Resetting an end-user's password via password reset token can now be done in a single method call. Just provide the reset token and the new password, and that's it.

Resolved Issues

  • Issue 46: Application#setDefault*StoreMapping IT failure
  • Issue 48: OAuth provider support with API Key management!
  • Issue 52: Removed unnecessary Provider setters
  • Issue 54: AuthenticationResult must not extend Resource
  • Issue 55: Account's password can now be reset along with the password reset token, in one API call
  • Issue 56: Method chaining for Resources.
  • Issue 58: Allow a Client instance to directly perform common Tenant actions.

1.0.beta

  • Added Provider integration: Google and Facebook are supported.

Backwards Incompatible Changes

This beta release contains a few backwards-incompatible changes, we strive to keep them minimal.

  • ClientBuilder was previously in charge of constructing the ApiKey. Now, the ApiKey is built through a new ApiKeyBuilder interface which can be instantiated via the new com.stormpath.sdk.client.ApiKeys utility class. ApiKeyBuilder provides a nice fluent builder API. Once the ApiKey is built, it can be set to the Client by means of the ClientBuilder instance.

1.0.alpha

  • Added the possibility to specify AccountStore during authentication.
  • Issue 36: Client version is now being obtained from version.properties file

Backwards Incompatible Changes

This is a prep release for the 1.0 final release, and we are finalizing the 1.0 API. As a result, this alpha release contains a few backwards-incompatible changes, but we have tried to keep them a minimum. As we have tried very hard to do during 0.x, 1.x will continue to enforce semantic versioning practices so there are little surprises.

  • Client and ClientBuilder were previously concrete classes - they are now interfaces. A com.stormpath.sdk.client.Clients utility class has been added with utility methods for creating clients, providing a nice fluent builder API. This retains a creation/builder pattern in use across the rest of the client API.

0.9.3

  • Issue 16: Allow client to use basic authentication
  • Backwards-incompatible change: com.stormpath.sdk.impl.http.support.SignatureException has been replaced by com.stormpath.sdk.impl.http.support.RequestAuthenticationException
  • New method for Account: isMemberOfGroup(String hrefOrName)

0.9.2

This is a bugfix point release that resolves 3 issues:

  • Issue 30: Custom data updates are not cached when calling account/group save()
  • Issue 28: ResourceException getMessage() should return a more descriptive message
  • Issue 31: Provide more detailed ResourceException messages (duplicate of Issue #28).

0.9.1

This is a bugfix point release that resolves 1 issue:

  • Issue 25: account.addGroup and group.addAccount do not work

0.9.0

This is a milestone / new feature release.

Custom Data!

Our most requested feature is now available via the Stormpath Java SDK!

You now have the ability to create, update, delete up to 10 Megabytes of your own custom data per Account or Group stored within Stormpath. This is a big deal: any account or group information that you can think of specific to your application(s) can now be stored directly with the account or group. This allows you to completely remove user tables within your application if you desire.

Read the Custom Data announcement and the Custom Data REST API documentation for more information and how to safely use Custom Data in your own applications.

Custom Data is a SDK Resource: you can save, update and delete it like any other. But it is also a java.util.Map<String,Object> implementation:

CustomData data = account.getCustomData();
data.put("favoriteColor", "blue");
data.remove("favoriteHobby");
data.save();

Because CustomData extends Map<String,Object>, you can store whatever data you want, but NOTE:

The data MUST be JSON-compatible. This means you can store primitives, and Maps, Arrays, Collections, nested as deep as you like. Ensure the objects you persist can be marshalled to/from JSON via Jackson (what the Stormpath Java SDK uses for JSON marshalling). Also a single Custom Data resource must be less than 10 Megabytes in size.

Persistance by Reachabliity

Custom Data is a resource like any other - you can save() modifications and delete() it if you like. But, because it it has a 1-to-1 correlation with an owning Account or Group, it is a little extra special: you can also save, update and delete Custom Data just by saving the owning account or group.

For example, let's say you wanted to create a Starfleet account for Captain Jean-Luc Picard. Because Stormpath has no knowledge of Star Trek-specific needs, we can store this in the account's Custom Data resource:

Application application = getApplication(); //obtain the app instance however you wish

Account account = client.instantiate(Account.class);
account.setGivenName("Jean-Luc");
account.setSurname("Picard");
account.setEmail("captain@starfleet.com");
account.setPassword("Changeme1!");

//let's store some application-specific data:
CustomData data = account.getCustomData();
data.put("rank", "Captain");
data.put("birthDate", "2305-07-13");
data.put("birthPlace", "La Barre, France");
data.put("favoriteDrink", "Earl Grey tea (hot)");

application.createAccount(account);

Notice how we did not call data.save() - creating the account (or updating it later via save()) will automatically persist the account's customData resource. The account 'knows' that the custom data resource has been changed and it will propogate those changes automatically when you persist the account.

Groups work the same way - you can save a group and it's custom data resource will be saved as well.

NOTE: Just remember, if you have any secure data or information you don't want searchable, ensure you encrypt it before saving it in an account or group's custom data resource. Read the Custom Data announcement for usage guidelines.

Create Accounts via an Application

As a convenience, you may now create account and group resources directly via an application, without first needing to obtain the intermediate directory or group where they will be persisted:

Application application = getApplication(); //obtain the app instance however you wish

Account account = client.instantiate(Account.class);
account.setGivenName("John");
account.setSurname("Smith");
account.setEmail("john@smith.com");
account.setPassword("Changeme1!");

application.createAccount(account);

You can also use the CreateAccountRequest concept to control other account creation directives. For example, using the Fluent API:

import static com.stormpath.sdk.account.Accounts.*;

...

account = application.createAccount(newCreateRequestFor(account).setRegistrationWorkflowEnabled(true).build());

Again, this is a convenience: The account will be routed to (and created in) the application's designated default account store, or throw an error if there is no designated account store.

Because accounts are not 'owned' by applications (they are 'owned' by a directory), this will not make application 'private' accounts - it is merely a convenience mechanism to reduce the amount of work to create an account that may use a particular application.

Create Groups via an Application

Similar to accounts, as a convenience, you may create group resources directly via an application without first needing to obtain the intermediate directory where the group will be persisted:

Application application = getApplication(); //obtain the app instance however you wish

Group group = client.instantiate(Group.class);
group.setName("Directory-unique name here");

application.createGroup(group);

You can also use the CreateGroupRequest variant to control other group creation directives. For example, using the fluent API:

import static com.stormpath.sdk.group.Groups.*;

...

group = application.createGroup(newCreateRequestFor(group).withResponseOptions(options().withCustomData()).build());

Remember, this is a convenience: The group will be routed to (and created in) the application's designated default group store, or throw an error if there is no designated group store.

Because groups are not 'owned' by applications (they are 'owned' by a directory), this will not make application 'private' groups - it is merely a convenience mechanism to reduce the amount of work to create a group accessible to a particular application.

Create Cloud Directories

You may now create and delete 'Cloud' (natively hosted) directories in Stormpath with the Stormpath Java SDK. LDAP and Active Directory 'Mirrored' directories must still be created in the Stormpath Admin Console UI. For example:

Directory dir = client.instantiate(Directory.class);
dir.setName("My new 'cloud' Directory");

dir = client.getCurrentTenant().createDirectory(dir);

...
//delete it when no longer useful
dir.delete();

Manage Account Store Mappings

Account Store Mappings are useful in more advanced usages of Stormpath, for example, if you have more than one directory (or group) to assign to an application to create a merged user base for the application.

The Java SDK now allows you to add, remove, re-order and generally manage an Application's account store mappings for these more advanced use cases. See the JavaDoc for the AccountStoreMapping resource and the following Application methods:

AccountStoreMappingList getAccountStoreMappings();
AccountStoreMappingList getAccountStoreMappings(Map<String, Object> queryParams);
AccountStoreMappingList getAccountStoreMappings(AccountStoreMappingCriteria criteria);
AccountStore getDefaultAccountStore();
void setDefaultAccountStore(AccountStore accountStore);
AccountStore getDefaultGroupStore();
void setDefaultGroupStore(AccountStore accountStore);
AccountStoreMapping createAccountStoreMapping(AccountStoreMapping mapping) throws ResourceException;
AccountStoreMapping addAccountStore(AccountStore accountStore) throws ResourceException;

0.8.1

This is a bugfix point release that resolves 1 issue:

  • Issue #12 application.authenticateAccount fails if caching is enabled

0.8.0

Bug Fixes

Collection Iteration (transparent pagination)

Collection Resource iteration previously only represented the first page in a collection. Iteration now transparently iterates over the entire collection, automatically requesting new pages from the server as necessary. For example:

AccountList accounts = application.getAccounts();

//iterate over the entire account collection:
for (Account account : accounts) {
    //do something with the account
}

New Features and Improvements

Caching

The SDK now has full caching support, utilizing a CacheManager interface (that produces/manages Cache instances). If enabled, this improves performance by reducing round-trips to the Stormpath API servers.

An out-of-the-box production-grade CacheManager implementation - complete with default and per-region TTL/TTI configuration - may be configured for single-JVM applications. Single-JVM app example config:

import static com.stormpath.sdk.cache.Caches.*;
...

Client client = Clients.builder()
    .setApiKey(ApiKeys.builder()
        .setFileLocation(System.getProperty("user.home") + "/.stormpath/apiKey.properties")
        .build()
    )
    .setCacheManager(newCacheManager()
        .withDefaultTimeToLive(1, TimeUnit.DAYS) //general default
        .withDefaultTimeToIdle(2, TimeUnit.HOURS) //general default
        .withCache(forResource(Account.class) //Account-specific cache settings
            .withTimeToLive(1, TimeUnit.HOURS)
            .withTimeToIdle(30, TimeUnit.MINUTES))
        .withCache(forResource(Group.class) //Group-specific cache settings
            .withTimeToLive(2, TimeUnit.HOURS))
        .build() //build the CacheManager
    )
    .build(); //build the Client

Multi-JVM applications (an application deployed across multiple JVMs) would likely want to use a distributed/clustered coherent Cache product like Hazelcast, Ehcache+TerraCotta, Oracle Coherence, Gigaspaces, etc. To leverage these caching products, you must implement the two interfaces (CacheManager and Cache) to delegate to your Caching provider API of choice, and you're on your way. For example:

CacheManager cacheManager = new CacheManagerImplementationThatUsesMyPreferredCachingProduct();
Client client = Clients.builder()
    .setApiKey(ApiKeys.builder()
        .setFileLocation(System.getProperty("user.home") + "/.stormpath/apiKey.properties")
        .build()
    )
    .setCacheManager(cacheManager);
    .build();

In both cases, the Stormpath Java SDK will store resource data in separate cache regions. Each region is named after a resource interface for which it caches data, e.g. "com.stormpath.sdk.account.Account", allowing for custom caching rules per resource type. This gives you finer control of resource caching behavior based on your preferences/needs.

Query Support

Two new query mechanisms were introduced - you choose which you want to use based on your preference and/or JVM language.

  1. Fluent and type-safe query DSL: If you're using a type-safe language, you will find this convenient, especially when using an IDE that auto-completes. You'll find writing valid queries fast! For example: 
    import static com.stormpath.sdk.account.Accounts.*;
...

application.getAccounts(where(
    surname().containsIgnoreCase("Smith"))
    .and(givenName().eqIgnoreCase("John"))
    .orderBySurname().descending()
    .withGroups(10, 10) //eager fetching
    .offsetBy(20).limitTo(25)); //pagination
  2. Map-based query methods. These are not type safe, but might be desirable for some developers, maybe those using dynamically typed languages. The map key/value pairs are simply REST API query parameters and values. For example, the same results of the above fluent query could be achieved as follows in Groovy: 
    application.getAccounts [surname: '*Smith*', givenName: 'John',
                         orderBy: 'surname desc', expand: 'groups(offset:10,limit:10)'
                         offset: 20, limit: 25]
JavaDoc Enhancements

JavaDoc has been improved significantly. But please don't hesitate to send us a Pull Request with fixes or enhancements!

0.6.0

AbstractResource

  • Added setProperty(String name, Object value, final boolean dirty) method.
  • Refactored setProperty(name, value) to delegate to this new method.
  • Refactored getResourceProperty entirely to support silent swapping links to materialized Resource instances.

AbstractResourceCollection

  • Refactored getCurrentPage() implementation to silently swap materialized collection with existing property (Change starts on line 72 and goes to line 84). This refactoring calls the new AbstractResource.setProperty(name, value, false) method.

DefaultDataStore

  • Added toSimpleReference(String propName, Resource resource)
  • Updated toMap method implementation to use new toSimpleReference call (new else if statement on line 186)