Examples: query, "exact match", wildcard*, wild?ard, wild*rd
Fuzzy search: cake~ (finds cakes, bake)
Term boost: "red velvet"^4, chocolate^2
Field grouping: tags:(+work -"fun-stuff")
Escape special characters +-&|!(){}[]^"~*?:\ - e.g. \+ \* \!
Range search: properties.timestamp:[1587729413488 TO *] (inclusive), properties.title:{A TO Z}(excluding A and Z)
Combinations: chocolate AND vanilla, chocolate OR vanilla, (chocolate OR vanilla) NOT "vanilla pudding"
Field search: properties.title:"The Title" AND text
 
Answered
Get User Info from Online Session Id

We are working through the 'SP Initiated SSO Approximation' example from https://docs.q2developer.com/guides/frontend_development/sso.html. We have the request going to our AWS Coginto instance and the SAML request is coming back to a Q2 Ardent extension. We have the self.online_session.client_session_id being passed along in a cookie along with a one-time use token for security. In the Ardent extension, how can we now go about getting the user information from the client_session_id in order to build out the SAML assertion?

Posted 4 years ago
Votes Newest

Answers


While it is possible to get user information from the session id. I would reccommend passing user_id instead and then using the User DbObject: https://docs.q2developer.com/api_references/q2_sdk/db/db_objects/user.html

Posted 4 years ago
Trey Teter
124 × 2 Administrator
0

Thanks Trey - so instead of storing the session id in memcache like the diagram suggests, we should stored the user id instead? I can see how that makes it easier and since the user id doesn't get passed outside the q2 environment (via cookie) then no security concerns. We'll give it a try!

— Chris Janes   4 years ago
0

There is reason to store the session to make sure the session hasn't expired or isn't a new session. I think that is the reason we did session_id in the docs. Since you seem to have your own token for security it makes sense to just pass the user_id instead. You can always pass both along.

— Trey Teter   4 years ago
0

We've have successfully stored the user_id in Q2 cache under a one time use token, set the token in the cookie and then looked up the user using the token when we get the response back from our Congito instance. Since this exchange of information is quick, unless the session expires within this very narrow window, this should work just fine for us. Thanks for the suggestion.

— Chris Janes   4 years ago
0

I would recommend handling the session expiring in a smooth manner. Glad I could help.

— Trey Teter   4 years ago
139 Views
1 Answer
4 years ago
4 years ago
Tags