vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Status codes 

HTTP has a set of standard status codes. These fall into five categories:



* Informational: 1xx
* Success: 2xx
* Redirection: 3xx
* Client Errors: 4xx
* Server Errors: 5xx





 Informational: 1xx 



Informational status codes

 Code Meaning Description 

 100 [Continue](https://datatracker.ietf.org/doc/html/rfc7231section-6.2.1) The server MAY respond with this status code if the client sends a preliminary request (sometimes called a "look-before-you-leap" request); this code indicates the client should resend the request, in full (including the previously omitted representation). This code MUST NOT be returned unless the Expect request header was provided with a value of 100-continue. 
 101 [Switching Protocols](https://datatracker.ietf.org/doc/html/rfc7231section-6.2.2) This status MUST be returned for successful requests that include a supported use of the Upgrade header. This status MUST NOT be returned except for operations which exist specifically to switch protocols<br><br>[1]<br><br>. For example, the HTTP handshake for a WebSocket connection returns 101 Switching Protocols and this handshake MAY be documented as an operation in an HTTP API. 







 Success: 2xx 



Success status codes

 Code Meaning Description 

 200 [OK](https://datatracker.ietf.org/doc/html/rfc7231section-6.3.1) This code MUST be returned for successful requests not covered by a more specific 2xx code. The response body to return depends on the method; see [Methods](https://cloud.ibm.com/docs/api-handbook?topic=api-handbook-methods) for more details. 
 201 [Created](https://datatracker.ietf.org/doc/html/rfc7231section-6.3.2) This code MUST be returned when a new resource was successfully created in a synchronous manner.
Introducing PKCS 11 - Standard Plan 

PKCS #11 is a standard that specifies an application programming interface (API), called Cryptoki, for devices that hold cryptographic information and perform cryptographic functions. The Cryptoki API follows a simple object-based approach. The approach addresses the goals of technology independence and resource sharing, presenting to applications a common, logical view of the device called a cryptographic token.

Cryptoki isolates an application from the details of the cryptographic device. The application does not have to change the interface to a different type of device or to run in a different environment. Thus, the application is portable. The functions of the Cryptoki API are organized into the following categories:



* [General-purpose functions](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html_Toc416959740) (four functions)
* [Slot and token management functions](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html_Toc416959741) (nine functions)
* [Session management functions](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html_Toc416959742) (eight functions)
* [Object management functions](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html_Toc416959743) (nine functions)
* [Encryption functions](http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html_Toc416959744) (four functions)
const rsaKey = new RSA(process.env.PUBLIC_IBM_RSA_KEY);

/
* Returns a signed JWT. Optionally, adds an encrypted user_payload in stringified JSON.
/
function mockLogin(userID, userPayload) {
const payload = {
sub: userID, // Required
iss: 'www.ibm.com', // Required
acr: 'loa1' // Required
// A short-lived exp claim is automatically added by the jsonwebtoken library.
};
if (userPayload) {
// If there is a user payload, it is encrypted in base64 format using the IBM public key.
payload.user_payload = rsaKey.encrypt(userPayload, 'base64');
}
const token = jwt.sign(payload, process.env.YOUR_PRIVATE_RSA_KEY, { algorithm: 'RS256', expiresIn: '10000ms' });
return token;
}
Show more
3. From the Zendesk application, enable visitor authentication.



* From the Chat dashboard navigation pane, expand Settings, and then click Widget.
* Open the Widget security tab.
* In the Visitor Authentication section, click the Generate button.



For more information, see [Enabling authenticated visitors in the Chat widget](https://support.zendesk.com/hc/en-us/articles/360022185314-Enabling-authenticated-visitors-in-the-Chat-widget). You do not need to follow the steps to create a JWT. The Assistant service generates a JSON Web Token for you.
4. Copy the shared secret from Zendesk.



To secure the Zendesk connection, complete the following steps:



1. In the Authenticate users section, set the switch to On.
2. Paste the secret that you copied from the Zendesk setup page into the Zendesk shared secret field.
Networking Provide the endpoints for routing API traffic; deploy and manage remote DataPower API Gateways (if desired) Expose the API to a public or private network via the IBM managed or a self-managed DataPower API Gateway 
 API subscriptions Enable API subscriptions as an identification/authentication method for a REST APIs and distribute appropriate keys to API subscribers Generate and authenticate API keys 
 API security Enable IBM-supported security mechanisms (e.g. OAuth provider/consumer, basic auth, etc) as an authentication method for a REST API Protect published APIs via OAuth tokens, basic auth, etc 
 Actions Configure Integrate, generate, and activate 
 Monitoring Monitor individual API uptime and configure necessary alerts Integrate with IBM Cloud Log Analysis to provide customer-accessible API operational logs 
 Rate limiting Define appropriate rate limiting rules via the API Connect Product and API YAML specifications Enforce rate limits 
 API management Configure API Connect using the provided interfaces and supported design specifications. Host, provision, integrate, and implement your APIs using your API Connect-compatible specifications 
 Developer Portal Configure authentication, manage Drupal modules, and administer Portal sites Apply scheduled upgrades and fixes, and ensure the general availability of the Portal subsystem
Web Application Firewall concepts 

The Web Application Firewall (WAF) protects against OSI Layer-7 attacks, which can be some of the most tricky. This document gives some details.



  What is a Web Application Firewall? 

A WAF helps protect web applications by filtering and monitoring HTTP traffic between a web application and the internet. A WAF is an OSI protocol Layer-7 defense in the [OSI model](https://en.wikipedia.org/wiki/OSI_model), and it is not designed to defend against all types of attacks.

Deploying a WAF in front of a web application is like placing a shield between the web application and the internet. A proxy server protects a client machine’s identity by using an intermediary (for outgoing traffic), but a WAF is a type of reverse-proxy that protects the server from exposure by having the client's traffic pass through the WAF before reaching the server (for incoming traffic).





  Types of attacks WAF can prevent 

A WAF typically protects web applications from attacks such as cross-site forgery, cross-site-scripting (XSS), file inclusion, and SQL injection, among others. A WAF usually is part of a suite of tools, which together can create a holistic defense against a range of attack vectors.





  How a WAF works 

A WAF operates through a set of rules often called policies. These policies aim to protect against vulnerabilities in the application by filtering out malicious traffic.

The value of a WAF comes from the speed and ease with which its policy modifications can be implemented, thereby allowing a faster response to varying attack vectors. For example, during a [DDoS attack](https://en.wikipedia.org/wiki/Denial-of-service_attack), rate limiting can be implemented by modifying WAF policies.





  Key benefits of a CIS WAF 

The IBM Cloud® Internet Services WAF is an easy way to set up, manage, and customize security rules to protect your web applications from common web threats. See the following list for key features:



*  Easy setup - The CIS WAF is part of our overall service, which takes just a few minutes to set up. After you redirect your DNS to us, you can switch on the WAF and set up the rules you need.
*  Detailed reporting - See greater detail in the reporting, for example, threats blocked by rule/rule group.
new HttpClientConfig.Builder("https://60d1b41b-2478-4767-9fc0-d99b1d00b6d1.bkvfu0nd0m8k95k94ujg.databases.appdomain.cloud:31347")
.multiThreaded(true)
// Add the credentials username and password
.defaultCredentials("admin", "mypassword")
.sslSocketFactory(sslSocketFactory)
.build());

// create a JestClient
JestClient client = factory.getObject();
// create the call for the cluster health
Health health = new Health.Builder().build();
// get the cluster health as a JestResult
JestResult result = client.execute(health);
// print out the cluster's health
System.out.printf("nn<------ CLUSTER HEALTH ------>n%snn", result.getJsonObject());
// shutdown the connection
client.close();

} catch (IOException | KeyStoreException | NoSuchAlgorithmException | KeyManagementException | CertificateException e) {
e.printStackTrace();
}

}

}
Show more

The following example uses the Python library [elasticsearch-py](https://www.elastic.co/guide/en/elasticsearch/client/python-api/current/index.html) to connect.

from elasticsearch import Elasticsearch
from ssl import create_default_context

context = create_default_context(cafile="path/to/cert.pem")

es = Elasticsearch(
* Token Source: Header
* Header Key Name: X-Gitlab-Token



Specify the following values to use generic webhook triggers with Slack outgoing webhooks:



* Securing: Token Matches
* Token Source: Payload
* JSON Property Name / Form Key: token



The following example shows how to use the curl command with a generic webhook that is secured with a Token Matches rule:

Zoom

![Generic webhook example](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/pipeline_tekton_generic_webhook.png)

Figure 2. Generic webhook example

curl -X POST 
https://devops-api.us-south.devops.cloud.ibm.com/v1/tekton-webhook/588236be-749b-4c67-ae57-a561abbbc9a8/run/7e82880e-4223-4c98-8ca9-ef6df36bb6dc 
-H 'Content-Type: application/json' 
-H 'token: 48a0f92c0932890048596906a22ae189c48c5619fbcf9600' 
-d '{
"somekey": "somevalue"
}'

To obtain payload values in the pipeline definition, specify a Triggerbinding parameter with a value that is derived from the event:

apiVersion: tekton.dev/v1beta1
kind: TriggerBinding
metadata:
name: binding
spec:
params:
- name: somekey
value: $(event.somekey)

Save your changes.
5. In the Environment properties section, click Add and select a property type to define your own environment property.
discoveryUrl string Yes A well-known endpoint that provides a JSON document of OIDC/OAuth 2.0 configuration information. 
 clientId string Yes An identifier for the client that is used for authentication. 
 clientSecret string *No A plain text secret that is used to authenticate the client. If not provided, a clientSecretRef must exist. 
 clientSecretRef object No A reference secret that is used to authenticate the client. The reference can be used in place of the clientSecret. 
 clientSecretRef.name string Yes The name of the Kubernetes Secret that contains the clientSecret. 
 clientSecretRef.key string Yes The field within the Kubernetes Secret that holds the clientSecret. 



* For backend applications: The OAuth 2.0 Bearer token spec defines a pattern for protecting APIs by using [JSON Web Tokens (JWTs)](https://datatracker.ietf.org/doc/html/rfc7519). By using the following configuration as an example, define a JwtConfig CRD that contains the public key resource, which is used to validate token signatures.

apiVersion: "security.cloud.ibm.com/v1"
kind: JwtConfig
metadata:
name: jwt-config
namespace: sample-app
spec:
jwksUrl: https://us-south.appid.cloud.ibm.com/oauth/v4/<tenantID>/publickeys







 Registering application endpoints 

Register application endpoints within a Policy CRD to validate incoming requests and enforce authentication rules. Each Policy applies exclusively to the Kubernetes namespace in which the object lives and can specify the services, paths, and methods that you want to protect.

apiVersion: "security.cloud.ibm.com/v1"
kind: Policy
metadata:
name: samplepolicy
namespace: sample-app
spec:
targets:
-
serviceName: <svcSampleApp>
paths:
- exact: /web/home
method: ALL
"ibmenapnsheaders": "{"apns-priority":10, "apns-collapse-id": "collapse"}"

To get more details on APNs headers, you can check out [here](https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/sending_notification_requests_to_apns/).





 ibmenchromebody(string/json) 

This attribute is needed if you want to send push notification to a chrome device. This is the body that you want to send to web server, this must be JSON in string format. For more information regarding chrome body, follow this documentation [here](https://developer.mozilla.org/en-US/docs/Web/API/Notification).

You can follow these examples for quick start:

"ibmenchromebody": "{"title":"Hello Chrome", "options": {}}"





 ibmenfirefoxbody(string/json) 

This attribute is needed if you want to send push notification to a Firefox device. This is the body that you want to send to web server, this must be JSON in string format. For more information regarding Firefox body, follow this documentation [here](https://developer.mozilla.org/en-US/docs/Web/API/Notification).

You can follow these examples for quick start:

"ibmenfirefoxbody": "{"title":"Hello Firefox", "options": {}}"





 ibmensafaribody(string/json) 

This attribute is needed if you want to send push notification to a Safari device. This is the body that you want to send to web server, this must be JSON in string format.
where {location} indicates where your application is hosted:



* us-south for Dallas
* us-east for Washington, DC
* eu-de for Frankfurt
* au-syd for Sydney
* jp-tok for Tokyo
* eu-gb for London
* kr-seo for Seoul



And {instance_id} is the unique identifier of your service instance.

The examples in the documentation abbreviate wss://api.{location}.speech-to-text.watson.cloud.ibm.com/instances/{instance_id} to {ws_url}. All WebSocket examples call the method as {ws_url}/v1/recognize.

A WebSocket client calls the /v1/recognize method with the following query parameters to establish an authenticated connection with the service. You can specify these aspects of the request only as query parameters of the WebSocket URL.

access_token (required string)
: Pass a valid access token to establish an authenticated connection with the service. You must establish the connection before the access token expires. You pass an access token only to establish an authenticated connection. Once you establish a connection, you can keep it alive indefinitely. You remain authenticated for as long as you keep the connection open. You do not need to refresh the access token for an active connection that lasts beyond the token's expiration time. Once a connection is established, it can remain active even after the token or its credentials are deleted.



IBM Cloud

Pass an Identity and Access Management (IAM) access token to authenticate with the service. You pass an IAM access token instead of passing an API key with the call. For more information, see [Authenticating to IBM Cloud](https://cloud.ibm.com/docs/watson?topic=watson-iamgs-credential-cloud).
IBM Cloud Pak for Data

Pass an access token as you would with the Authorization header of an HTTP request.
Store your the following variable to be used in the API command:



* crn: the full url-encoded CRN of the service instance.
* webhook_id: alert webhook identifier.



3. When all variables are initiated, get the webhook details:



curl -X GET https://api.cis.cloud.ibm.com/v1/:crn/alerting/destinations/webhooks/:webhook_id
-H 'content-type: application/json'
-H 'accept: application/json'
-H 'x-auth-user-token: Bearer xxxxxx'





 Updating a webhook using the API 

To update a webhook by using the API, follow these steps:



1. Set up your API environment with the correct variables.
2. Store your the following variable to be used in the API command:



* crn: the full url-encoded CRN of the service instance.
* webhook_id: alert webhook identifier.
* name: the name of the webhook.
* url: the URL of the webhook.
* secret: the optional secret or API key needed to use the webhook.



3. When all variables are initiated, update the webhook:



curl -X PUT https://api.cis.cloud.ibm.com/v1/:crn/alerting/destinations/webhooks/:webhook_id
-H 'content-type: application/json'
-H 'x-auth-user-token: Bearer xxxxxx'
-d '{"name":"Example Webhook","url":"https://hooks.slack.com/services/Ds3fdBFbV/456464Gdd"}'





 Deleting a webhook using the API 

To delete a webhook by using the API, follow these steps:



1. Set up your API environment with the correct variables.
2.
If not set, the context instance specified by ibmcloud cis instance-set INSTANCE is used.--output: Specify output format, only JSON is supported.<-- </section "id="section-update-waf-rule-options" "> --><-- <section "id="section-update-waf-rule-examples" "> --> Examples Disable WAF rule f939de3be84e66e757adcdcb87908023 in WAF package a25a9a7e9c00afc1fb2e0245519d725b. ibmcloud cis waf-rule-mode-set 31984fea73a15b45779fa0df4ef62f9b a25a9a7e9c00afc1fb2e0245519d725b f939de3be84e66e757adcdcb87908023 disable -i "cis-demo"
<-- </section "id="section-update-waf-rule-examples" "> --><-- </section "id="section-update-waf-rule" "> --><-- <section "id="section-create-waf-override" "> --> ibmcloud cis cis waf-override-create Create a URL based Web Application Firewall (WAF) rule. ibmcloud cis waf-override-create DNS_DOMAIN_ID (--json @JSON_FILE | JSON_STRING) -i, --instance INSTANCE] --output FORMAT] ! !!!!!!
<-- <section "id="section-create-waf-override-options" "> --> Command options DNS_DOMAIN_ID: The ID of DNS domain. Required.--json: The JSON file or JSON string used to describe a override WAF rule. Required.
<-- <ul> -->

* The required fields in JSON data are urls and rules.

<-- <ul> -->
Securing your API with Client ID and Client Secret using the Developer Toolkit 

Duration: 10 mins
Skill level: Beginner



 Objective 

This tutorial guides you through securing your API with Client ID and Client Secret in API Connect V5. When applications are registered in your Developer Portal, a Client ID is generated to identify the application. Optionally, a Client Secret (which serves as a password) can also be generated. Applications need to supply the Client ID and Client Secret keys when calling your API.





 Prerequisites 

Before you begin, complete one of the following tutorials:



* [Import an OpenAPI2.0 spec and proxy an existing REST service](https://cloud.ibm.com/docs/apiconnect/tutorials?topic=apiconnect-tut_rest_landing).
* [Add a New API Spec and Invoke an Existing REST Service](https://cloud.ibm.com/docs/apiconnect/tutorials?topic=apiconnect-tut_rest_landing).







 Set the identification mechanism of your API 



1. Start API Designer:
a. Open a command window.
b. Run the following command: apic edit API Designer opens in your default web browser. c. Click Sign in with IBM Cloud.
d. Enter your IBM Cloud login information.
2. Navigate to your API's Design view: a. Click Drafts in the navigation panel. b. Click the APIs tab. c. Click the Weather Provider API that you created in a previous tutorial. The API opens in the Design view.
![1_goto_drafts_api.png](https://cloud.ibm.com/docs-content/v1/content/78bb71851d95d7580503eb9ba10cf3ae31490ade/apiconnect/tutorials/images/1_goto_drafts_api.png)
3. In the Design view:
b.
* URL: https://us-south.functions.appdomain.cloud/api/v1/web/e97d2516-5ce4-4fd9-9d05-acc3dd8ennn/southernize/add_southern_charm
* Secret: none
* Header name: Content-Type
* Header value: application/json



The postmessage webhook calls an IBM Cloud Functions web action name add_southern_charm.

The node.js code in the add_southern_charm web action looks as follows:

function main(params) {
console.log(JSON.stringify(params))
if (params.payload.output.generic[0].text !== '') {
//Get the length of the input text
var length = params.payload.output.generic[0].text.length;
//create a substring that removes the last character from the input string, which is typically punctuation.
var revision = params.payload.output.generic[0].text.substring(0,length-1);
const response = {
body : {
payload : {
output : {
generic : [
{
//Replace the input text with your shortened revision and append y'all to it.
"response_type": "text",
"text": revision + ', ' + 'y'all.'
}
],
},
},
},
};
return response;
}
else {
return {
body : params
}
}
}
Show more





 Example 2 

This example shows you how to translate a message response back to the customer's native language. It only works if you perform the steps in [Example 2](https://cloud.ibm.com/docs/assistant?topic=assistant-webhook-prewebhook-pre-example-translate) to define a premessage webhook that translates the original message into English.
APIs 

IBM Watson® IoT Platform is deprecated. As of 30 April 2023, only subscribers on paid plans will be able to deploy new instances. The service will be fully withdrawn on 1 December 2023. Any instances that still exist on 1 December 2023 will be deleted. For more information, see [the deprecation details](https://cloud.ibm.com/docs/IoT?topic=IoT-deprecation).

This IBM Cloud® documentation collection pertains to the IBM Watson® IoT Platform Lite pricing plan and includes basic getting started information, API references, and general troubleshooting information. For the full Watson IoT Platform feature documentation, see the [Watson IoT Platform product documentation ![External link icon](https://cloud.ibm.com/docs-content/v1/content/dc2670e9228a1dbe562d3d2c7ee63f7a48ba27c3/icons/launch-glyph.svg)](https://www.ibm.com/support/knowledgecenter/SSQP8H/iot/overview/overview.html) on IBM Knowledge Center. More information about the various plans can be found in [Watson IoT Platform service plans](https://cloud.ibm.com/docs/services/IoT?topic=IoT-plans_overviewplans_overview).

Several APIs are available for developing code for devices, gateways, and applications that connect to IBM Watson® IoT Platform.

The HTTP APIs are protected by HTTP basic authentication. When you generate an API key by using the dashboard, you are presented with a key and an authentication token. For more information about API keys and tokens, see [API key connection ![External link icon](https://cloud.ibm.com/docs-content/v1/content/icons/launch-glyph.svg)](https://www.ibm.com/support/knowledgecenter/SSQP8H/iot/platform/platform_authorization.htmlapi-key).



 About HTTP APIs