Open jenshaase opened 10 years ago
Hi Jens!
Your timing is amazing! :)
We just released the Stormpath SDK for Java 1.0.RC yesterday and it includes a huge new feature: The ability for the Stormpath SDK to secure your REST API using HTTP Basic or OAuth 2, both via API Keys.
The implementation caches the API Keys after the initial authentication to ensure that all subsequent REST requests are as fast as possible.
As for group caching however, we don't cache collections at the moment because - on average - they usually become invalidated very quickly and requests are always needed to obtain accurate views of the collections. That being said, we'll use this issue as a feature request for us to optimize this.
As a workaround, the best thing to do is probably to cache the results manually:
href
to a Collection<String>
.cacheManager.getCache("accountGroups");
Collection<String>
to a JSON object, e.g. groupHrefs
. It's best to store strings or raw/primitives in the cache to avoid type version conflicts if you upgrade the Java SDK later.cache.put(account.getHref(), groupHrefsCollectionAsJson);
Then, on login, when you receive the Account object, use the account's href
to lookup that cached collection JSON string and reverse the process. Once you have a Collection<String>
again, you can iterate over the href
s and call client.getResource(groupHref, Group.class)
. That call will check the cache first for the actual group data and then return a Group instance without 'hit'ting the server.
You will have to configure the accountGroups
cache with appropriate TTL/TTI values based on how long you want an account's groups collection to live before being re-acquired from the server to reflect fresh data.
I hope that helps! Please feel free to follow up with any questions. You'll also likely get faster support (on average) by sending questions to support @ stormpath.com. Cheers!
Here's our current API Authentication guide: http://docs.stormpath.com/guides/securing-your-api/
That may solve the problem. When will there be a release of of the Shiro plugin that is working with 1.0.RC?
Link expansion would also solve the problem. But it does not seems to work. I tried to override the getAccountHref
in ApplicationRealm
:
@Override
public String getAccountHref(PrincipalCollection principals) {
return super.getAccountHref(principals) + "?expand=groups,groupMemberships";
}
If I can use link expansion, it would be great. This will prevent me from changing my code to work with API Keys.
Thanks.
Now that 1.0.RC is out (and 1.0.RC2 is on its way), we're actively updating the stormpath-shiro plugin to reference the latest stable release.
We'll try to get this fixed as soon as we're able.
cc @antollinim
@jenshaase We just released stormpath-shiro 0.6.0 with a dependency on the Stormpath SDK for Java 1.0.RC2. It is available in Sonatype's OSS repository immediately, but may take a couple of hours to be visible in Maven Central. Please let us know if this helps!
Thanks, I will have a look.
Hi,
I tried to use the Cache to prevent repeating requests. However, in my implementation on each login attempt there is one request to the server. After reading the code, I recognized that collections requested are not cached: https://github.com/stormpath/stormpath-sdk-java/blob/stormpath-sdk-root-1.0.RC/impl/src/main/java/com/stormpath/sdk/impl/ds/DefaultDataStore.java#L587
I currently use HTTP Basic Auth for an REST-API. If I send lots of request to my REST-API the responses will be very slow. Here is what is happening:
Is there anything I can do, to cache the group request?
Cheers, Jens