AdamN
Khoros Oracle
Joined 18 years ago
User Profile
User Widgets
Contributions
Re: Urgent: Case Sensitivity w/ SSO
keithkellyI gave our Support team a heads up on the necessary backend change, so if you'd like to continue your discussion in the existing Support case, they should be able to help coordinate next steps. If you weren't already planning to, I'd suggest testing against stage first where possible to confirm expected behavior for existing and new accounts.230Views1like0CommentsRe: Urgent: Case Sensitivity w/ SSO
keithkellySorry to hear about the trouble you're having. We try to make it a point throughout the launch process to call out this fact, including in our SSO Kickoff call and in our documentation. Apologies if we missed the mark there. I'll circle back with our team to see where we might have room for improvement in how we communicate this. The reason we handle the SSO ID as case sensitive is to align with the standards of the protocols we support. For example, the SAML "NameID" is expected to be case-sensitive per the spec, as is Open ID Connect's "sub" value. If we did not align with these standards, then it could create a scenario where one user could log in to another user's account, which would not be good either! As a side note, we generally discourage the use of e-mail address for the SSO ID, since it is not uncommon for people to change their e-mail address for various reasons (marriage, changing companies, changing email providers, just because, etc.) and one of the requirements of the SSO ID is that it must be immutable. If you do not already have some kind of immutable, unique identifier for each user, the best practice would be to generate and store one, like a GUID. It's worth noting that while we do not have a config to disable case sensitivity, we do have a backend config that allows us to transform SSO IDs to either all lower case or all upper case. So if you could apply a similar transformation on your IDP side, that might help solve the problem going forward. However, we would still need to account for existing users (i.e. update them all to lower-case), and if you're going to that length, it would be better to replace the SSO IDs with GUIDs if possible. It sounds like you have experience with scripting for our APIs, so this is potentially something you could self-service. You'd just want to make sure to temporarily prevent SSO logins while you're running the script, to avoid data inconsistency issues. And as Claudius suggested, our Professional Services can also assist with these types of scripts if you'd prefer to work with us via a project. I hope this helps!340Views4likes0CommentsRe: Refresh Token not returned from accessToken endpoint
zachtinesThanks for flagging the conflicting information. Despite how the setting is named, it appears the documentation is actually correct... Having the setting unchecked will allow a refresh token to be generated. I'll flag this for our product and docs team to see if we can improve this. I would give that a try first, and if it's still not working for your individual user account, you would normally find it under My Settings > Personal > Auto-Signin Options274Views0likes1CommentRe: Refresh Token not returned from accessToken endpoint
Hizachtines, I'd suggest checking whether the account you're using to login has Auto Sign-in enabled. If so, the refresh token will not be returned. This is what the "Note" on this page is referring to:https://developer.khoros.com/khoroscommunitydevdocs/reference/request-auth-token-oauth One thing that's not clear from the documentation is that disabling Auto Sign-in via the admin will not resolve this issue for existing accounts, since the preference will have already been stored in the existing account. You would need to login to the UI with the account and disable Auto Sign-in in the individual account's preferences. I hope this helps!307Views0likes3CommentsRe: LithiumSSO token || How to calculate session inactivity
prasadu507The best practice here would be to implement retry logic that can detect an expired session key error response from the API, acquire a new fresh session key, and make the API call again. Trying to track the session key inactivity period may be futile, as you would still need retry logic to account for the "when the community is restarted" scenario. Additionally, artificially attempting to keep the session active by making a passive request every 30-X minutes may unnecessarily tie up system resources, and again you would still need to account for the other scenarios of expiring after 24 hours or after a restart.142Views0likes0CommentsRe: Is there way to create new status for ideas via API?
akashmIt looks like you're missing the /available path in the request. At community level, when creating the status, the path is: /restapi/vc/message_statuses/add At the board level, when associating the already created status with the board, the path is: /restapi/vc/boards/id/<board id>/message_statuses/available/add So for your last example, it would be something like: https://<MY URL>/restapi/vc/boards/id/<My Board ID>/message_statuses/available/add?message_status=key/pending_closure Please give this a try instead243Views0likes0CommentsRe: Is there way to create new status for ideas via API?
HiStanGromer, I'm not seeing a separate call for editing/updating in our docs. However, from a cursory look at the logic behind the scenes, it appears that if you specify an existing key via the /add method, it will attempt to update the corresponding status. This seems to be implied by the documentation as well since it mentions for the "returns" details: MessageStatus: either the pre-existing message status with the provided key and type (if provided), or the newly created status. But you may want to try it in stage first, just to make sure it works as expected. I hope this helps!268Views2likes0CommentsRe: Is there way to create new status for ideas via API?
akashmIt is expecting the id or the key of the status, as defined when you created the status. Then you pass it in the request like: .../message_statuses/available/add?message.status=key/accepted or .../message_statuses/available/add?message.status=id/654 (Note, you'll want to URL-encode your query param values. I'm leaving them unencoded here for readability) If you need to create new statuses, you can use: https://devdocportal.khoros.com/t5/Community-API-v1-Reference/bd-p/restv1docs?section=commv1&leaf-id=Community.message_statuses#Community.message_statuses.add I hope this helps!276Views2likes3CommentsRe: Set User Rank via API
I think Stan has the right idea. As Stan pointed out, you can't directly set ranks via the API or otherwise; it's all managed through the rank structure itself, so the rank structure would need to be built to account for this. How easy or hard this is will likely depend on how your rank formulas are constructed: If your formula is essentially a series of AND evaluations (e.g. posts > 10 && net_kudos_events_received > 5 && tagging_tag_count > 3 && ...) then you'll probably need some kind of special case added in as an OR logic, or as Stan suggested have separate parallel ranks for the legacy users based on role or some other criteria unique to these users. If your formula is doing some kind of math calculation to total some kind of "points" system (e.g. posts*1.4 + net_kudos_events_received*3 +tagging_tag_count*0.7 > 24), then one option would be to use the Bonus Points("arbitrary_points" in your rank formula) to give these legacy users a boost to meet some minimum ranking threshold.188Views1like1Comment