Recent Content
How to create/subscribe the Webhook in Aurora
Hello Folks, I would like to understand the steps involved in setting up a webhook, including how to create one and subscribe to it for specific events or actions. Any guidance or best practices for managing webhooks in Aurora would be greatly appreciated. Thanks in Advance.
API Auth in Postman
Hi, Im a bit of a newbie here and would love some help. I am trying to complete Auth in Postman and returning 400 bad request/Invalid request or page not found when trying to obtain the code. Error: getaddrinfo ENOTFOUND {{base_community_url}} The URL is just the Community domain which is the same an the redirect URI. {{URL}}/api/2.0/auth/authorize?li_client_id={{Encoded client ID}}&redirect_uri={{Redirect URI not encoded}}&response_type=code or {{URL}}/api/2.0/auth/authorize?li_client_id={{Encoded client ID}}&redirect_uri={{Redirect URI not encoded}}&response_type=code&jwt={{SSO Toekn}} Thanks HannahKhoros Communities Aurora 24.11 Release Notes
5 MIN READ The Communities Aurora v24.11 release contains more community language translations, the ability to edit community guidelines and privacy policies, the Content Archive feature, conversation display format defaults, improvements to the developer experience, and several bug fixes.Handlebars Context Objects
Hi all, Just trying to see if anyone else has hit this or if its 'my head is mince syndrome'. I am trying to create a social sharing component but when is use {{page.url}} I am only getting the base url for the community. What I really want is the current page URL. I have tried every which way of the page. Context object but can't get it to spit out the current page URL.Error with Oauth 2.0 Client Credentials workflow
I'm trying to authenticate an api call in a typescript app using the oauth 2.0 client credentials workflow and I'm running into issues, I believe, with generating the CC Hash for this. This is for Community Classic. I have verified that I have the correct client id, client secret and shared secret key and that they're being pulled in correctly in my code. Not sure what I'm missing, but this is the error I see when I try to authenticate: {"error":"Authorization or API call failed","details":"Failed to obtain access token. Status: 403. Response: {\"status\":\"error\",\"message\":\"cc_hash is invalid.\",\"data\":{\"type\":\"error_data\",\"code\":214,\"developer_message\":\"The decryption failed. ccHash is Invalid\",\"more_info\":\"\"},\"metadata\":{}}"} Here's the relevant part of my Typescript code that's generating the CC Hash. Not sure if something is formatted incorrectly or what's not being generated correctly or causing it to return an invalid cc hash function generateCCHash(clientId: string, clientSecret: string, sharedSecretKey: string): string { try { const epochTimeMinute = getEpochTimeMinute(); const nonce = generateNonce(); const strToHash = `${clientId}:${clientSecret}:${nonce}:${epochTimeMinute}`; console.log("String to hash:", strToHash); const hash = crypto.createHash('sha512'); hash.update(strToHash, 'utf8'); hash.update(sharedSecretKey, 'utf8'); const hashResult = hash.digest('hex'); console.log("Generated hash (cc_hash):", hashResult); return hashResult; } catch (error) { console.error("Error generating CC-Hash:", error); throw error; } }24.10 API change breaks navigation
Staging instances of two three communities I work with got upgraded to 24.10 and for both all the Khoros supplied theme-lib.community-header-navigation broke as a result with the error: Freemarker template 'theme-lib.community-header-navigation' processing failed: InvalidReferenceException:The following has evaluated to null or missing: ==> restBuilder().method("POST").path("/search").body(liql_query).call().data.items [in template "theme-lib.community-header-navigation" at line 188, column 62] I haven't done any in-depth investigation or how to come up with a fix. On quick glance neither the Communities Classic v24.09 Release Notes nor Classic Communities: 24.10 Release Notes do contain any suspicious change. Just wanted to share so you folks got a starting point.Aurora: Multi-Auth SSO
Communities require diverse authentication methods to accommodate varying member segments like employees, customers, etc.Admins can offer multiple sign-in options simultaneously, providing enhanced flexibility. These options include: Khoros SSO Up to three IDPs for SAML More than three IDPs for OIDC/OAuth2 (OIDC can be configured via admin only) To edit these settings, go to Settings > Systems > ACCOUNT > Sign-in. If Sign-In Display is not displayed, contact Khoros Support and request that the Multi-Auth feature be enabled. Edit the Sign-In Display option to configure the sign-in options you want to provide your members and how you want to display the sign-in options. Below is an example on the list of sign-in options you can configure. From here, you can: View all available sign-in options for your community. Add a welcome note that is displayed to users on the sign-in page. Turn on or off the sign-in options you prefer. Edit the labels of the sign-in buttons. Rearrange the order in which the sign-in options appear on sign-in pages. Choose to display the sign-in options as buttons for member sign-in. If you select the Display as sign-in button option, members see a sign-in button. If you de-select this option, members see a sign-in form instead. Related topics: About Khoros Aurora Single Sign-On (SSO) Khoros Aurora SSO auto-sign in Configure SSO settings for the communityAurora OpenID Connect/OAuth 2.0 setting descriptions
This article describes all the OIDC- and OAuth2.0-related settings within Settings > System > Account > OIDC/OAuth Providers. If OIDC/OAuth Providers and its subsections are not displayed in the panel on the left, contact Khoros Support and request that the OIDC/OAuth feature be enabled. Learn more about the OIDC/OAuth 2.0 feature. Provider Information Name: Desired name to label this provider within the settings. ID: Desired ID to give to this provider. This ID is used within the Sign-in URL and Registration URL that are defined in Settings > System > Account > Single Sign-On (SSO). Client ID: The Client Identifier used to validate against the authorization server. Client Secret: The Client Secret used to validate against the authorization server. Authorization URL: The authorization endpoint which will return either the authorization code (Authorization code flow) or the ID token (implicit flow). Response type: Community only supports the Authorization Code flow; code is the default value for Authorization code flow. Scope: Defines what access privileges are being requested. To use OpenID Connect requests, openid value must be used. If supported, other scope values may be profile, email address, address, and/or phone. The scope defined here will determine which Claims are returned from either the ID Token or User Info endpoint. Multiple values input here must be separated by a comma. Add Static Parameters: Add any additional parameters that should be sent with the authorization URL during sign-in by clicking Add Parameter. You must enter the Key and Value. This can be used for passing optional parameters such as max_age, claims, etc. Persist parameters: When enabled, any query string parameters passed to the Khoros OIDC sign-in endpoint will be passed through to the Authorization URL upon sign-in. Parameters to be persisted can be added to the Registration page and Sign-in page URLs defined in general SSO settings for the community. Enable PKCE: Turn on this option to enable Proof Key Code Exchange for the authorization code flow. The OpenID Provider must also be configured to support this flow. Token URL: The token endpoint which will return the ID token. Client auth method: Authentication method to the token endpoint. Only two methods are supported, with the option to disable only if PKCE is being used. client_secret_base: Uses HTTP basic authentication. client_secret_post: Includes the client credentials in the request body. none: For security purposes, this should be chosen only if PKCE is used. Static Parameter (optional): Any static parameters that are used to request a token can be defined here. Header parameters (optional) Claim mapping (ssoid required): Any Claims returned from the token endpoint can be mapped here to an Aurora community profile attribute. JWT Options Note: The following options apply only to OIDC setups. Audience Override: (OIDC only) Audience is used in JWT validation. By default, JWT validation checks if the Audience (aud) claim in the JWT matches the client ID. If another aud claim is expected, enter it here. Issuer: (OIDC only) Should be set to the OpenID provider. Typically, it is the same as the Token endpoint. JWKS URI: (OIDC only) This URL contains the verification keys that are used in JWT validation. Disable JWT validation (for testing purposes only): (OIDC only) OpenID Connect flow must use JWT Validation according to spec. User Info (Optional) URL: URL of user info endpoint that is used to retrieve user information. The user info endpoint uses Bearer Authentication, if a URL is provided, then the token endpoint MUST return an Access Token. User attributes can also be obtained directly from the id_token where available. Use POST request: By default, the user info endpoint is called with a HTTP GET. Turn on this option if HTTP POST should be used instead. Static Parameters: Any static parameters that are used for the user info endpoint can be defined here. Header Parameters: Add any additional parameters that should be sent with the header during sign-in. Add Claim Mapping: Any claims returned from the user info endpoint can be mapped here to a Community profile attribute. These are used to specify key value pairs of claim values to be stored in the user's profile. The claims mapping is applied to the /token call response itself unless the id_token property is present, in which case the mapping is applied to that JSON body. Be aware of the following considerations when mapping user claims to community user attributes: ssoid: You must provide a mapping for this user attribute. The value of the user must be both unique and immutable. Additionally, the value is case sensitive. email: The value for the user must be unique. If you are unable to supply a user’s email address via the login flow, open a Support ticket to ask about having the user SSO registration page enabled to allow the user to be prompted to set their email address on first login. login: This must meet character requirements. roles.grant or roles.remove: If you supply mapping for these attributes, the value mapped must be a comma-separated list of role names, and those roles must already exist in the community. profile.url_icon: The user’s Community profile image can be set to a remotely hosted resource so long as it is accessible to the Community. Note: For other common profile fields, refer to User profile data in the Khoros Developer Docs. Logout (Optional) RP Initiated Read more information on OpenID Connect Relying Party (RP) logout. RP URL: The URL that is called when using Khoros /sso_logout_redirect endpoint. A back-channel request will be made to this logout URL passing the user’s access token. This URL is expected to sign out the user from the provider and functions as a single logout. Authorization method: Authorization method used when calling the logout endpoint. Basic uses the client ID and client secret in the Authorization Basic header. Bearer uses the user’s access token in the Authorization Bearer header. With None, no Authorization header is passed with the sign-out request. Token method: Optional field and not typically needed if the authorization method is set to Bearer. Selecting Form URL Encoded Body passes the user’s access token as application/x-www-form-urlencoded. JSON Body passes the user’s access token as application/json. RP param name: When the token method is set to Form URL Encoded Body or JSON Body, use this setting to specify the name of the parameter to pass. Defaults to token. RP Params passthrough: When enabled, any query-string parameters passed to the Khoros OIDC logout endpoint are passed through to the Logout URL during sign-out. Static Parameters: Additional parameters that should be passed to the Logout URL. OP Initiated OP enabled: When this setting is turned on, the logout endpoint can be used by the OpenID Provider (OP) initiated logout flows. OP allow iframe: When this setting is turned on, it allows the logout endpoint to be called via iframe and allows use with front-channel logout flows. OP URL: Users that browse to the logout endpoint are redirected to the specified post sign-out redirect URL after being signed out. By default, users are redirected to the community front page. Note: For private communities, this may result in immediately redirecting the user to sign in again. If you have a private community, you may want to specify an external URL (for example, on your .com). OP iframe redirect url: Use this to specify which URLs may place the logout endpoint in an iframe. In practice, this sets the Content Security Policy response header frame ancestor's value. Frontend Logout Frontend logout URL: If the frontend logout URL field is configured, the user will be sent to this location with their id_token_hint attached upon logout so that they may be cleanly logged out of the IDP. This also makes it possible to overwrite the post_logout_redirect_url if needed. Frontend logout params: Enter any additional parameters that should be sent with the frontend logout URL during sign-out. This can also be used for passing additional parameters. Alternate name for post_logout_redirect_uri: This value overrides the default post_logout_redirect_uri query parameter name. Advanced Redirect URI Override: This setting is primarily for testing purposes and typically not used in production environments. If a different redirect URI needs to be passed to the OP, it can be defined here. Note: The authorization code may be accepted only at the Community generated callback URL. Related topics: About Aurora OIDC/OAuth2.0 SSO
