Update cookies with their newly named values

[StayBlue]

I noticed this while trying to log in. The cookie stored in my local storage was different from the one referenced within the configuration. I ignored this initially and just put the values that I thought each value in the configuration was referencing:

ltmid_v2 -> account_mid_v2
ltoken_v2 -> cookie_token_v2

This didn't work and gave me a "Please login" error message:

{"retcode":10001,"message":"Please login","res":{"data":null,"message":"Please login","retcode":10001}}

Eventually, I figured out that this might be related to what I ignored earlier, and after changing the values to represent the ones I saw in my local storage, the login worked without issues.

[torikushiii]

Have you tried logging in using incognito mode as suggested in the guide to check for the missing values?

Unfortunately, using ltoken_v2 and ltmid_v2 values won't work globally for some features. If someone want to use code redeem feature while using these values, it will result in an error. However, they should work fine for checking-in and notes, if I'm not mistaken.

[StayBlue]

Have you tried logging in using incognito mode as suggested in the guide to check for the missing values?

Unfortunately, using ltoken_v2 and ltmid_v2 values won't work globally for some features. If someone want to use code redeem feature while using these values, it will result in an error. However, they should work fine for checking-in and notes, if I'm not mistaken.

To make my life simpler, I'll call all the cookies that start with cookie and account as "account cookies," and the ones that start with the letter l as "l-value cookies"

I was wondering how such a change to the values could've been made in such a short period of time without logging me out of my existing sessions. Logging in through an incognito window did show the key that I presumably missed before. After doing some digging, I've found something interesting.

First, all of the values are stored inside your browser when you log in. Second, depending on the endpoint, the client might opt to send different cookies with the request. For example, redeeming a code uses account cookies. When going to the profile page to grab the cookie, as suggested in the Gist linked in the README, it uses l-value cookies. It also uses l-value cookies when checking in (at least for HSR; I'm not sure about the rest).

This is all to say that it might be worthwhile sending the cookies that the client (aka the website) sends, given that the user might get flagged (or something along those lines) if you send the wrong cookie, even if it is at the expense of user convenience.

[torikushiii]

I think I could see your point.

To address the issue, I can either:

1. Merge this pull request and add an extra property to the default config file for the required token, allowing people who want to automatically redeem codes to do so. This way, the necessary cookie request can be saved and split into their respective requests.

2. Alternatively, I can ask people to provide their entire cookie in the default config file, which would look like this:

default.config.js

{
	id: 2,
	active: true,
	type: "genshin",
	data: [
		{
			cookie: "mi18nLang=xxxx; _MHYUUID=xxxx; HYV_LOGIN_PLATFORM_OPTIONAL_AGREEMENT=xxxx; e_nap_token=xxxx; cookie_token_v2=xxxx; account_mid_v2=xxxx; account_id_v2=xxxx; ltoken_v2=xxxx; ltmid_v2=xxxx; ltuid_v2=xxxx; HYV_LOGIN_PLATFORM_LOAD_TIMEOUT=xxxx; DEVICEFP_SEED_ID=xxxx; DEVICEFP_SEED_TIME=xxxx; DEVICEFP=xxxx; HYV_LOGIN_PLATFORM_TRACKING_MAP=xxxx; HYV_LOGIN_PLATFORM_LIFECYCLE_ID=xxxx",
			redeemCode: false,
			dailiesCheck: true,
			weekliesCheck: true,
			stamina: {
				check: false,
				threshold: 150,
				persistent: false
			},
			expedition: {
				check: false,
				persistent: false
			}
		}
	]
}

I will then parse each required cookie properly in this class: https://github.com/torikushiii/hoyolab-auto/blob/main/hoyolab-modules/template.js and save them for the required requests

[StayBlue]

I think I could see your point.

To address the issue, I can either:

1. Merge this pull request and add an extra property to the default config file for the required token, allowing people who want to automatically redeem codes to do so. This way, the necessary cookie request can be saved and split into their respective requests.

2. Alternatively, I can ask people to provide their entire cookie in the default config file, which would look like this:

default.config.js

{
	id: 2,
	active: true,
	type: "genshin",
	data: [
		{
			cookie: "mi18nLang=xxxx; _MHYUUID=xxxx; HYV_LOGIN_PLATFORM_OPTIONAL_AGREEMENT=xxxx; e_nap_token=xxxx; cookie_token_v2=xxxx; account_mid_v2=xxxx; account_id_v2=xxxx; ltoken_v2=xxxx; ltmid_v2=xxxx; ltuid_v2=xxxx; HYV_LOGIN_PLATFORM_LOAD_TIMEOUT=xxxx; DEVICEFP_SEED_ID=xxxx; DEVICEFP_SEED_TIME=xxxx; DEVICEFP=xxxx; HYV_LOGIN_PLATFORM_TRACKING_MAP=xxxx; HYV_LOGIN_PLATFORM_LIFECYCLE_ID=xxxx",
			redeemCode: false,
			dailiesCheck: true,
			weekliesCheck: true,
			stamina: {
				check: false,
				threshold: 150,
				persistent: false
			},
			expedition: {
				check: false,
				persistent: false
			}
		}
	]
}

I will then parse each required cookie properly in this class: https://github.com/torikushiii/hoyolab-auto/blob/main/hoyolab-modules/template.js and save them for the required requests

The latter of the two options seems to be better for convenience's sake. I can also look into updating this PR to align with what you were looking to do with the former, but I'll leave it up to you.

[torikushiii]

I will do the latter since it's easier for everyone, rather than going through multiple steps to find their specific cookies.

Regarding this PR, I will close it and will do it myself since it will change almost the entire codebase, mainly the request codes. Thank you for your insight and detailed explanation on how to approach the requests.