MLM will not accept changed mam_id

[BumbleBeever]

I changed the session cookie on the website as I was having issues but now MLM will not accept the new mam_id.

On MLM's webpage I get this error: mam_id is invalid, all features are disabled: HTTP status client error (403 Not Authorized) for url (https://www.myanonamouse.net/jsonLoad.php?snatch_summary=true)

It looks like it tries to use the mam_id stored in it's database file, errors out because that one is no longer valid and then tries to use the mam_id from the config file but gets stuck at that point.

These are the log entries when MLM starts:

2026-07-30T10:49:10.917588089+02:00  INFO mlm_db: Migrations started
    at mlm_db/src/lib.rs:199
    in mlm_db::migrate

  2026-07-30T10:49:10.977332972+02:00  INFO mlm_db: Migrations done
    at mlm_db/src/lib.rs:210
    in mlm_db::migrate

  2026-07-30T10:49:10.977586186+02:00  INFO mlm_mam::api: Restoring mam_id
    at mlm_mam/src/api.rs:85

  2026-07-30T10:49:11.108421288+02:00  WARN mlm_mam::api: Stored mam_id failed with HTTP status client error (403 Not Authorized) for url (https://www.myanonamouse.net/jsonLoad.php?snatch_summary=true), falling back to config value
    at mlm_mam/src/api.rs:112

[CampingAvocado]

I tried to reproduce this:

1. Shut down MLM
2. Delete IP-locked session on MaM
3. Create new IP-locked session on MLM, copy new mam_id
4. Paste the new mam_id into MLM config
5. Restart MLM

Logs then show the same as you pasted:

  2026-07-30T11:44:15.831682924+02:00  INFO mlm_db: Migrations started
    at mlm_db/src/lib.rs:199
    in mlm_db::migrate
  2026-07-30T11:44:15.836135459+02:00  INFO mlm_db: Migrations done
    at mlm_db/src/lib.rs:210
    in mlm_db::migrate
  2026-07-30T11:44:15.836284499+02:00  INFO mlm_mam::api: Restoring mam_id
    at mlm_mam/src/api.rs:85
  2026-07-30T11:44:15.925407533+02:00  WARN mlm_mam::api: Stored mam_id failed with HTTP status client error (403 Forbidden) for url (https://www.myanonamouse.net/jsonLoad.php?snatch_summary=true), falling back to config value
    at mlm_mam/src/api.rs:112

But opening MLM, the fallback to the (updated) config value worked; I can e.g. use the search function.

Does this differ from your procedure? I assume you updated the config mam_id value to the most recent one provided by MaM before restarting MLM as well?

[BumbleBeever]

That is exactly what I did. But the MLM webpage still shows that error and locks me out of all functions.
I did change the mam_id before restarting. Even tried both IP and ASN locked mam_id as I am behind a VPN.

I will do some testing to see if I can get any further information.

[BumbleBeever]

I tried a couple of things:
Started MLM with no database file to see if that was the issue. Same result.
I moved the image outside of the VPN to my local IP and remade the cookie for it. Same result.

When I use curl with the mam_id to make the request to https://www.myanonamouse.net/jsonLoad.php?snatch_summary=true inside the docker container I get the expected JSON response.

For now I am stumped, but I will do some more testing later when I have time.

[BumbleBeever]

I figured out what is causing it but not why yet.
I am using Podman instead of Docker to run the instance which should work the same but apparently something is different.

I just tried to run a completely fresh setup of the MLM instance in both Podman and Docker and the Docker instance worked fine but the Podman one does not.
I will use Docker for now while I try to figure out what is causing this.

[CampingAvocado]

Haven't had time to properly look into it but I noticed that the error response I got in my reproduction isn't quite the same (you got (403 Not Authorized), I got (403 Forbidden)).
I ran a diagnosis via LLM and it postulated that MaM may set a domain-scoped Set-Cookie in the 403 response.
On retry this isn't cleared and instead the host-only cookie (mam_id) is just added. With both cookies present MaM then picks the wrong one.

Edit: I've since tried to test the hypothesis and cannot elicit a conflicting cookie from MaM,
so I think the slop-hypothesis was indeed just slop.

Maybe someone else using podman can corroborate whether they also get the issue or I'll try and reproduce with podman myself sometime

[CampingAvocado]

The only way I've been able to reproduce the exact (403) Not Authorized response is by using an old version of MLM that still passes the User Agent header MLM without the version code MLM/5.0.0. Without the version code, MaM explicitly blocks access since older versions don't adhere to their API.

Is it at all possible that your podman setup is somehow still using an old image?