vania-janet/multiturn-rag-retrieval-data huggingface dataset:
SSO sign-out API call variables

 Variable Value 

 region The region in which your instance of App ID is provisioned. Learn more about the [available regions](https://cloud.ibm.com/docs/appid?topic=appid-regions-endpoints). 
 tenantID The unique identifier for your instance of App ID. You can find this value in the Service Credentials tab of the App ID dashboard. If you do not have a set of service credentials, you can create one and take the value from there. 
 redirectURI A URI that you specified in your SSO configuration through the App ID dashboard. For security reasons, if you do not specify a value redirection cannot occur and an error is displayed. 
 clientID Your application's client ID. 



Even if the SSO session is ended, a user with a valid access token that is stored in their session might not be required to enter their credentials again until their token expires. By default the token expires after 1 hour.





 By using the Node.JS server SDK 

You can also use the App ID Node.js server SDK to automatically handle the redirection for you.



1. Set logoutSSO as a method. For example:

let webAppStrategy = new WebAppStrategy(.....);
....
webAppStrategy.logoutSSO();
2. Configure logout.

app.get('/logoutSSO', (req, res) => {
res.clearCookie("refreshToken");
webAppStrategy.logoutSSO(req,res, { "redirect_uri": "https://my-app.com/after_logout" });
});









 Ending all sessions for a user 

As an administrator, you can end all SSO sessions for any user by using the App ID admin APIs. The APIs are protected by a Cloud IAM token.

Example API request:
When you delete a policy, it's no longer included for authorization evaluations. IAM keeps a copy of all deleted policies for 10 days. During this time period, you can list and restore them at any time. To restore a deleted policy, see [Restoring deleted policies by using the API](https://cloud.ibm.com/docs/account?topic=account-iam-audit-policies&interface=apiiam-audit-policies-restore).





 Exporting user access policy reports 

You can export an access policy report for each user in your account if you are the account owner, have the Editor role or higher on the User Management service, or have the Editor role or higher on the IAM Access Management service. The access policy report lists all of the access policies that the user has, including the policies that are associated with access groups that the user is a member of.

Auditing user's access policies ensures that you're using the principle of least privilege. Use the report to determine whether the user is assigned to the appropriate access policies, and take the needed action to reduce the number of access policies.

To export the report, complete the following steps:



1. In the IBM Cloud console, go to Manage > Access(IAM), and select Users.
2. Determine the user that you want to audit and click the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/d4595e5202a9a27767cf034e81b038cdf772e0d5/secure-enterprise/includes/account/includes/icons/action-menu-icon.svg) > Access report.
3. Click Download JSON or Download CSV.







 Listing policies with last permit information by using the API 

List all account policies including last permit information that is sorted by count or last used. The policy metadata can be retrieved by using the [IAM Policy Management API](https://cloud.ibm.com/apidocs/iam-policy-managementpolicy-data-enrichment).



* Curl
* Java
* Python
* Go
* Node
If you migrate from a previous configuration, it is recommended that you double check your configuration code to make sure the VRRP group ID is not statically assigned.

The VRRP group ID is persisted in the database, so the same group ID value is used during an OS reload or upgrade. Any user modified VRRP group ID is overwritten with the system assigned value during an OS reload.





 VRRP priority 

The first machine in a gateway group has a priority of 254, and this value is decremented for the next device provisioned. You should never set a priority to 255, as this defines the VIP "address owner" and can result in unintended behavior when the machine is brought online with a configuration that differs from the running active master.





 VRRP preemption 

Preemption should always be disabled on all VRRP interfaces, so that a new device or one that is going through the reloading of its OS does not try to take over the cluster.





 VRRP advertise interval 

To signal that it is still in service, the master interface or VIF sends “heartbeat” packets called “advertisements” to the LAN segment, using the IANA assigned multicast addresses for the VRRP (224.0.0.18 for IPv4 and FF02:0:0:0:0:0:0:12 for IPv6).

By default, the interval is set to 1. This value can be increased, but it is not recommended to set a value over 5. On a busy network, it can take much longer than a second for all the VRRP notices to arrive on the backup device from the master, so a value of 2 should be used for high-traffic networks.





 VRRP synchronization (sync-group) 

Interfaces in a VRRP synchronization group (“sync group”) are synchronized such that, if one of the interfaces in the group fails over to backup, all interfaces in the group fail over to backup. For example, if one interface on a master router fails, the whole router fails over to a backup router.

This value is different than the VRRP group, as it defines what interfaces on a device fail over when an interface in that group registers a fault.
Choosing what to do at the end of a step 

By default, the steps in an action are executed in sequence from first to last. However, you can change this default in order to change what happens next. Used in combination with step conditions, this capability makes it possible for the conversation to follow many different flows depending on the customer's input.

To specify what happens when a step finishes, click And then.

![Step editor "And then" field](https://cloud.ibm.com/docs-content/v1/content/ca9232b3702768f24bb897f48f10778fcda28718/watson-assistant/images/step-and-then.png)

Select an option from the drop-down list. The following options are available:



* [Continue to next step](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-step-what-nextcontinue-to-next-step)
* [Re-ask previous step(s)](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-step-what-nextre-ask-previous-step)
* [Go to a subaction](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-step-what-nextgo-to-another-action)
* [Use an extension](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-step-what-nextuse-extension)
* [Search for the answer](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-step-what-nextsearch-for-answer)
* [Connect to agent](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-step-what-nextconnect-to-agent)
* [End the action](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-step-what-nextend-action)
3. Log in as the functional ID.

ibmcloud login
4. Change the infrastructure credentials to the functional ID user.

ibmcloud oc api-key reset --region <region>
5. Refresh the clusters in the region to pick up on the new API key configuration.

ibmcloud oc cluster master refresh -c <cluster_name_or_ID>



4. Infrastructure account: If the user's username is returned as the owner of the infrastructure account, migrate your existing clusters to a different infrastructure account before removing the user. For each cluster that the user created, follow these steps:



1. Check which infrastructure account the user used to provision the cluster.



1. In the Worker Nodes tab, select a worker node and note its ID.
2. Open the menu ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/icons/icon_hamburger.svg) and click Classic Infrastructure.
3. From the infrastructure navigation pane, click Devices > Device List.
4. Search for the worker node ID that you previously noted.
5. If you don't find the worker node ID, the worker node is not provisioned into this infrastructure account. Switch to a different infrastructure account and try again.



2. Determine what happens to the infrastructure account that the user used to provision the clusters after the user leaves.



* If the user does not own the infrastructure account, then other users have access to this infrastructure account and it persists after the user leaves. You can continue to work with these clusters in your account. Make sure that at least one other user has the [Administrator platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users) for the clusters.
* If the user owns the infrastructure account, then the infrastructure account is deleted when the user leaves. You can't continue to work with these clusters.
Now the controller verifies who you are (Authentication) and whether you have the required privileges to do what you want to do with that entity (Authorization). The credentials that are included in the request are verified against the so-called subjects database in a CouchDB instance.

In this case, the controller verifies that you exist in the Functions database and determines whether you have the necessary privilege to invoke the action myAction, which is assumed to be an action in a namespace that you own. Thus, you have the authorization to invoke the action.

As everything is sound, the gate opens for the next stage of processing.





 4. Getting the action: CouchDB… again 

After the controller determines that you are authenticated and authorized to invoke the action, it loads the action (in this case myAction) from the whisks database in CouchDB.

The record of the action contains mainly the code to run and any default parameters that you want to pass to your action, merged with the parameters that you included in the actual invoke request. The record also contains the resource restrictions that are imposed on it in execution, such as the amount of memory that the action is allowed to consume.

In this particular case, the action doesn’t take any parameters (the function parameter definition is an empty list). Thus, it is assumed that default parameters are not set, including specific parameters for the action.





 5. Who’s there to invoke the action: Load Balancer 

The Load Balancer, which is part of the controller, has a global view of the executors that are available in the system by checking their health status continuously. Those executors are called Invokers. The Load Balancer, knowing which Invokers are available, chooses one of them to invoke the action that you requested.





 6. Please form a line: Kafka 

The controller and the Invoker solely communicate through messages that are buffered and persisted by Kafka. Kafka lifts the burden of buffering in memory, which risks an OutOfMemoryException, from both the controller and the Invoker, while also making sure that messages are not lost if a system crashes.
[Log Analysis to Log Analysis streaming](https://cloud.ibm.com/docs-content/v1/content/f61dbc5d84bf0c89e477a05cab04c72f429e1b7a/log-analysis/images/la_to_la.svg)

Figure 2. Log Analysis to Log Analysis streaming

You can only stream from one IBM Log Analysis instance to one other IBM Log Analysis instance. You cannot stream from the second IBM Log Analysis instance to another IBM Log Analysis instance.

Currently, you can only stream up to 1TB of data per day.

If you have any regulatory requirement for data residency and compliance needs, you must control the location where Log Analysis, Event Streams, Kafka Connect and the destination tool are available.



 Configure streaming 

For information on how to configure streaming, see [Configuring streaming](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-streaming-configure).

Consider the following information when streaming data to an Event Streams instance:



* You must have manager role to configure streaming in the Log Analysis instance. This role includes the logdna.dashboard.manage IAM action role that allows a user to perform admin tasks such as configure streaming.
* When you configure streaming, the IBM Log Analysis instance and the Event Streams instance must be provisioned in the same account.
* To connect the IBM Log Analysis instance to the Event Streams instance, you need the following information:



* Endpoint URLs to call the APIs
* Credentials for authentication



* If you configure the account to restrict access to configured IP addresses via IAM settings, or if the account limits the network locations that connections are accepted from via context based restrictions rules (CBR) for the Event Streams service, you must allowlist the Log Analysis CIDR blocks in the account.
t.src='https://web-chat.global.assistant.dev.watson.appdomain.cloud/versions/' +
(window.watsonAssistantChatOptions.clientVersion || 'latest') +
'/WatsonAssistantChatEntry.js';
document.head.appendChild(t);
});
</script>
Show more



 Apple devices 

On Apple devices, the Intelligent Tracking Prevention feature automatically deletes any client-side cookie after 7 days. This means that if an anonymous customer accesses your website and then visits again two weeks later, the two visits are treated as two different MAUs.

To avoid this problem, use a server-side first-party cookie in your web application. For example, when an anonymous user visits your website for the first time, you can generate a unique user ID and store it in a server-side cookie with any expiration date you choose. Then, your code can use the [updateUserID()](https://web-chat.global.assistant.watson.cloud.ibm.com/docs.html?to=api-instance-methodsupdateuserid) instance method to set the user ID. You can then use the same cookie to set the same user ID for this customer on any future visits until it expires.





 More information 

For more information about billing, see [User-based plans explained](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-admin-managing-plan).

For more information about MAU limits per plan, see [Pricing](https://www.ibm.com/products/watson-assistant/pricing).

For more information about deleting a user's data, see [Labeling and deleting data](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-admin-securing).
If there is no data, the archive file for that period is empty.



 Archived file format 

The archive directory format looks like this:

year=<YYYY>/month=<MM>/day=<DD>/<accountID>.<YYYY>-<MM>-<DD>.<HHHH>.json.gz

Where

YYYY represents the year; MM represents the month; and DD represents the day.

<accountID> represents the auditing account ID, that is, the ID that is shown in the [web UI URL](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-get_web_url).

HHHH represents hours in 24 format.



* The timestamp that is used to determine whether the event is included in an archive is the UTC timestamp.



Depending on your location, there might be events that you see in local time in your views on a specific day. However, you cannot find them in the archive file. You are most likely viewing events in local time and the archive process uses the UTC timestamp.





 Configure archiving 

For information on how to configure archiving, see:



* [Configuring archiving through the UI](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-archiving).
* [Configuring archiving by using the API](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-archiving-manage-apiarchivingapi-conf).



In addition, consider the following information:



* You must have the manager role to configure archiving in the IBM Cloud Activity Tracker instance. This role includes the logdna.dashboard.manage IAM action role that allows a user to perform admin tasks such as configure archiving.
* When you configure archiving, the Activity Tracker instance and the IBM Cloud Object Storage (COS) instance must be provisioned in the same account.
* Max connections (optional): Define the maximum number of concurrent connections that the listener allows.
* HTTPS redirect: Click the toggle button to enable the HTTPS redirect configuration, then specify the following HTTPS redirect settings:



* HTTPS listener: The target HTTPS listener, which the current HTTP listener incoming traffic is redirected to. Note that you will only see a list of HTTPS listeners whose accept_proxy_proxy value is the same as the HTTP listener.
* Redirect URI (optional): The URL to which the request redirects.
* Status code: The status code of the response returned by the load balancer.







15. If you want to redirect, forward, or reject particular incoming traffic for an HTTP or HTTPS front-end listener based on certain criteria, configure layer 7 policies.



* After the status of the load balancer changes to Active, click Front-end listeners in the navigation and click the value in the Policies column for the listener you created.
* On the Policies page, click Add policy and specify the following information to create a policy. You can create multiple policies.



* Name: Enter a name for the policy, such as my-policy. The name must be unique within the listener.
* Action: The action to take when all the rules for the policy match. You can reject a request with a 403 response, redirect the request to a configured URL and response code, redirect the traffic from an HTTP listener to an HTTPS listener, or forward the request to a specific back-end pool. If an incoming request does not match the rules for any policies, the request is forwarded to the default back-end pool of the listener.
* Priority: Within each action type, policies are evaluated in ascending order of priority. Policies to reject traffic are always evaluated first, regardless of their priority. Policies to redirect traffic are evaluated next, followed by policies to forward traffic.
* Redirect: The URL to which the request is redirected, if the action is set to Redirect.
* Status Code: The status code of the response returned by the load balancer, if the action is set to Redirect.
Through our layer 7 support, you can now group VSI or Bare Metal server instances in server pools and handle incoming requests according to set rules and policies so that traffic can be redirected to a URL, rejected, or distributed to layer 7 pool members.





 20 February 2019 

Data logs
: IBM Cloud® Load Balancer now supports data logs forwarding. With data logs enabled, your load balancer log data is forwarded to the IBM Cloud Log Analysis Service.





 11 December 2018 

Back-end encryption and data log forwarding
: IBM Cloud® Load Balancer now supports back-end encryption and the ability to forward your data logs. Back-end encryption allows end-to-end data traffic encryption, including the traffic between the load balancer and the back-end servers. Data log forwarding lets you send data logs from your load balancers to the IBM Cloud Log Analysis Service.





 04 August 2018 

Layer 7 API support
: IBM Cloud® Load Balancer now provides a set of APIs supporting layer 7 load balancing. With layer 7 support, traffic can be redirected to a URL, rejected, or distributed to Level-7 pool members, including bare-metal and virtual-server instances. Incoming data traffic is classified by using Layer 7 policies and rules. The policies define what action to take when the data traffic matches the rules that are associated with them.
: For more information, see [Layer 7 load balancing](https://cloud.ibm.com/docs/loadbalancer-service?topic=loadbalancer-service-layer-7-load-balancing).





 04 April 2018 

Horizontal scaling
: IBM Cloud® Load Balancer now scales up automatically when its load increases, and scales down as it decreases. When you create a load balancer, it starts with two appliances, but the number of appliances can be increased to 16 as the monitoring system detects an increase in the load. The IP addresses of each of the active appliances are added as DNS A-Records to the Fully Qualified Domain Name (FQDN) of the load balancer.

Internal load balancer
: A highly demanded "internal" version of our IBM Cloud® Load Balancer is now available.
In the New Panel:



1. Set the Metric to sysdig_container_net_http_request_time.
2. Set Group by to container_id.



3. Edit the Dashboard scope, set the filter to container_image, is and icr.io/solution-tutorials/tutorial-application-log-analysis:latest.
4. Save the dashboard.



Zoom

![New Dashboard](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution12/new_dashboard.png)

Figure 3. New dashboard

To add another panel:



1. Use the Add Panel button in the dashboard.
2. Change the panel type from Timechart to Number
3. Set the Metric to sysdig_container_net_request_count.
4. Set the Time Aggregation to Rate.
5. Set the Group by to Sum.
6. Enable Compare To and set the value to 1 Hour ago.
7. Save the dashboard.









 Step 7: Remove resources 



* If you created them as part of this tutorial, remove the logging and monitoring instances from [Observability](https://cloud.ibm.com/observe) page.
* Delete the cluster including worker node, app and containers. This action cannot be undone.

ibmcloud ks cluster rm --cluster $MYCLUSTER -f --force-delete-storage



Depending on the resource it might not be deleted immediately, but retained (by default for 7 days). You can reclaim the resource by deleting it permanently or restore it within the retention period. See this document on how to [use resource reclamation](https://cloud.ibm.com/docs/account?topic=account-resource-reclamation).





 Expand the tutorial
Optionally, you can specify a list of file extensions to allow caching for files only with those extensions. All objects in the bucket must be set with anonymous read or public read access.

For more information, see [Accelerate delivery of static files using a CDN](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-static-files-cdn).





 Path-based CDN mappings 

Your IBM Cloud CDN service can be restricted to a particular directory path on the origin server by providing the path when you create the CDN. A user is allowed access only to those contents in that directory path. For example, if a CDN www.example.com is created with path /videos, it is accessible only through www.example.com/videos/.





 Purge-cached content 

IBM Cloud CDN provides the capability to conveniently and quickly remove, or "purge", the cached content from the Edge servers. With the introduction of the [purge group](https://cloud.ibm.com/docs/CDN?topic=CDN-cdn-api-referenceapi-for-multiple-file-purge) concept, paths can be classified into related groups, which can be purged at the same time. Purge groups can include 1000 paths, by default. A Purge operation with Akamai completes in about 5 seconds. You can also view your purge history, and save specific purge groups as favorites.





 Serve Stale content 

When the CDN Edge server receives a user request, and the requested content is not cached, the Edge server reaches out to the origin host to fetch the content. That content is then cached for the TTL duration specified for the content. If a user request is received after the TTL has expired, the Edge server reaches out to the origin host to fetch the content. If the origin server cannot be reached for some reason (for instance, the origin host is down, or there is a network issue), the Edge server serves the expired (stale) content to the request. This feature is supported by Akamai and cannot be turned off.





 Support for multiple origins with distinct paths