Feature - Rejected Prevent mixing requests from different characters

Linknoid

Member
I'll start off by saying this is pretty much a result of user error. However, the consequences of this user error are disproportionate to the mistake I made. I've had this happen twice now, and I imagine I'll probably make the mistake again in the future. I know it's my fault, but I don't know how to prevent myself from ever making this mistake again.

If you open KoLmafia, it binds to a local port, and the relay browser talks on that port. KoLmafia assumes that any requests coming in on that port are directed to the current session, even if they're from a different session.

I often have multiple tabs open, and I'm lazy about closing tabs for sessions that have already ended. I usually log out from the "General" tab in KoLmafia, rather than the logout button in the relay browser, which leaves the relay browser tab for that session open.

I've never really had any serious issues from doing this, except this one: if you go into combat from a tab that was logged in with a different character, all 12 combat action bars for your current character get permanently replaced by the combat action bars for the character that was previously logged in on that tab.

It's probably technically a bug in KoL to completely replace the action bars like that. Or maybe not. But it's not really KoL's fault, because it's being used outside of it's design: if you don't use KoLmafia, you could never accidentally trigger that behavior. And it's not really KoLmafia's fault, because it's just passing along requests made by the relay browser. So really it's the user's fault for sending a request from a different session. But losing up to 12 bars of carefully configured buttons in exchange for accidentally clicking the wrong tab is really dangerous behavior.

I have a few ideas of how this could be avoided, but of course the developers might have better ideas on preventing this:

1. Bind KoLmafia to a new port each time you log in. Existing browser sessions would simply fail to connect.
2. Somehow detect that the character that generated the request in the relay browser is not the one that KoLmafia is logged in as, using existing request data.
3. Inject a KoLmafia generated cookie into all responses sent to the relay browser, and refuse to honor browser requests that don't include that cookie.
 

Linknoid

Member
This feature could be something optional that you have to turn on. I don't want to break anyone's existing usage. And it wouldn't have to completely lock you out of sending requests from the wrong session, it could simply show a warning page you have to click through.
 

philmasterplus

Active member
Randomizing ports would also defeat the browser image cache. There was discussion in the ASS discord about removing KoLmafia's built-in image cache (since it consumes a fair bit of memory) and relying on the browser cache.

Using cookies sounds nice, if it works. HTTP cookies have always been something of a mystery to me.
 

Veracity

Developer
Staff member
There was discussion in the ASS discord about removing KoLmafia's built-in image cache (since it consumes a fair bit of memory) and relying on the browser cache.
That's not going to happen in the official source. The license allows to fork the source and make personal changes to your heart's content, though.

Probably simpler to just do this:

Code:
set useImageCache=false
 

fronobulax

Developer
Staff member
My recollection is that mafia started caching images when there was a desire to override images with something other than what KoL served. It also serves as a mechanism for KoLmafia to have its own images.

I will note that I routinely run two characters in the relay browser and I have never seen anything like this. I also have never customized the combat action bars and 90% of my bar button pressing is Script or Attack which don't vary. While I don't doubt that this is a real problem, I'm not sure what fix would be easier than training users "Don't Do That".
 

Linknoid

Member
After thinking about it more:

1. Different ports won't work in general for reasons already discussed.
2. There's nothing unique per-character about the requests, so there's nothing to differentiate.
3. A cookie based solution won't work, since you don't get unique cookies per-tab, so the wrong tab will pass exactly the same cookie as the right tab.
4. Another idea I can come up with would be changing the base URL so instead of http://127.0.0.1:60080/ it would use http://127.0.0.1:60080/charactername/. But that probably won't work because it would break rooted URLs, i.e. /choice.php vs choice.php

I'm fond of the "Don't Do That" solution, and wish I could train myself to never make mistakes :) It would be far less likely to be a problem with 2 characters, but it's much easier to lose track of what you're doing when trying to manage 5 in quick succession.

I keep quite a few bars worth of actions that took quite some time to assemble, something along these lines:

1. Main bar, frequently changes
2. Free kills and copiers
3. Stuns and staggers
4. 334/33398/etc. scrolls, perpetual damage items (like bag of gross foreign snacks)
5. Reusable combat items and mercenary ammo
6. El Vibrato spheres (for LT&T El Vibrato boss) and items to funksling with them
7. Cheap variety of combat items (for LT&T granny boss, who won't let you repeat an item)
 

lostcalpolydude

Developer
Staff member
As described here, you can retrieve the data you have in your combat action bars. Then, if anything wipes them out, you can reload from your saved data.
 

Linknoid

Member
That's excellent. Being able to back up the data is a practical enough solution, and it doesn't risk breaking anything in KoL or KoLmafia or generate any extra work for anyone. I think this feature request can be closed as impractical.
 

xKiv

Active member
After thinking about it more:

4. Another idea I can come up with would be changing the base URL so instead of http://127.0.0.1:60080/ it would use http://127.0.0.1:60080/charactername/. But that probably won't work because it would break rooted URLs, i.e. /choice.php vs choice.php

I think that's what head/base@href is for:

Code:
<head>
  <base href="http://127.0.0.1:60080/charactername/">
</head>

But it could still break full URLs, and also possibly any kol-side javascript that would want to manipulate/parse URLs directly.
 
Top