Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Self-hosted web view login cookie check fails for usernames containing `@` or spaces

Open Beginner friendly
  • Is something wrong?
#26,115 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
ios, objective-c, swift
Domain
authentication, mobile, mobile-dev

Research direction

Start in WordPress/Classes/Utility/WebViewController/CookieJar.swift at HTTPCookie.isWordPressLoggedIn(username:), which currently takes everything before the first % as the username. Percent-decode the cookie value (PHP also maps spaces to +) and split on |, matching isWordPressLoggedInAtomic(username:). Confirm AuthenticationService.loadAuthCookiesForSelfHosted no longer re-POSTs to wp-login.php for usernames like [email protected] and john doe.

Written by the indexing model from the issue text.

Description

[Type] Bug Self-hosted Webviews

Found while reviewing #26103. Pre-existing — not introduced by that PR, and unchanged by #26106 and #26104.

The logged-in cookie check for self-hosted sites never matches when the username contains a character that PHP URL-encodes, so the app logs in again before every authenticated web view load.

Root cause

HTTPCookie.isWordPressLoggedIn(username:) takes the username to be everything before the first % in the cookie value:

https://github.com/wordpress-mobile/WordPress-iOS/blob/3db37280b4bd84f1cc4e68526f84c35d507149a6/WordPress/Classes/Utility/WebViewController/CookieJar.swift#L156-L159

WordPress sets the cookie value to username|expiration|token|hmac and PHP's setcookie() URL-encodes it, so the check relies on the first | arriving as %7C. An encoded character inside the username breaks that:

Username Cookie value Parsed username Match
admin admin%7C… admin ✅
[email protected] user%40example.com%7C… user ❌
john doe john+doe%7C… john+doe ❌

Impact

AuthenticationService.loadAuthCookiesForSelfHosted treats a failed check as "no cookie" and POSTs the username and password to wp-login.php again:

https://github.com/wordpress-mobile/WordPress-iOS/blob/3db37280b4bd84f1cc4e68526f84c35d507149a6/WordPress/Classes/Services/AuthenticationService.swift#L31-L40

This affects sites that RequestAuthenticator authenticates with .siteLogin credentials. The login itself still succeeds, so the cost is an extra login round-trip — and a new session on the site — before each authenticated load, rather than a visible failure.

WordPress.com usernames are normally limited to lowercase letters and numbers, so the same predicate is not expected to misfire on the WordPress.com path.

Verification

Confirmed with a Foundation probe (macOS 27.0.1): HTTPCookie.cookies(withResponseHeaderFields:for:) keeps the value percent-encoded, and the predicate returns false for [email protected] and john doe.

The cookie values in the probe were built from WordPress's cookie format. We have not reproduced this against a live self-hosted site.

Suggested fix

Percent-decode the value before parsing — PHP's urlencode also turns spaces into + — and split on |, as isWordPressLoggedInAtomic(username:) already does.

Dominant language
Swift
Stars
3.9k
Forks
1.2k
Avg merge
1d 18h
Merged PRs (30d)
56

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from wordpress-mobile/WordPress-iOS

All issues in wordpress-mobile/WordPress-iOS

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.