mirror of
https://github.com/google/nomulus
synced 2026-01-05 04:56:03 +00:00
56cd2ad282
We're changing the way that allocation tokens work in suboptimal (i.e. incorrect) situations in the domain check, creation, and renewal process. Currently, if a token is not applicable, in any way, to any of the operations (including when a check has multiple operations requested) we return some variation of "Allocation token not valid" for all of those options. We wish to allow for a more lenient process, where if a token is "not applicable" instead of "invalid", we just pass through that part of the request as if the token were not there. Types of errors that will remain catastrophic, where we'll basically return a token error immediately in all cases: - nonexistent or null token - token is assigned to a particular domain and the request isn't for that domain - token is not valid for this registrar - token is a single-use token that has already been redeemed - token has a promotional schedule and it's no longer valid Types of errors that will now be a silent pass-through, as if the user did not issue a token: - token is not allowed for this TLD - token has a discount, is not valid for premium names, and the domain name is premium - token does not allow the provided EPP action Currently, the last three types of errors cause that generic "token invalid" message but in the future, we'll pass the requests through as if the user did not pass in a token. This does allow for a default token to apply to these requests if available, meaning that it's possible that a single DomainCheckFlow with multiple check requests could use the provided token for some check(s), and a default token for others. The flip side of this is that if the user passes in a catastrophically invalid token (the first five error messages above), we will return that result to any/all checks that they request, even if there are other issues with that request (e.g. the domain is reserved or already registered). See b/315504612 for more details and background