@idosgames/core 0.8.0 → 0.9.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +59 -0
- package/dist/index.cjs +2 -2
- package/dist/index.d.cts +259 -16
- package/dist/index.d.ts +259 -16
- package/dist/index.js +2 -2
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -14,6 +14,65 @@ and this project follows [Semantic Versioning](https://semver.org/spec/v2.0.0.ht
|
|
|
14
14
|
|
|
15
15
|
## [Unreleased]
|
|
16
16
|
|
|
17
|
+
## [0.9.0] - 2026-08-24
|
|
18
|
+
|
|
19
|
+
Signing in by e-mail becomes a **two-step flow** with a confirmation code, and a password now
|
|
20
|
+
belongs to a **title**, not to the platform. Friend requests gain the outgoing direction, and the
|
|
21
|
+
usage history is rolled up into periods. Breaking — see below.
|
|
22
|
+
|
|
23
|
+
### Breaking
|
|
24
|
+
|
|
25
|
+
- **`registerWithEmail` no longer signs the player in.** It returns `EmailRegistrationOutcome`
|
|
26
|
+
(`codeTtlMinutes`, `resendCooldownSeconds`) instead of `ClientState`: the server only stores the
|
|
27
|
+
attempt and mails a code, and the player is created by `confirmEmailRegistration`. A screen that
|
|
28
|
+
waits for a session here waits forever. There is no flag to branch on — confirmation is platform
|
|
29
|
+
behaviour and no title can switch it off.
|
|
30
|
+
- **`EMAIL_ALREADY_EXISTS` is no longer returned by registration.** A free and a taken address
|
|
31
|
+
answer identically, so the form cannot be used to ask "does this person have an account here";
|
|
32
|
+
the owner of a taken address gets a "you already have an account" e-mail instead, without a code.
|
|
33
|
+
- **`loginWithPlatformToken` and `AuthenticationAction.LoginWithPlatformToken` removed.** The
|
|
34
|
+
backend stopped issuing the audience it accepted, so the endpoint was unreachable code. Use
|
|
35
|
+
`loginWithSsoCode` (see `beginSsoRedirect`).
|
|
36
|
+
- **`UserReferralState.FollowerIDs` removed.** It was an unbounded list in the hot player document
|
|
37
|
+
with no readers; the count that replaced it is server-sent, and the relationship itself lives on
|
|
38
|
+
the subscriber's side.
|
|
39
|
+
|
|
40
|
+
### Added
|
|
41
|
+
|
|
42
|
+
- **`confirmEmailRegistration(email, code)`** — exchanges the mailed code for a session and creates
|
|
43
|
+
the player. Persists the credentials for `autoLogin()` exactly as `loginWithEmail` does; the
|
|
44
|
+
password comes from step one and is never sent again.
|
|
45
|
+
- **`resendVerificationCode(email)`** — mails a NEW code (only a hash is stored server-side, so the
|
|
46
|
+
previous one cannot be re-sent). Answers successfully whatever happened, with one exception worth
|
|
47
|
+
surfacing: `EMAIL_SENDER_NOT_CONFIGURED`, which is about the server's configuration and not about
|
|
48
|
+
the address.
|
|
49
|
+
- **`zEmailRegistrationResponse` / `EmailRegistrationResponse`** and
|
|
50
|
+
`AuthenticationRequest.VerificationCode`.
|
|
51
|
+
- **`client.social.getOutgoingRequests()`** + `SocialAction.GetOutgoingRequests` and the
|
|
52
|
+
`social:outgoingRequestsLoaded` event. Direction and status are separate axes, and the outgoing
|
|
53
|
+
list cannot be derived from a counter — without it the "Sent" mark on a card lived only until the
|
|
54
|
+
app restarted.
|
|
55
|
+
- **`UserSocialState.FriendsCount` / `IncomingCount` / `OutgoingCount`** — server-sent counters.
|
|
56
|
+
The friend lists themselves are now a local cache, filled by the matching `get*` call.
|
|
57
|
+
- **`UsagePeriodRecord`** — the rolled-up month/year record (`Seconds`, `Sessions`, `ActiveDays`,
|
|
58
|
+
`LongestSessionSeconds`, `ActiveHoursMask`, `FirstActiveDay`).
|
|
59
|
+
- **`BoardRollResponse.DiceValues`** — the individual dice behind the rolled total.
|
|
60
|
+
|
|
61
|
+
### Changed
|
|
62
|
+
|
|
63
|
+
- ⚠ **A password now belongs to the TITLE.** The same address in two games means two independent
|
|
64
|
+
passwords, and resetting in one game does not change the login for the other. The reset e-mail
|
|
65
|
+
goes out through the **publisher's** SMTP, so a shared password would let one publisher's mail
|
|
66
|
+
server control access to every other publisher's game. The identity stays shared — Google, Apple
|
|
67
|
+
and the idosgames.com sign-in still recognise the same person everywhere; identity answers "who
|
|
68
|
+
is this", not "what proves they may sign in". Don't tell the player "the same password as in your
|
|
69
|
+
other game", and don't reuse stored credentials across titles.
|
|
70
|
+
- **Every outcome of `resetPassword` answers the same** — `INVALID_RESET_CODE` for an unknown
|
|
71
|
+
address, a code never requested, an expired code and a wrong code alike; an exhausted code
|
|
72
|
+
answers `RESET_CODE_ATTEMPTS_EXCEEDED`. The remaining-attempt count is gone from the response: it
|
|
73
|
+
confirmed the account existed and told an attacker how much room was left. Don't parse a number
|
|
74
|
+
out of `error`.
|
|
75
|
+
|
|
17
76
|
## [0.7.0] - 2026-08-10
|
|
18
77
|
|
|
19
78
|
Real-money payment support. Every configured price becomes a **`PriceOptions` dictionary**, a
|