Run beside the PHP app you are leaving.

The compat-php add-in reads and writes a PHP application’s sessions, encrypted cookies, cache values, queued jobs and $2y$ password hashes — so both can serve the same users while you move routes across. Use it to migrate, not to stay.

Read the Compatibility docs

compat_php example output: a shared key, a PHP session adopted, CSRF, shared cache, PHP unserialize, a refresh token and a passkey.

What you get

Adopt the PHP app’s session cookie and read its session store.
Decrypt and issue its encrypted cookies with the same key ring.
Read cache values and queued jobs it wrote.
Verify its bcrypt $2y$ hashes, and upgrade them when needs_rehash says so.

In the docs

Compatibility

src/app/http/kernel.rs

// Running beside the PHP application you are moving off: adopt its session
// cookie, read its session store, accept its encrypted XSRF token.
pub fn web() -> MiddlewareStack {
    let mut web = groups::web();
    web.push(AdoptForeignSession::new("app_session", "rainier_session"))
       .push(StartSession::with_config(foreign_store(), config().cookie("rainier_session")))
       .push(VerifyCsrfToken::new().codec(Arc::new(EncryptedXsrf::new(cookies()))));
    web
}

// The same APP_KEY ring, so its encrypted cookies decrypt here too.
let keys = KeyRing::from_base64(current, &previous)?;

Up close

Select an image to see it full size.

compat_php output: a PHP session adopted with its flash message, and a PHP-issued CSRF token accepted while a forged one gets 419. — A user signed in on the PHP side is signed in here, flash data included; the PHP CSRF token works and a forged one is a 419.

compat_php output: shared cache values read, and a PHP serialized object read without instantiating anything. — PHP cache values and serialized objects are read as data; nothing is instantiated.

All features