axum-extra - cookie not being updated up on response but I can see it in the headers

[yatesco]

Hi there,

I'm using private-cookie from axum-extra and following the example at https://docs.rs/axum-extra/latest/axum_extra/extract/struct.PrivateCookieJar.html. I can see (in Chrome) the request and response contain the cookie/set-cookie headers, but any updates to the cookie aren't persisted on the next request.

1. request 1 - cookie is empty so a default is set and returned
2. request 2 - the client POSTS an update
3. server picks up the existing cookie, updates it and returns it
4. request 3 - the client POSTS another update
5. server opens the jar but the state doesn't include the update in step 3 - it is still the default value

I have no other extractors, but I do have another Extension which adds in some other state.

Relevant code:

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    // build our application with some routes
    // let app = Router::new().route("/greet/:name", get(greet));
    let app = Router::new()
        .route("/", get(root))
        .route("/expand/:id", post(toggle_expand))
        .layer(extract::Extension(reference_data))
        .layer(Extension(key));
...
}

async fn root(
    jar: PrivateCookieJar,
    Extension(rd): Extension<Arc<RwLock<reference_data_domain::ReferenceData>>>,
) -> impl IntoResponse {
    let state = get_state(&jar);
    render_root(state, jar, rd.clone())
}

async fn toggle_expand(
    jar: PrivateCookieJar,
    Path(id): Path<usize>,
    Extension(rd): Extension<Arc<RwLock<reference_data_domain::ReferenceData>>>,
) -> impl IntoResponse {
    let mut state = get_state(&jar);
   // *** MAKE A CHANGE TO THE STATE
    render_root(state, jar, rd.clone())
}

fn render_root(
    state: api::State, 
    jar: PrivateCookieJar,
    rd: Arc<RwLock<reference_data_domain::ReferenceData>>,
) -> (PrivateCookieJar, maud::Markup) {
    dbg!(&state); // *** THIS SHOWS THE UPDATED STATE ***/
    let jar = set_state(jar, &state);
    let markup = html! {
        (DOCTYPE)
            meta charset="utf-8";
          ....
        }
    };
    (jar, markup)
}

fn get_state(jar: &PrivateCookieJar) -> api::State {
    let value: Option<String> = jar
        .get("qfi-pj-ui")
        .map(|cookie| cookie.value().to_owned());
    println!("cookie value: {:?}", &value); // *** FIRST TIME IS EMPTY BUT THEN ALWAYS SHOWS DEFAULT VALUE ***
    let state = match value {
        Some(json) => serde_json::from_str(&json).expect("cannot deserialise from cookie"),
        None => api::State::new(})
    };
    state
}

fn set_state(jar: PrivateCookieJar, state: &api::State) -> PrivateCookieJar {
    let persistent_state = serde_json::to_string(&state).expect("cannot serialise model");
    println!("persisting state: {}", persistent_state); /*** THIS CORRECTLY SHOWS THE UPDATED STATE ***/
    let jar = jar.add(Cookie::new("qfi-pj-ui",persistent_state));
    jar
}

Chrome example of a response:

[jplatte]

How does this post request happen? Is it via navigation, i.e. submitting a form, or is JavaScript involved? Also, is there a small info sign on the right of the set-cookie header in the dev console? The screenshot is cut off on the right.

edit: Conclusion of the discussion below is that the provided app sets multiple values for the same cookie, but with different paths. How the code could be changed to actually be able to update the cookie value is yet unclear, but it's clear that both set-cookie headers are being received and respected by the browser.

[yatesco]

Yes - I somehow need to say "this cookie from /nested/path replaces the cookie from /". I naively thought cookies were scoped to a domain, not a path. TIL.

[jplatte]

No, both are sent, that's what Chromium shows. It might just be a limitation in the cookie crate that it (seemingly) discards the extra occurrence of the same cookie.

[jplatte]

Try setting the path of the cookie explicitly, like in the second example in cookie's docs: https://docs.rs/cookie/latest/cookie/struct.Cookie.html#constructing-a-cookie

[yatesco]

I suspect I need more access to the actual header itself, to define the path the cookie is associated with... I'll keep playing - thanks for your help :-)

[jplatte]

In any case it seems pretty clear that if there is a bug on the server side here, it's the cookie library not allowing you to access multiple values for the same cookie. I'll mark this as answered.

[yatesco]

For anyone keeping track - POSTing to "/" works fine, it is setting the cookie on requests from "/" and "/nested/path" breaks as it sends both cookies back to the server and the one associated with "/" is the one returned by PrivateCookieJar::get.