AdamN
Khoros Oracle
Joined 19 years ago
User Profile
User Widgets
Contributions
Re: Creating a blog on behalf of another user - GraphQL
Hi allensmith81 , while coAuthors is a valid input for creating blog articles, it doesn't appear that our GraphQL currently includes an input field to set the original author. One potential work-around, if you're using API v1 Authentication there's a way to essentially "switch users" via API. This allows a user with admin permissions to obtain an API session key for another user. You do this by passing in the desired user via the user.login parameter, and making the request with an admin user session key. This should return a session key for the user specified via user.login. If you're not familiar with API V1 Authentication, more details here: https://developer.khoros.com/khoroscommunitydevdocs/docs/session-key#retrieve-the-session-key This article in our Dev Docs gives a more detailed example of how this works for obtaining the session key: https://developer.khoros.com/khoroscommunitydevdocs/docs/create-subscriptions-for-another-user#example Once you have the session key for the desired user, you can then make the GraphQL call to create the blog article using the API v1 session key for that user, passing it into the request via the li-api-session-key request header. I hope this helps!13Views0likes1CommentRe: Urgent: Case Sensitivity w/ SSO
keithkelly I 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.232Views1like0CommentsRe: Urgent: Case Sensitivity w/ SSO
keithkelly Sorry 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
zachtines Thanks 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 Options282Views0likes1CommentRe: Refresh Token not returned from accessToken endpoint
Hi zachtines , 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!315Views0likes3CommentsRe: LithiumSSO token || How to calculate session inactivity
prasadu507 The 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.156Views0likes0CommentsRe: Is there way to create new status for ideas via API?
akashm It 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 instead252Views0likes0CommentsRe: Is there way to create new status for ideas via API?
Hi StanGromer , 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!271Views2likes0CommentsRe: Is there way to create new status for ideas via API?
akashm It 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!281Views2likes3Comments