Nathan Moreton
2 days ago
committed by
GitHub
GitHub
5 changed files with 578 additions and 4 deletions
@ -0,0 +1,200 @@ |
|||||
|
# SSO cookie vendor |
||||
|
|
||||
|
Lets the Bitwarden mobile and desktop apps log in when Vaultwarden sits behind a |
||||
|
reverse proxy that authenticates every request, such as Cloudflare Access, |
||||
|
Authentik, Authelia, or oauth2-proxy. |
||||
|
|
||||
|
## Background |
||||
|
|
||||
|
Putting Vaultwarden behind an authenticating proxy means only users who pass |
||||
|
your identity provider (IdP) reach the vault at all. Bots cannot crawl the |
||||
|
endpoint, credential stuffing never reaches the login form, and the exposed |
||||
|
surface shrinks to the proxy. |
||||
|
|
||||
|
The cost is that the Bitwarden mobile and desktop apps can no longer finish |
||||
|
logging in. The proxy expects a browser with a cookie jar and OAuth 2.0 redirect |
||||
|
support, and the apps' HTTP clients have neither. After the browser step, the |
||||
|
apps receive the proxy's HTML login page where they expect JSON from |
||||
|
Vaultwarden, and login stalls. |
||||
|
|
||||
|
Bitwarden solved this in their own server in February 2026 with a flow called |
||||
|
SSO cookie vending: |
||||
|
|
||||
|
1. The server states in `/api/config` that it sits behind an authenticating |
||||
|
proxy, and names the IdP login URL and the cookie to look for. |
||||
|
2. The app opens a system browser at that IdP login URL. |
||||
|
3. After the user authenticates, the proxy sets its cookie and the browser |
||||
|
reaches `/api/sso-cookie-vendor`. |
||||
|
4. The server reads the cookie and redirects the browser to a `bitwarden://` |
||||
|
deep link carrying it. |
||||
|
5. The app attaches that cookie to every later API request, and the proxy lets |
||||
|
those requests through. |
||||
|
|
||||
|
Vaultwarden 2026.2.0 shipped the web-vault connector page from |
||||
|
[bitwarden/clients#18476][pr-18476], but not the two server-side pieces the flow |
||||
|
needs: the `/api/sso-cookie-vendor` endpoint and the `communication.bootstrap` |
||||
|
block in `/api/config`. Without them the apps detect the connector page, open a |
||||
|
browser, complete the proxy's authentication, and then get a 404 when they try |
||||
|
to collect the cookie. This change adds both pieces. |
||||
|
|
||||
|
## What this adds |
||||
|
|
||||
|
A configuration section, `sso_cookie_vendor`, holding four settings: |
||||
|
|
||||
|
| Setting | Purpose | |
||||
|
|---|---| |
||||
|
| `SSO_COOKIE_VENDOR_ENABLED` | Turns the feature on. Defaults to `false`. | |
||||
|
| `SSO_COOKIE_VENDOR_IDP_LOGIN_URL` | URL the app opens in a browser to authenticate. | |
||||
|
| `SSO_COOKIE_VENDOR_COOKIE_NAME` | Name of the cookie the proxy sets on authenticated requests. | |
||||
|
| `SSO_COOKIE_VENDOR_COOKIE_DOMAIN` | Domain scope of that cookie. | |
||||
|
|
||||
|
On top of those settings, this change: |
||||
|
|
||||
|
- Publishes the three string settings in `/api/config` as a |
||||
|
`communication.bootstrap` object, in the shape Bitwarden's clients already |
||||
|
read from [bitwarden/server#6892][pr-6892]. |
||||
|
- Serves `GET /api/sso-cookie-vendor`, which reads the proxy's cookie from the |
||||
|
request and returns a 302 to |
||||
|
`bitwarden://sso-cookie-vendor?COOKIE_NAME=COOKIE_VALUE&d=1`. Replace |
||||
|
`COOKIE_NAME` and `COOKIE_VALUE` with your configured cookie name and its |
||||
|
percent-encoded value; `d=1` is the sentinel the clients look for. |
||||
|
- Refuses to start when `SSO_COOKIE_VENDOR_ENABLED` is `true` and any of the |
||||
|
three string settings is empty, and reports which ones to set. |
||||
|
|
||||
|
The route is registered only when the feature is on. With |
||||
|
`SSO_COOKIE_VENDOR_ENABLED=false`, Vaultwarden serves exactly the routes it |
||||
|
served before. |
||||
|
|
||||
|
### Sharded cookies |
||||
|
|
||||
|
Cloudflare Access splits its auth JWT across numbered cookies, such as |
||||
|
`CF_Authorization-0` and `CF_Authorization-1`, when the token outgrows the |
||||
|
per-cookie size limit. The endpoint looks for up to 20 shards, `-0` through |
||||
|
`-19`, and forwards every shard it finds in one deep link, in ascending order, |
||||
|
so the app can reassemble the token. An unsuffixed cookie takes precedence over |
||||
|
any shards, matching the Bitwarden server. |
||||
|
|
||||
|
### Why this belongs in the server |
||||
|
|
||||
|
The existing workaround for Cloudflare Access users is a Cloudflare Worker that |
||||
|
intercepts `/api/config` and `/api/sso-cookie-vendor` and supplies the same |
||||
|
behavior. That works, with three drawbacks: |
||||
|
|
||||
|
- Every user behind Cloudflare Access has to deploy and maintain a Worker. |
||||
|
- A Worker helps only Cloudflare Access users. Authentik, Authelia, |
||||
|
oauth2-proxy, and any other authenticating proxy that sets a cookie can use |
||||
|
the same flow, but each one needs its own shim. |
||||
|
- `communication.bootstrap` is part of Bitwarden's `/api/config` contract, so it |
||||
|
belongs in the server rather than in a proxy layer. |
||||
|
|
||||
|
Implementing it in Vaultwarden makes any authenticating proxy work with the |
||||
|
mobile and desktop apps once you set four environment variables. |
||||
|
|
||||
|
## Configure the endpoint |
||||
|
|
||||
|
Set the four settings in `.env`, in `config.json`, or through the admin panel: |
||||
|
|
||||
|
```bash |
||||
|
SSO_COOKIE_VENDOR_ENABLED=true |
||||
|
SSO_COOKIE_VENDOR_IDP_LOGIN_URL=https://example.cloudflareaccess.com/cdn-cgi/access/login/vault.example.com |
||||
|
SSO_COOKIE_VENDOR_COOKIE_NAME=CF_Authorization |
||||
|
SSO_COOKIE_VENDOR_COOKIE_DOMAIN=vault.example.com |
||||
|
``` |
||||
|
|
||||
|
### Cloudflare Access |
||||
|
|
||||
|
- `SSO_COOKIE_VENDOR_IDP_LOGIN_URL` is the Access Login URL on the |
||||
|
application's details page. It takes the form |
||||
|
`https://TEAM.cloudflareaccess.com/cdn-cgi/access/login/YOUR_DOMAIN`, where |
||||
|
`TEAM` is your Cloudflare Zero Trust team name and `YOUR_DOMAIN` is the |
||||
|
hostname the Access application protects. |
||||
|
- `SSO_COOKIE_VENDOR_COOKIE_NAME` is always `CF_Authorization`. |
||||
|
- `SSO_COOKIE_VENDOR_COOKIE_DOMAIN` is the domain the Access application |
||||
|
protects. |
||||
|
|
||||
|
### Other authenticating proxies |
||||
|
|
||||
|
Any proxy works that redirects unauthenticated requests to a browser-based IdP |
||||
|
flow and sets a cookie on the authenticated response. Set |
||||
|
`SSO_COOKIE_VENDOR_IDP_LOGIN_URL` to the proxy's login URL, and set |
||||
|
`SSO_COOKIE_VENDOR_COOKIE_NAME` and `SSO_COOKIE_VENDOR_COOKIE_DOMAIN` to the |
||||
|
cookie the proxy sets on authenticated sessions. |
||||
|
|
||||
|
Note: Cloudflare Access is the only proxy this has run against in production. |
||||
|
The others meet the requirements above, but no one has reported a tested |
||||
|
configuration for them yet. |
||||
|
|
||||
|
## How the login flow runs |
||||
|
|
||||
|
From the user's side, with the feature configured: |
||||
|
|
||||
|
1. The user opens the Bitwarden app and points it at their Vaultwarden server. |
||||
|
2. The app reads `/api/config`, finds |
||||
|
`communication.bootstrap.type` set to `ssoCookieVendor`, and switches to the |
||||
|
cookie vending flow. |
||||
|
3. The app prompts the user to sign in through their browser and opens the |
||||
|
system browser at `SSO_COOKIE_VENDOR_IDP_LOGIN_URL`. |
||||
|
4. The browser follows the proxy to the IdP. The user authenticates. |
||||
|
5. The proxy sets its auth cookie and sends the browser to |
||||
|
`/api/sso-cookie-vendor`. |
||||
|
6. Vaultwarden reads the cookie off the request and redirects the browser to |
||||
|
`bitwarden://sso-cookie-vendor?CF_Authorization=COOKIE_VALUE&d=1`. |
||||
|
7. The operating system hands the deep link to the Bitwarden app. |
||||
|
8. The app stores the cookie and sends it with every later API request. The |
||||
|
proxy recognizes the cookie, lets the request through, and the app continues |
||||
|
to the usual master password unlock. |
||||
|
|
||||
|
The apps need no changes. This uses the cookie vending support Bitwarden's |
||||
|
clients already ship. |
||||
|
|
||||
|
## Security notes |
||||
|
|
||||
|
- The endpoint exists only when `SSO_COOKIE_VENDOR_ENABLED` is `true`. An |
||||
|
install that leaves the feature off serves the same routes it served before. |
||||
|
- The endpoint reads a cookie from a request the proxy has already |
||||
|
authenticated. The proxy validates the IdP session before the request reaches |
||||
|
Vaultwarden, so this adds no authentication boundary of its own. |
||||
|
- The redirect moves the cookie between two parties that both already hold it: |
||||
|
the browser that received it and the app on the same device. The proxy |
||||
|
validates the same cookie in either case. |
||||
|
- Vaultwarden's own authentication still applies. The user unlocks the vault |
||||
|
with their master password after the proxy gate, so this does not weaken the |
||||
|
vault. |
||||
|
- The deep link is capped at 8192 bytes, matching the Bitwarden server. A |
||||
|
request that would exceed the cap gets a 400 and an HTML error page. |
||||
|
- A request carrying neither the cookie nor any shard gets a 404 and the same |
||||
|
error page, which tells the user to return to the app. |
||||
|
|
||||
|
## Test the change |
||||
|
|
||||
|
Unit tests live in `src/api/core/sso_cookie_vendor.rs` under `#[cfg(test)] mod |
||||
|
tests`. Run them with: |
||||
|
|
||||
|
```bash |
||||
|
cargo test --features sqlite -- sso_cookie_vendor |
||||
|
``` |
||||
|
|
||||
|
They cover: |
||||
|
|
||||
|
- A single cookie, the common case. |
||||
|
- Sharded cookies, forwarded in suffix order regardless of map iteration order. |
||||
|
- An unsuffixed cookie taking precedence when shards are also present. |
||||
|
- A missing cookie producing a 404. |
||||
|
- Percent-encoding of values holding spaces and reserved characters. |
||||
|
- An oversize cookie producing a link past the 8192-byte cap. |
||||
|
- The error page matching the Bitwarden server's HTML. |
||||
|
|
||||
|
## References |
||||
|
|
||||
|
- [bitwarden/server#6880][pr-6880]: configuration infrastructure. |
||||
|
- [bitwarden/server#6892][pr-6892]: exposing the configuration in `/api/config`. |
||||
|
- [bitwarden/server#6903][pr-6903]: the endpoint implementation. |
||||
|
- [bitwarden/clients#18476][pr-18476]: the web-vault connector page, shipped in |
||||
|
Vaultwarden 2026.2.0. |
||||
|
- [bitwarden/clients#19392][pr-19392]: client-side cookie acquisition. |
||||
|
|
||||
|
[pr-6880]: https://github.com/bitwarden/server/pull/6880 |
||||
|
[pr-6892]: https://github.com/bitwarden/server/pull/6892 |
||||
|
[pr-6903]: https://github.com/bitwarden/server/pull/6903 |
||||
|
[pr-18476]: https://github.com/bitwarden/clients/pull/18476 |
||||
|
[pr-19392]: https://github.com/bitwarden/clients/pull/19392 |
||||
@ -0,0 +1,299 @@ |
|||||
|
//! SSO cookie vending for the Bitwarden mobile and desktop apps behind an authenticating proxy.
|
||||
|
//!
|
||||
|
//! When Vaultwarden runs behind a reverse proxy that gates every request on an identity provider
|
||||
|
//! (Cloudflare Access, Authentik, Authelia, oauth2-proxy), the Bitwarden mobile and desktop apps
|
||||
|
//! cannot finish logging in. The proxy answers their API calls with a browser redirect to the
|
||||
|
//! identity provider, and their HTTP clients have no cookie jar or browser to follow it with.
|
||||
|
//!
|
||||
|
//! Bitwarden's answer is cookie vending. The server advertises the flow through the
|
||||
|
//! `communication.bootstrap` object in `/api/config`, the app opens a system browser at the
|
||||
|
//! identity provider, and the browser lands on the route in this module once the proxy has set its
|
||||
|
//! auth cookie. The route hands that cookie back to the app as a `bitwarden://` deep link, and the
|
||||
|
//! app attaches it to every later API request so the proxy lets those requests through.
|
||||
|
//!
|
||||
|
//! Vaultwarden authenticates nobody here. The proxy is the gate, and the vault's own master
|
||||
|
//! password unlock still runs afterwards. The route is registered only when
|
||||
|
//! `SSO_COOKIE_VENDOR_ENABLED` is true, so installs that have not opted in are unaffected.
|
||||
|
//!
|
||||
|
//! This is the server half of bitwarden/server#6880, #6892, and #6903. For operator-facing setup,
|
||||
|
//! see `docs/sso-cookie-vendor.md`.
|
||||
|
|
||||
|
use std::collections::HashMap; |
||||
|
|
||||
|
use rocket::{ |
||||
|
Route, |
||||
|
http::{CookieJar, Status}, |
||||
|
response::{Redirect, content::RawHtml as Html}, |
||||
|
}; |
||||
|
|
||||
|
use crate::CONFIG; |
||||
|
|
||||
|
/// Maximum length of the `bitwarden://` deep link, in bytes.
|
||||
|
///
|
||||
|
/// Matches the limit the Bitwarden server enforces, so an oversize token fails the same way on
|
||||
|
/// both servers instead of producing a link the app or the operating system truncates silently.
|
||||
|
const MAX_REDIRECT_URI_LENGTH: usize = 8192; |
||||
|
|
||||
|
/// Number of sharded cookie suffixes to look for, `-0` through `-19`.
|
||||
|
///
|
||||
|
/// Cloudflare Access splits its auth JWT across numbered cookies when the token outgrows the
|
||||
|
/// per-cookie size limit, so reading only the unsuffixed name would miss the token entirely.
|
||||
|
const MAX_SHARD_COUNT: usize = 20; |
||||
|
|
||||
|
/// Returns the routes this module serves.
|
||||
|
///
|
||||
|
/// The caller in `api::core::routes` invokes this only when `SSO_COOKIE_VENDOR_ENABLED` is true,
|
||||
|
/// so the endpoint does not exist on installs that leave the feature off.
|
||||
|
pub fn routes() -> Vec<Route> { |
||||
|
routes![sso_cookie_vendor] |
||||
|
} |
||||
|
|
||||
|
/// Returns the HTML error page for `status_code`, in the format the Bitwarden server uses.
|
||||
|
///
|
||||
|
/// A browser renders this response, not an API client, so the page tells the user to return to the
|
||||
|
/// app rather than describing why the lookup failed.
|
||||
|
fn error_html(status_code: u16) -> Html<String> { |
||||
|
Html(format!( |
||||
|
"<!DOCTYPE html><html lang=\"en\"><head><meta charset=\"utf-8\"><title>Error</title></head>\ |
||||
|
<body><p>Error code {status_code}. Please return to the Bitwarden app and try again.</p></body></html>" |
||||
|
)) |
||||
|
} |
||||
|
|
||||
|
/// Vends the reverse proxy's auth cookie to the calling app as a `bitwarden://` deep link.
|
||||
|
///
|
||||
|
/// The browser arrives at `GET /api/sso-cookie-vendor` after the proxy has authenticated the user,
|
||||
|
/// so the request already carries the proxy's cookie. The response is a 302 to
|
||||
|
/// `bitwarden://sso-cookie-vendor?<cookie-name>=<value>&d=1`, which the operating system hands to
|
||||
|
/// the Bitwarden app. The `d=1` parameter is the sentinel Bitwarden's clients look for.
|
||||
|
///
|
||||
|
/// # Errors
|
||||
|
///
|
||||
|
/// Every failure renders an HTML page rather than a JSON body, because a browser displays it:
|
||||
|
///
|
||||
|
/// - 500 when `SSO_COOKIE_VENDOR_COOKIE_NAME` is empty. Config validation rejects that combination
|
||||
|
/// at startup and on admin-panel updates, so reaching it means the config was bypassed.
|
||||
|
/// - 404 when the request carries neither the cookie nor any of its shards. This is the response
|
||||
|
/// an unconfigured Bitwarden server gives, and the clients already handle it.
|
||||
|
/// - 400 when the deep link would exceed `MAX_REDIRECT_URI_LENGTH`.
|
||||
|
#[get("/sso-cookie-vendor")] |
||||
|
fn sso_cookie_vendor(cookies: &CookieJar<'_>) -> Result<Redirect, (Status, Html<String>)> { |
||||
|
let cookie_name = CONFIG.sso_cookie_vendor_cookie_name(); |
||||
|
|
||||
|
if cookie_name.is_empty() { |
||||
|
return Err((Status::InternalServerError, error_html(500))); |
||||
|
} |
||||
|
|
||||
|
// Copy the relevant cookies out of the jar so that link building stays a plain function over a
|
||||
|
// map, which the tests below can drive without standing up a request.
|
||||
|
let mut cookie_map = HashMap::new(); |
||||
|
if let Some(cookie) = cookies.get(&cookie_name) { |
||||
|
cookie_map.insert(cookie_name.clone(), cookie.value().to_owned()); |
||||
|
} |
||||
|
for i in 0..MAX_SHARD_COUNT { |
||||
|
let shard_name = format!("{cookie_name}-{i}"); |
||||
|
if let Some(cookie) = cookies.get(&shard_name) { |
||||
|
cookie_map.insert(shard_name, cookie.value().to_owned()); |
||||
|
} |
||||
|
} |
||||
|
|
||||
|
let redirect_uri = build_redirect_uri(&cookie_name, &cookie_map)?; |
||||
|
|
||||
|
// Measured on the finished link rather than on the raw cookie, because percent-encoding and
|
||||
|
// the shard names both count against what the app has to receive.
|
||||
|
if redirect_uri.len() > MAX_REDIRECT_URI_LENGTH { |
||||
|
return Err((Status::BadRequest, error_html(400))); |
||||
|
} |
||||
|
|
||||
|
Ok(Redirect::found(redirect_uri)) |
||||
|
} |
||||
|
|
||||
|
/// Builds the `bitwarden://` deep link from the cookies found on the request.
|
||||
|
///
|
||||
|
/// An unsuffixed cookie wins over any shards, matching the Bitwarden server. When only shards are
|
||||
|
/// present, every shard found is forwarded in ascending suffix order so the app can reassemble the
|
||||
|
/// token. The counting loop, not the map's iteration order, is what makes that order deterministic.
|
||||
|
///
|
||||
|
/// # Errors
|
||||
|
///
|
||||
|
/// Returns 404 and an HTML error page when neither the unsuffixed cookie nor any shard is present.
|
||||
|
fn build_redirect_uri(cookie_name: &str, cookies: &HashMap<String, String>) -> Result<String, (Status, Html<String>)> { |
||||
|
if let Some(value) = cookies.get(cookie_name) { |
||||
|
let encoded_value = url_encode(value); |
||||
|
return Ok(format!("bitwarden://sso-cookie-vendor?{cookie_name}={encoded_value}&d=1")); |
||||
|
} |
||||
|
|
||||
|
let mut shards: Vec<(String, String)> = Vec::new(); |
||||
|
for i in 0..MAX_SHARD_COUNT { |
||||
|
let shard_name = format!("{cookie_name}-{i}"); |
||||
|
if let Some(value) = cookies.get(&shard_name) { |
||||
|
shards.push((shard_name, url_encode(value))); |
||||
|
} |
||||
|
} |
||||
|
|
||||
|
if shards.is_empty() { |
||||
|
return Err((Status::NotFound, error_html(404))); |
||||
|
} |
||||
|
|
||||
|
let params: Vec<String> = shards.into_iter().map(|(name, value)| format!("{name}={value}")).collect(); |
||||
|
Ok(format!("bitwarden://sso-cookie-vendor?{}&d=1", params.join("&"))) |
||||
|
} |
||||
|
|
||||
|
/// Percent-encodes a cookie value for the deep link's query string.
|
||||
|
///
|
||||
|
/// Uses `application/x-www-form-urlencoded` serialization so a value containing `&` or `=` cannot
|
||||
|
/// be read by the receiving app as an extra query parameter.
|
||||
|
fn url_encode(value: &str) -> String { |
||||
|
url::form_urlencoded::byte_serialize(value.as_bytes()).collect() |
||||
|
} |
||||
|
|
||||
|
#[cfg(test)] |
||||
|
mod tests { |
||||
|
//! The tests drive `build_redirect_uri` directly rather than the route, because the route needs a
|
||||
|
//! live `CookieJar` and the configured cookie name. The status codes the route maps these
|
||||
|
//! results to are documented on `sso_cookie_vendor`.
|
||||
|
|
||||
|
use super::*; |
||||
|
|
||||
|
#[test] |
||||
|
fn test_url_encode_simple() { |
||||
|
assert_eq!(url_encode("abc123"), "abc123"); |
||||
|
} |
||||
|
|
||||
|
#[test] |
||||
|
fn test_url_encode_special_chars() { |
||||
|
let encoded = url_encode("eyJhbGci.test=value&other"); |
||||
|
assert!(encoded.contains("eyJhbGci.test")); |
||||
|
assert!(encoded.contains("%3D")); |
||||
|
assert!(encoded.contains("%26")); |
||||
|
} |
||||
|
|
||||
|
#[test] |
||||
|
fn test_error_html_format() { |
||||
|
let html = error_html(404); |
||||
|
let content = html.0; |
||||
|
assert!(content.contains("<!DOCTYPE html>")); |
||||
|
assert!(content.contains("Error code 404")); |
||||
|
assert!(content.contains("Please return to the Bitwarden app and try again.")); |
||||
|
} |
||||
|
|
||||
|
#[test] |
||||
|
fn test_error_html_500() { |
||||
|
let html = error_html(500); |
||||
|
assert!(html.0.contains("Error code 500")); |
||||
|
} |
||||
|
|
||||
|
#[test] |
||||
|
fn test_error_html_400() { |
||||
|
let html = error_html(400); |
||||
|
assert!(html.0.contains("Error code 400")); |
||||
|
} |
||||
|
|
||||
|
#[test] |
||||
|
fn test_single_cookie_found() { |
||||
|
let mut cookies = HashMap::new(); |
||||
|
cookies.insert("CF_Authorization".to_string(), "jwt_token_value".to_string()); |
||||
|
|
||||
|
let result = build_redirect_uri("CF_Authorization", &cookies); |
||||
|
assert!(result.is_ok()); |
||||
|
let uri = result.unwrap(); |
||||
|
assert_eq!(uri, "bitwarden://sso-cookie-vendor?CF_Authorization=jwt_token_value&d=1"); |
||||
|
} |
||||
|
|
||||
|
#[test] |
||||
|
fn test_sharded_cookies_found() { |
||||
|
let mut cookies = HashMap::new(); |
||||
|
cookies.insert("CF_Authorization-0".to_string(), "part0".to_string()); |
||||
|
cookies.insert("CF_Authorization-1".to_string(), "part1".to_string()); |
||||
|
cookies.insert("CF_Authorization-2".to_string(), "part2".to_string()); |
||||
|
|
||||
|
let result = build_redirect_uri("CF_Authorization", &cookies); |
||||
|
assert!(result.is_ok()); |
||||
|
let uri = result.unwrap(); |
||||
|
assert!(uri.starts_with("bitwarden://sso-cookie-vendor?")); |
||||
|
assert!(uri.contains("CF_Authorization-0=part0")); |
||||
|
assert!(uri.contains("CF_Authorization-1=part1")); |
||||
|
assert!(uri.contains("CF_Authorization-2=part2")); |
||||
|
assert!(uri.ends_with("&d=1")); |
||||
|
} |
||||
|
|
||||
|
#[test] |
||||
|
fn test_single_cookie_preferred_over_shards() { |
||||
|
let mut cookies = HashMap::new(); |
||||
|
cookies.insert("CF_Authorization".to_string(), "single_value".to_string()); |
||||
|
cookies.insert("CF_Authorization-0".to_string(), "shard0".to_string()); |
||||
|
cookies.insert("CF_Authorization-1".to_string(), "shard1".to_string()); |
||||
|
|
||||
|
let result = build_redirect_uri("CF_Authorization", &cookies); |
||||
|
assert!(result.is_ok()); |
||||
|
let uri = result.unwrap(); |
||||
|
// The unsuffixed cookie wins, and no shard reaches the link.
|
||||
|
assert_eq!(uri, "bitwarden://sso-cookie-vendor?CF_Authorization=single_value&d=1"); |
||||
|
assert!(!uri.contains("CF_Authorization-0")); |
||||
|
} |
||||
|
|
||||
|
#[test] |
||||
|
fn test_cookie_not_found_returns_404() { |
||||
|
let cookies = HashMap::new(); |
||||
|
|
||||
|
let result = build_redirect_uri("CF_Authorization", &cookies); |
||||
|
assert!(result.is_err()); |
||||
|
let (status, html) = result.unwrap_err(); |
||||
|
assert_eq!(status, Status::NotFound); |
||||
|
assert!(html.0.contains("Error code 404")); |
||||
|
} |
||||
|
|
||||
|
#[test] |
||||
|
fn test_oversize_cookie_exceeds_uri_limit() { |
||||
|
let mut cookies = HashMap::new(); |
||||
|
// A cookie long enough to push the finished link past the cap.
|
||||
|
let long_value = "x".repeat(MAX_REDIRECT_URI_LENGTH + 1); |
||||
|
cookies.insert("CF_Authorization".to_string(), long_value); |
||||
|
|
||||
|
let result = build_redirect_uri("CF_Authorization", &cookies); |
||||
|
assert!(result.is_ok()); |
||||
|
let uri = result.unwrap(); |
||||
|
// Building succeeds. The 400 comes from `sso_cookie_vendor`, which applies the cap.
|
||||
|
assert!(uri.len() > MAX_REDIRECT_URI_LENGTH); |
||||
|
} |
||||
|
|
||||
|
#[test] |
||||
|
fn test_cookie_value_url_encoded() { |
||||
|
let mut cookies = HashMap::new(); |
||||
|
cookies.insert("CF_Authorization".to_string(), "value with spaces&special=chars".to_string()); |
||||
|
|
||||
|
let result = build_redirect_uri("CF_Authorization", &cookies); |
||||
|
assert!(result.is_ok()); |
||||
|
let uri = result.unwrap(); |
||||
|
assert!(!uri.contains(" ")); |
||||
|
assert!(uri.contains("value+with+spaces%26special%3Dchars")); |
||||
|
} |
||||
|
|
||||
|
#[test] |
||||
|
fn test_sharded_cookies_ordered() { |
||||
|
let mut cookies = HashMap::new(); |
||||
|
// Inserted out of order: the link must still come back in suffix order.
|
||||
|
cookies.insert("CF_Authorization-2".to_string(), "part2".to_string()); |
||||
|
cookies.insert("CF_Authorization-0".to_string(), "part0".to_string()); |
||||
|
cookies.insert("CF_Authorization-1".to_string(), "part1".to_string()); |
||||
|
|
||||
|
let result = build_redirect_uri("CF_Authorization", &cookies); |
||||
|
assert!(result.is_ok()); |
||||
|
let uri = result.unwrap(); |
||||
|
// Shards appear as 0, 1, 2 whatever order the map yields them in.
|
||||
|
let q = uri.find("CF_Authorization-0").unwrap(); |
||||
|
let r = uri.find("CF_Authorization-1").unwrap(); |
||||
|
let s = uri.find("CF_Authorization-2").unwrap(); |
||||
|
assert!(q < r); |
||||
|
assert!(r < s); |
||||
|
} |
||||
|
|
||||
|
#[test] |
||||
|
fn test_d_sentinel_always_present() { |
||||
|
let mut cookies = HashMap::new(); |
||||
|
cookies.insert("MyAuth".to_string(), "val".to_string()); |
||||
|
|
||||
|
let result = build_redirect_uri("MyAuth", &cookies); |
||||
|
let uri = result.unwrap(); |
||||
|
assert!(uri.ends_with("&d=1")); |
||||
|
} |
||||
|
} |
||||
Loading…
Reference in new issue