If a TLD has a whitelist on nameservers, domains in such TLD must have
at least one nameserver. Therefore creating domains with empty nameserver
is forbidden, as well as deleting the last nameserver on a domain. We
enforce this policy by checking the number of nameservers for the new resource
to makesure it is not zero if a whitelist exists.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=127318320
This new name is a more accurate description of what the actual class
does. TldSpecificLogicEngine is an interface that will be added in
the near future, implementations of which will provide custom per-TLD
logic. The class being renamed is more properly a proxy that only
handles logic generic to all TLDs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=127088913
When updating a filed other than the registrant for a domain, a null
registratantContactId is passed to the registrant whitelist validator, causing
an excpetion because null is not an element in the whitelist (if it exists).
Added logic to handle null registrantContactId.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=126817310
See [] for details, but basically, @FlowScope causes the Flow instance produced by flowProvider.get() in FlowRunner to be the same each time it's called, which leads to the instance being re-used when a transactional retry (e.g. for a ConcurrentModificationException) causes a flow to be attempted more than once. Flow is not meant to be re-used and certain flows fail at runtime when this happens, so the effect is that a CME now aborts most EPP requests, which is bad.
This is a bit of a hacky fix; finding a better one is tracked in []
== TESTING ==
This is very hard to test because there isn't really a clean way to trigger a CME from within a flow's execution without hardcoding in assumptions about what a given flow is doing when it runs, and we can't easily supply a custom Flow for testing while also exercising the Flow daggerization process (since this bug only appears due to the specific way that dagger constructs the Provider<Flow>). Ideally a fix would improve the testability here as well.
For now, I've manually tested this change by pasting code into FlowRunner that explicitly throws a ConcurrentModificationException after running the flow (similar to DryRunException), but only on the first transaction attempt. With @FlowScope on provideFlow(), this change reproduces the UnsupportedOperationException issue in many tests; once it's removed (i.e. with this CL submitted) the problem goes away.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=126226066
We've been using the very fragile newline-delimited legacy logging
statement in FlowRunner for ICANN reporting for a long time. While
this is bad in a few ways, the worst is that the parsing of this
logging statement is extremely fragile (e.g. adding/removing fields
can easily break the parsing). This is in fact part of what broke the
ExportLogsServlet parsing last fall ([] and forced us to
recover by manually parsing the log statement (and its XML) in
BigQuery. It also broke again in [] where we were relying
on matching the logging classname, since matching on 'EPP Command'
was considered insufficiently narrow.
This introduces a new JSON-format logging statement to FlowRunner
that fixes both of these problems:
1) it replaces the newline-delimited "format" with a JSON-based
format, so that we can add new fields much more easily and
reliably support logging more structured data
2) it replaces the short 'EPP Command' signature with a much more
targeted 'EPP-REPORTING-LOG-SIGNATURE' signature so that we can
use that alone for matching, rather than relying on the class
name in the log message
What this doesn't fix is the fact that we still need to parse the
XML in BigQuery; we should fix this by logging the parts of the XML
that ICANN reporting needs explicitly, but that'll be a subsequent
change, since while the existing approach is gross, it's actually
much less fragile than just matching the log statement itself.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=125902976
This cleanups up the toString() methods of all implementations of
these interfaces, as pre-work for adding tests against the legacy
logging statement in FlowRunner used for ICANN reporting, so that we
can validate against any changes to that log statement in the future.
It removes system hash codes since those aren't really safe to rely on
in test code and they really don't help with debugging anyway. It
also standardizes SessionMetadata.toString() a bit and regroups
methods on that interface so all the getters are together.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=125686039
All [] paths relating to soy are encompassed by @io_bazel_rules_closure[]
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=125498324
This is more efficient (we were constructing all the
providers and the map anew for every flow) and prettier.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=125479328
Daggerizes all of the EPP flows. This does not change anything yet
about the flows themselves, just how they are invoked, but after
this CL it's safe to @Inject things into flow classes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=125382478
Despite the comment, DomainAllocateFlow is absolutely registered in
FlowPicker. It gets picked if there's a domain create epp command that
also specifies the allocate extension. Remove the explicit setting of
flowClass, and remove two tests that now fail because DomainCreateFlow
gets loaded - which is the desired behavior.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=125339191
The "SessionSource" has nothing to do with sessions (and it's often
used in sessionless contexts). What it does indicate is the endpoint
used to make the request.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=125295224
Superuser should only be settable via the tool (see []
which is merged in here but not diffbased, and which removes
the implicit superuser for CharlestonRoad). It is a property
of the request, not of the session (there are no sessions in the tool).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=125204707
dryRun is only available via the (sessionless!) tool, and is not
a property of the session.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=125203026
TransportCredentials are per-request, not per-session, and
there's no reason to carry them within SessionMetadata.
While I'm in here, get rid of "null" credentials.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=125202213
This introduces Actions and Dagger up until FlowRunner. The changes
to the servlets are relatively simple, but the required changes to
the tests, as well as to auxillary EPP endpoints (such as the http
check api and the load test servlet) were vast. I've added some
comments in critique to make the review easier that don't really
make sense as in-code comments for the future.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=124593546
This properly reflects the fact that other, separate things will now
be responsible both for EAP and for per-TLD custom pricing.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=124558165
The load tests used to directly build EPP, but that becomes
problematic for an upcoming CL that refactors a lot of the
EPP flow code. Instead, use the existing tool endpoint
(conveniently, LoadTestAction is already in the tools module).
This required changing the EppToolServlet to get its
xml from a param rather than from the request payload,
since task queues won't allow both a payload and request
params on the same task.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=124351878
This cleans up some of the tests, and helps with
future injection CLs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=124208164
For domain checks in GA and quiet period, show domains with pending applications as unavailable.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=124134193
This completes the command extensions for the regType 0.2 extension.
Up next will be the response extensions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=123322887
Note that it doesn't do anything yet beyond basic XML validation
because the default registry system doesn't use registration types,
but this serves as a template for the other domain commands using
registration types and provides a method that TLDs implementing custom
logic can use. This also explicitly doesn't yet handle the response
extensions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=123245388
This is so we can associate history records with all mutations when doing
database maintenance.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=123209304
Second-level domain name isn't accurate because we support multi-part
TLDs, so standardize on the "fullyQualifiedDomainName" name that is
used throughout the code base.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=122693009
This also renames the existing FlowRegistry to FlowPicker to avoid
overloaded uses of the word "registry". Absent this renaming, the new
package would've been google.registry.flows.registry, which gives
entirely the wrong impression as it makes it sound like the home for
flows that affect TLDs.
This is a preparatory CL for adding flow picker engines that will
allow customized flows to run on a per-TLD basis.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=122671260
This is the first step toward being able to add more providers on a
per-TLD basis.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=122656117
RFC5731 leaves the registrant field as optional. We
currently don't show it on un-authed info, but we do
show it in WHOIS, so there's no strong reason not to
show it here. By doing so, we maintain the invariant
that registrant must always be present on a
DomainResource object.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=122645356
