@lunch-money/developer-docs 2.11.2-preview.12 → 2.11.2-preview.13
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.
|
@@ -49,6 +49,8 @@ Open the [new OAuth client form](/oauth/applications/new) in the Developer Porta
|
|
|
49
49
|
|
|
50
50
|
You can own up to 25 non-deleted OAuth clients. If you reach the limit, delete a client you no longer use before registering another.
|
|
51
51
|
|
|
52
|
+
The support email must be confirmed before you can submit the client for review. If it matches your own verified Lunch Money account email, Lunch Money confirms it automatically. For any other address—including one used by another Lunch Money account—Lunch Money sends a confirmation link from `support@lunchmoney.app` to that mailbox. The link is valid for 72 hours, so use an address you can access and follow the link promptly.
|
|
53
|
+
|
|
52
54
|
After registration, record the client ID in your application configuration. A client ID identifies the registration but is not a secret.
|
|
53
55
|
|
|
54
56
|
If you registered a **Confidential web client**, create a client secret from its details page. Lunch Money shows the secret value only once. Copy it immediately into a secret manager or protected server configuration; it cannot be retrieved later. Never commit it or expose it in browser or mobile code.
|
|
@@ -23,7 +23,7 @@ Submitting a client for review is how you make your application authorizable by
|
|
|
23
23
|
Before requesting review, make sure the client has:
|
|
24
24
|
|
|
25
25
|
- an application description, developer name, and logo so users can identify the application and who created it;
|
|
26
|
-
- a monitored support email where users and Lunch Money can reach you;
|
|
26
|
+
- a confirmed, monitored support email where users and Lunch Money can reach you;
|
|
27
27
|
- a publicly accessible homepage URL where users can learn about the application;
|
|
28
28
|
- a publicly accessible privacy policy URL explaining how the application handles user data;
|
|
29
29
|
- at least one eligible redirect URI—a confidential web client needs a non-loopback production HTTPS redirect, while a native client may use a private-use scheme or loopback redirect;
|
|
@@ -40,6 +40,8 @@ Open-source applications are welcome. If your source code is public, include the
|
|
|
40
40
|
|
|
41
41
|
A confidential web client may retain owner-only loopback callbacks alongside its production HTTPS callback, but it still needs a non-loopback production HTTPS redirect before review.
|
|
42
42
|
|
|
43
|
+
Confirm the support email from the mailbox before you submit the client. The Developer Portal's readiness checklist shows whether it is confirmed and prevents submission until it is. If you change the address before approval, Lunch Money clears its confirmation; confirm the new address before the client can be submitted or approved.
|
|
44
|
+
|
|
43
45
|
### Native applications
|
|
44
46
|
|
|
45
47
|
You do not need to create a standalone marketing website for a native application. Its public Apple App Store or Google Play listing can serve as the homepage if it clearly explains what the application does and identifies the developer. A public pre-release listing, project page, or README in a public source-code repository can also work.
|
|
@@ -71,9 +73,11 @@ There is no review comment thread, so use the new request's additional context t
|
|
|
71
73
|
|
|
72
74
|
An `active` client can be authorized by other users. Keep its configuration current in the Developer Portal. You do not need to contact Lunch Money to rename the application, move hosting, or update a support address.
|
|
73
75
|
|
|
74
|
-
Changes save immediately, and the client stays `active`. Redirect URIs,
|
|
76
|
+
Changes save immediately, and the client stays `active`. Redirect URIs, description, and developer name take effect as soon as you save them. An approved confidential web client must keep at least one public HTTPS redirect.
|
|
77
|
+
|
|
78
|
+
Name, logo, support email, homepage URL, and privacy policy URL also save immediately, but Lunch Money users continue to see the last approved identity on the consent screen and Connected Apps page until Lunch Money reviews the update. The Developer Portal shows that as an identity update in review; it is not a return to `rejected`, and existing authorizations keep working.
|
|
75
79
|
|
|
76
|
-
|
|
80
|
+
When you change the support email, confirm the new address before Lunch Money can approve the identity update. Until it is confirmed and approved, users continue to see the previous approved address, and Lunch Money does not send notifications to the new address. Lunch Money tells the previously confirmed support address that the client was changed.
|
|
77
81
|
|
|
78
82
|
Client-secret rotation and revocation remain available subject to lifecycle and security checks. Scopes and client type cannot be changed after registration. A scope change requires a replacement client and user reauthorization.
|
|
79
83
|
|
package/docs/oauth/security.md
CHANGED
|
@@ -65,6 +65,10 @@ The [confidential Node.js sample](/oauth/sample-applications#understand-the-conf
|
|
|
65
65
|
|
|
66
66
|
Choose only the resource scopes needed for expected features. Add `offline_access` only for genuine unattended operation. Remember that scope changes require a replacement client and reauthorization; they cannot be requested dynamically.
|
|
67
67
|
|
|
68
|
+
## Keep the support address confirmed
|
|
69
|
+
|
|
70
|
+
Use a monitored support mailbox that your team controls, and keep it current in the Developer Portal. Lunch Money sends client notifications to a support address only after someone with access to that mailbox confirms it. Changing the address clears its confirmation, so follow the new confirmation link before relying on that mailbox for notifications.
|
|
71
|
+
|
|
68
72
|
## Operate credentials safely
|
|
69
73
|
|
|
70
74
|
Rotate client secrets on a schedule appropriate for your application's risk and immediately when one may have been exposed. A client can have up to three non-revoked secrets, so confirm that it has room before starting a rotation. Expired secrets still count toward this limit until you revoke them. Use overlapping active secrets during a controlled rotation: create the replacement, deploy and verify it, and then revoke the old secret. Coordinate refreshes so two workers do not replay the same rotating token, and atomically persist every complete replacement credential set. Production storage needs database transactions, distributed per-connection locking, recovery when persistence fails, multi-instance coordination, and tenant isolation. Make disconnect invalidate continuing refresh access as well as clear local state.
|
|
@@ -35,7 +35,7 @@ Match on `error` when it is returned, verify `state`, and treat `error_descripti
|
|
|
35
35
|
|
|
36
36
|
Until a client is approved, only its owner may authorize the application. Anyone else is stopped at the consent screen and is never returned to your application, so you will see no callback and no `error` parameter for these attempts.
|
|
37
37
|
|
|
38
|
-
Those users are shown the support email registered with your client so they can reach you. If you did not expect authorization to be unavailable, check the client in the [Developer Portal](/oauth/applications). A client stays in development until it is submitted for review and approved. A rejected or disabled client also prevents other users from authorizing the application.
|
|
38
|
+
Those users are shown the support email registered with your client so they can reach you. For an active client with a support-email update under review, Lunch Money shows the last approved address rather than the newly saved one. If you did not expect authorization to be unavailable, check the client in the [Developer Portal](/oauth/applications). A client stays in development until it is submitted for review and approved. A rejected or disabled client also prevents other users from authorizing the application.
|
|
39
39
|
|
|
40
40
|
### Redirect URI problems
|
|
41
41
|
|
|
@@ -48,7 +48,7 @@ The page displays one of two codes, a UTC timestamp, and the application name an
|
|
|
48
48
|
| `redirect_uri_mismatch` | The address your application sent is not registered for the client, or differs from a registered one | Open the client in the [Developer Portal](/oauth/applications) and compare the address with its registered redirect URIs. Web-client redirects and native HTTPS or private-use scheme redirects must match every component exactly. For a native HTTP loopback redirect, the scheme, host, path, and query string must match, but the ephemeral port may differ. See [local callback failures](#local-callback-failures). |
|
|
49
49
|
| `redirect_uri_missing` | No `redirect_uri` was sent, and the client has more than one registered, so Lunch Money cannot choose | Send the parameter explicitly. A client with exactly one registered address may omit it; Lunch Money then uses the registered value. |
|
|
50
50
|
|
|
51
|
-
The page offers the user a prefilled message addressed to the support email registered with your client.
|
|
51
|
+
The page offers the user a prefilled message addressed to the support email registered with your client. For an active client with a support-email update under review, this is the last approved address, which can differ from the address currently saved in the Developer Portal. The message contains the error code, the timestamp, the application name and client ID, and the callback address your application sent, reduced to its origin and path with any query string removed. Compare that sanitized callback address with the redirect URIs registered for the client, then correct either the registered URI or the address your application sends.
|
|
52
52
|
|
|
53
53
|
## Callback validation failures
|
|
54
54
|
|
|
@@ -135,17 +135,11 @@ The `scope` parameter names every scope the endpoint requires, including any the
|
|
|
135
135
|
|
|
136
136
|
Adding `scope` to an authorization URL cannot upgrade or narrow a grant. Lunch Money ignores the requested value and uses the client's complete registered scope set. To change scopes, create a replacement client, test all functionality, complete any required review, update the deployed client ID and credentials, and send every existing user through authorization again.
|
|
137
137
|
|
|
138
|
-
##
|
|
138
|
+
## Support email is not confirmed
|
|
139
139
|
|
|
140
|
-
|
|
140
|
+
You cannot submit a client for review until its support email is confirmed. Open the client in the [Developer Portal](/oauth/applications), check that the address is correct, and resend the confirmation email if needed. Check the mailbox's spam or junk folder for a message from `support@lunchmoney.app`.
|
|
141
141
|
|
|
142
|
-
|
|
143
|
-
| --- | --- | --- |
|
|
144
|
-
| `422 quota_exceeded`, field `clients` | You already own 25 non-deleted OAuth clients. | Delete a client you no longer use before registering another. |
|
|
145
|
-
| `422 quota_exceeded`, field `secrets` | The client already has three non-revoked secrets. Expired secrets still count. | Revoke an obsolete or expired secret before creating another. |
|
|
146
|
-
| `429 review_quota_exceeded` | You have made five initial review submissions across your clients in the rolling 24-hour window. | Wait until the time shown in the Developer Portal before submitting again. API clients should also respect the `Retry-After` response header. |
|
|
147
|
-
|
|
148
|
-
Cancelled submissions, rejected-client resubmissions, and submissions for clients later deleted still count toward the review limit. Reviews opened automatically after an active client's identity changes do not count.
|
|
142
|
+
Each confirmation link expires after 72 hours. You can resend at most once per hour; the Developer Portal shows when another resend is available. If the link reports that it is invalid or expired, return to the client and request a new one. Changing the support address also invalidates any link sent to the previous address.
|
|
149
143
|
|
|
150
144
|
## Local callback failures
|
|
151
145
|
|