customData not expanded about express-stormpath HOT 9 CLOSED

Hi @wrenoud

I can confirm what you're seeing. It's related to an issue with our Node SDK that we have to resolve w/ regards so how we cache entity expansions (see stormpath/stormpath-sdk-node#85)

In the meantime I think an acceptable workaround is to always call customData.get on the account object. The result of that call will be cached within the SDK so you won't be incurring a network request every time you call this method.

from express-stormpath.

Thanks @robertjd, I'll follow the discussion on the SDK issue.

from express-stormpath.

I haven't tested this since we've moved away from populating customData, but I believe this can be closed as it was addressed in 0.6.0 of the SDK.

from express-stormpath.

Thanks for the update. If you don't mind my asking, what solution did you find while custom data wasn't working correctly?

from express-stormpath.

Initially the solution I mentioned above is what we did, just always force expansion. We were creating a UUID, or are still rather, and trying to save that in the customData to "deserialize" the local user profile from our database. .

Recently we switched to using the email address for local lookup to clean up the process.

I was curious to ask about the id in the account href, I was hesitant to use it locally. Are other client using it?

from express-stormpath.

The identifier in the account href is globally unique, so it's totally safe to use that for lookups. This is the case for all Stormpath resources.

from express-stormpath.

Just a note: in the world of REST an href is the only 'id' that REST clients should be concerned with. HTTP allows redirects and changing of URLs, so the HREF is king (can be 302 redirected, etc). Relying on only an ID embedded in a URL is a foreign concept in REST and HTTP: HTTP browsers do not know how to parse URLs to discover IDs, and neither should REST clients. The href is the id as far as the client is concerned.

While stormpath internal IDs are guaranteed to be globally unique, from a REST perspective, that is an implementation detail. Because of HTTP redirection and potential URL changes over time, referencing an id only and then manually constructing the HREF based on that is a risky proposition, and could break client code in the future. HREFs are what allows the web to work in the face of change, and is also true for rest clients.

Because of this it is not recommended to parse internal/embedded IDs and use them for your own purposes. It is usually safer to generate your own ID and save that in the customData model, exactly as you have done :)

from express-stormpath.

Thanks @lhazlewood for the update! REST FTW

from express-stormpath.

Closing this issue as things seem to be resolved.

from express-stormpath.