Fix: Add authorization header examples for custom SMS provider (Product IS issue #26942)

[wso2-engineering-bot]

This PR was automatically generated by Claude AI.

• Fixes Missing explanation on how to configure Authorization details for custom SMS provider product-is#26942
• Type: Documentation / Suggestions
• Summary: Added clear examples and explanation for configuring authorization headers (Basic auth and Bearer token) in the custom SMS provider configuration. The documentation now includes specific examples for both authentication methods.
• Affected Versions: All versions that use the includes file (7.0.0, 7.1.0, 7.2.0, and next)
• Style Scope Verification: Microsoft Style Guidelines have been applied to the newly added content, ensuring clear, concise, and actionable documentation.
• Verification: Changes made to the common includes file that is used by all affected versions. The enhancement provides users with clear guidance on how to configure authorization headers for custom SMS providers.

Changes Made

Enhanced the "Headers" field documentation in the custom SMS provider configuration table to include:

1. Clearer description: Explicitly states that authorization details can be configured in this field
2. Basic authentication example: Shows how to configure Basic auth with base64 encoded credentials
3. Bearer token example: Demonstrates Bearer token authentication setup
4. Multiple headers example: Illustrates how to combine authorization headers with other custom headers

This addresses the issue where users were unclear about how to configure authorization for custom HTTP-based SMS providers in versions 7.0.0, 7.1.0, and 7.2.0, which don't have a dedicated authentication field in the UI.

Summary by CodeRabbit

• Documentation
  • Enhanced SMS provider configuration guide with expanded details on custom HTTP headers and authentication options.
  • Added practical examples demonstrating Basic authentication, Bearer token authentication, and multiple header configurations.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

wso2-engineering-bot seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[coderabbitai]

Walkthrough

Documentation update that expands the Headers section in the custom SMS provider configuration guide with detailed explanations and examples for configuring authorization headers using Basic authentication and Bearer token methods.

Changes

Cohort / File(s)	Summary
SMS Provider Documentation en/includes/guides/notification-channels/configure-sms-provider.md	Enhanced Headers cell with clearer guidance on configuring authorization details, including examples for Basic authentication, Bearer token authentication, and multiple header configurations.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

Poem

🐰 A rabbit hops through docs with glee,
Adding clarity for all to see,
Authorization headers now explained,
Basic auth and Bearer tokens explained,
Configuration knowledge, finally gained! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title directly relates to the main change: adding authorization header examples for the custom SMS provider configuration, matching the linked issue #26942.
Description check	✅ Passed	The PR description is mostly complete with clear context, examples, and rationale, though it deviates from the repository's template by omitting standard sections like Test environment and Security checks.
Linked Issues check	✅ Passed	The PR changes fully address linked issue #26942 by adding clear examples and explanations for Basic auth, Bearer token, and multiple headers configurations in the custom SMS provider documentation.
Out of Scope Changes check	✅ Passed	All changes are within scope—documentation enhancements to the Headers field for custom SMS provider configuration directly align with the linked issue's requirements.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fixing-product-is-issue-26942-1772908411

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (3)

en/includes/guides/notification-channels/configure-sms-provider.md (3)

108-113: Improve placeholder consistency in examples.

The examples use inconsistent placeholder formatting:

• Lines 108-111: <base64_encoded_username:password> and <token> use angle brackets to indicate placeholders
• Line 113: x-custom-header: value lacks angle brackets, making it unclear whether "value" is a literal string or a placeholder

For clarity, format all placeholders consistently with angle brackets.

📝 Proposed fix for placeholder consistency

           <strong>Multiple headers:</strong><br/>
-          <code>Authorization: Bearer &lt;token&gt;, x-custom-header: value</code>
+          <code>Authorization: Bearer &lt;token&gt;, x-custom-header: &lt;value&gt;</code>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@en/includes/guides/notification-channels/configure-sms-provider.md` around
lines 108 - 113, The examples in the Authorization section use inconsistent
placeholder formatting; update the three examples (Basic authentication, Bearer
token authentication, Multiple headers) so all placeholders are wrapped in angle
brackets — e.g., change base64_encoded_username:password to
<base64_encoded_username:password>, <token> remains as-is, and change the
Multiple headers example to use <value> for the custom header placeholder —
ensure the text "x-custom-header: <value>" mirrors the other examples.

---

108-109: Clarify the base64 encoding placeholder for Basic authentication.

The placeholder <base64_encoded_username:password> might confuse users about whether they should:

1. Literally type "base64_encoded_username:password", or
2. Base64-encode their actual credentials (e.g., username:password) first, then paste the result

Consider making this more explicit to avoid user confusion.

💡 Suggested clarification

           <strong>Basic authentication:</strong><br/>
-          <code>Authorization: Basic &lt;base64_encoded_username:password&gt;</code><br/><br/>
+          <code>Authorization: Basic &lt;base64-encoded credentials&gt;</code><br/>
+          (Encode <code>username:password</code> in base64 format first)<br/><br/>

Or alternatively, show a more complete example:

           <strong>Basic authentication:</strong><br/>
-          <code>Authorization: Basic &lt;base64_encoded_username:password&gt;</code><br/><br/>
+          <code>Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=</code><br/>
+          (Replace with your base64-encoded <code>username:password</code>)<br/><br/>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@en/includes/guides/notification-channels/configure-sms-provider.md` around
lines 108 - 109, The placeholder "base64_encoded_username:password" is
ambiguous; update the Authorization example to explicitly instruct users to
base64-encode the literal "username:password" and then supply that encoded
string after "Basic ". Replace or augment the current snippet (which shows
Authorization: Basic <base64_encoded_username:password>) with a clear phrasing
that says: base64-encode your credentials in the form username:password and use
the resulting base64 string as the token following "Basic". Also add a brief
concrete example text showing input and resulting token (e.g., username:password
→ base64-result) to illustrate the transformation.

---

106-106: Consider using more direct, active voice.

The phrase "If multiple headers are needed, separate them with commas" uses passive voice. While not incorrect, the guidelines prefer active voice and direct instructions.

✍️ Suggested rewording for active voice

-        <td>Custom static headers to be passed with the HTTP request. Use this field to configure authorization details for your SMS provider. If multiple headers are needed, separate them with commas. (Optional)</td>
+        <td>Custom static headers to pass with the HTTP request. Use this field to configure authorization details for your SMS provider. To configure multiple headers, separate them with commas. (Optional)</td>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@en/includes/guides/notification-channels/configure-sms-provider.md` at line
106, The sentence uses passive voice; update the copy in the documentation
string (the table cell text) to active voice by replacing "If multiple headers
are needed, separate them with commas." with a direct imperative like "Separate
multiple headers with commas." Keep the rest of the cell text intact (the
description for custom static headers / authorization details) so the table row
text and meaning remain unchanged.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@en/includes/guides/notification-channels/configure-sms-provider.md`:
- Around line 108-113: The examples in the Authorization section use
inconsistent placeholder formatting; update the three examples (Basic
authentication, Bearer token authentication, Multiple headers) so all
placeholders are wrapped in angle brackets — e.g., change
base64_encoded_username:password to <base64_encoded_username:password>, <token>
remains as-is, and change the Multiple headers example to use <value> for the
custom header placeholder — ensure the text "x-custom-header: <value>" mirrors
the other examples.
- Around line 108-109: The placeholder "base64_encoded_username:password" is
ambiguous; update the Authorization example to explicitly instruct users to
base64-encode the literal "username:password" and then supply that encoded
string after "Basic ". Replace or augment the current snippet (which shows
Authorization: Basic <base64_encoded_username:password>) with a clear phrasing
that says: base64-encode your credentials in the form username:password and use
the resulting base64 string as the token following "Basic". Also add a brief
concrete example text showing input and resulting token (e.g., username:password
→ base64-result) to illustrate the transformation.
- Line 106: The sentence uses passive voice; update the copy in the
documentation string (the table cell text) to active voice by replacing "If
multiple headers are needed, separate them with commas." with a direct
imperative like "Separate multiple headers with commas." Keep the rest of the
cell text intact (the description for custom static headers / authorization
details) so the table row text and meaning remain unchanged.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 82619bee-2689-4f6e-b70a-fa67d1857f24

📥 Commits

Reviewing files that changed from the base of the PR and between 3f332c6 and c0d46d3.

📒 Files selected for processing (1)

• en/includes/guides/notification-channels/configure-sms-provider.md

[AnuradhaSK]

@copilot Authorization header configuration in headers filed is required only under (product_name == "WSO2 Identity Server" and is_version <= "7.2.0") condition

[Copilot]

@AnuradhaSK I've opened a new pull request, #5944, to work on those changes. Once the pull request is ready, I'll request review from you.