This CL adds transferredRegistrationExpirationTime as a TransferData field
persisted to Datastore. It's only relevant for domains, and it represents the
registration expiration time resulting from the approval of the most recent
transfer request. For pending transfers, we assume the transfer will be
server-approved, and thus in DomainTransferRequestFlow we set this field to the
existing computed value serverApproveNewExpirationTime, which is what we use
for setting up the server-approve autorenew billing event and poll message.
In DomainTransferApproveFlow we overwrite this field with the freshly computed
newExpirationTime, whereas in DomainTransferCancel/RejectFlow (and in the
implicit cancel of DomainDeleteFlow during a pending transfer) we null it out.
There are two key benefits to having this field, which are described in more
detail in b/36405140.
1) b/25084229 - it allows storage of a frozen value to back the "exDate" field
of DomainTransferResponse, which we can use to fix various errors with how
exDate display currently works.
2) b/36354434 - it allows DomainResource.cloneProjectedAtTime() to just directly
set the registrationExpirationTime to this value, without computing it de
novo, which reduces duplicated logic and ensures that the new expiration time
matches the autorenew child objects.
This CL only starts writing the field on TransferData as persisted directly on
the DomainResource itself. We'll then want to backfill the field for at
least pending transfers, whether expired or not (so we can do (2) above), but
I think we might as well backfill it for all pending and approved transfers
so that we also fix (1) even for historical transfers. And then we can start
actually reading the field for both purposes. (Note that for (1), this will
only fix synchronous transfer responses served via DomainTransferQueryFlow,
not async transfer responses served via poll messages, since these have already
been persisted with a potentially bad exDate, but I don't think it's worth a
backfill for those).
One last naming note: I chose the verbose transferredRegistrationExpirationTime
rather than the extendedRegistrationExpirationTime of DomainTransferResponse
because (as is the case in autorenew grace, or for a superuser transfer) the
new registration time isn't necessarily extended at all; it may be the same as
the pre-transfer expiration time. Also, including "registration" helps clarify
w.r.t. pendingTransferExpirationTime which refers confusingly to the expiry of
the transfer itself, rather than the domain registration.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171858083
This CL changes the domain and contact transfer flows to check the entire
TransferData on the post-transfer resource, rather than just spot-checking
certain fields. This approach provides much better code coverage - in
particular, it checks that the non-request flows (approve, cancel, reject)
don't modify the fields that they shouldn't be modifying, and that they do
actually clear out the transfer server-approve entities fields written by
the transfer request flow. It's slightly orthogonal, but I also added
testing that the server-approve entities fields are actually set in the
request flows, which was previously untested.
This is pre-work for introducing an exDate-storing field into TransferData,
by making it easier to test everywhere that exDate is set *and* unset only
in the correct places.
As part of this CL, I've introduced a TransferData.copyConstantFieldsToBuilder()
method that is like asBuilder() but instead of copying all the fields to the new
builder, it only copies the logically constant ones: losing/gaining client IDs,
the request time and TRID, and transferPeriod. This is useful both in tests but
is also used in the resolvingPendingTransfer() helper that centralizes the core
transfer resolution logic (as of [] That method has its own tests,
and in the process I removed a bunch of crufty defunct TransferData tests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171053454
In the great flow flattening, ResourceFlowUtils grew a couple nice helpers
for rebuilding transferrable resources (Domains and Contacts) upon the
resolution of a transfer - approvePendingTransfer() and denyPendingTransfer().
Most transfer-resolving callsites use one of these two helpers, but for legacy
reasons the deletion flows (DomainDeleteFlow and DeleteContactsAndHostsAction)
were instead using the "manual" resolvePendingTransfer() method or its even more
low-level createResolvedTransferData() helper instead of denyPendingTransfer().
It's simpler to just have two options - approve and deny - so this CL inlines
createResolvedTransferData() into resolvePendingTransfer() and makes the latter
a private helper for the approve/denyPendingTransfer() public helpers.
This CL also adds sanity checks that approve/denyPendingTransfer() are called
only with the logically appropriate values of TransferStatus.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170819358
This CL deduplicates these two methods in DomainTransferRequestFlowTest:
- assertHistoryEntriesContainTransferBillingEventsOrGracePeriods()
- assertHistoryEntriesDoNotContainTransferBillingEventsOrGracePeriods()
Instead, we have one method with an extra parameter dictating whether or not
we should expect a transfer billing event (yes normally, no in the case of a
superuser transfer w/ 0 period). This is less code overall and avoids drift
between the normal vs special case assertions (if people make changes in one
but forget to do so in the other).
Also, the methods as named were a little confusing because the "Contain" vs
"DoNotContain" naming suggests that the methods are asserting opposite things,
but actually they assert some things in common (like the existence of autorenew
billing events, and that pre-transfer grace periods are cleared).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170540417
It's bad practice in terms of data model consistency to use DateTime.now(UTC) for cloneProjectedAtTime() within a transactional context - instead, we should always use ofy().getTransactionTime() when it's available. The ofy transaction time is frozen at the start of the transaction attempt, whereas DateTime.now(UTC) will continue marching ahead. So using it for a cloneProjectedAtTime() could mean materializing the outcome of logical-time-dependent events (like autorenews, or transfers, or grace period expirations) at a logical time (i.e. commit log time) prior to when they should actually have occurred.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170501277
Since HistoryEntry always represents a read-only log of mutation to a core resource, that mutation should always happen in a transaction, and the HistoryEntry should be saved in that transaction. As such, it's always more accurate to use ofy().getTransactionTime() for the modificationTime of the HistoryEntry rather than just DateTime.now(UTC).
In addition, having these be the exact same timestamp makes it possible to align HistoryEntries with commit log manifests using modificationTime = transactionTime, which is useful for recovery and analysis purposes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170136957
No reason for these not to work out of the box, right? The default-config.yaml already has a couple other real icann.org URLs for RDE testing and the TMCH CRL. This way Nomulus users don't have to worry about changing this setting (since other than testing it's hard to imagine what other value would be used; this is literally ICANN reporting so it always goes to ICANN).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170093954
Mostly based on the original PR, but with some tweaking by nfelt@, in particular to add some support for autorenew grace period subsumption.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169922894
LogsExportCursor was only used by ExportLogsTaskServlet, which we removed a long time ago. It's just dead code. The PersistedRangeLong type was only written for use by LogsExportCursor, and since it hasn't picked up new users in 3+ years I don't think we need to keep it around.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169264994
This finally fixes b/37629674 by cutting over the ICANN activity reporting query for EPP/SRS metrics to use the new JSON-based structured log line in FlowReporter, which is much easier to parse and interpret correctly than the old XML logging which was not designed to be ingested in BigQuery.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159633467
This makes a bunch of accuracy improvements to the ICANN activity EPP/SRS query that parses XML logs. We're going to be getting rid of this code imminently in favor of the new FlowReporter JSON log line which is much easier to interpret correctly, and in fact all of these issues were detected by comparison with that query. Fixing these issues brings this query almost (but not quite) up to par with the new version. The point of checking this in is so that we have evidence that the new version only diverges from the existing version in ways that are desirable and documented herein.
Here are the accuracy issues fixed in this CL:
1) false negative - the old query failed to parse the XML entirely for logs with no client ID (e.g. a registrar who isn't logged in attempting to do a domain check), due to an overly restrictive regex
2) false negative - the old query failed to extract the TLD from EPP requests for just ".tld" (no SLD label at all), which would be an invalid request anyway but should probably still be counted in the reporting for that TLD (which the new query does), due to an overly restrictive regex
3) false negative - the old query failed to normalize uppercase TLDs from the raw XML to lowercase, meaning they wouldn't have matched later on in the pipeline
4) false positive - the old query counted dry-runs from the tool as valid EPP requests, the new logging ignores them
5) false positive - if the old query can't extract the TLD (for example, the domain name provided is just "how" instead of a real SLD), it reports a NULL tld, but then the way the overall activity report query works, it considers that metric to apply to *all possible TLDs* (this is necessary behavior for cases where e.g. for contact/host metrics, we do want a null TLD to signify "applies to all TLDs"). In the case of e.g. a domain check though, this results in that domain check being counted for all TLDs' activity reports, even though it should not be counted for any of them. The fix is to manually filter out results with for 'srs-dom-*' metrics with a NULL tld.
6) false negative - old query wasn't counting /check (CheckApiAction) queries, new query does (and for some reason, we have a strange number of these coming in for TLDs other than .how/.soy, pretty much all from AWS IP addresses and with a UserAgent corresponding to the Go HTTP client library)
Finally, this also adds more progress printing lines to icann_reporting.py.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159608369
I happened to notice that one domain affected by b/33289763 had existing transfer data, so in that case the data got overwritten to look like a server cancellation (a year after the transfer request, so obviously wrong) rather than creating invalid transfer data, and hence wasn't picked up in the previous fixes. See b/33289763#comment32 for more details.
This CL renames the RemoveDomainTransferDataCommand used to fix the errors to FixDomainTransferDataCommand and changes its behavior to instead reset the TransferData to a server-approval result. It also changes it to load domains by ROID because loadByForeignKey() fails for deleted domains.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159273225
I think this comment was meant to be the justification for not using "localhost" (aka a hostname) in the URLs, because jsch would mangle it. However, we already cut over to using "localhost" in [] to avoid a dependency on IPv4, and it's been fine. So this comment no longer makes sense.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158063880
The StatusProhibitsOperationException superclass constructor just wants a raw message to return to the client, so we should pass it an explanation rather than just the superordinate domain name. In fact, I think the superordinate domain name isn't really necessary since it should be obvious from the hostname in the create/update request what the superordinate domain would be.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156747185
This fixes TaskQueueHelper methods and MatchableTaskInfo so that the .param() matching works for pull queues, by parsing the payload for URL-encoded parameters more liberally. As such, it updates all the places where formerly we were hacking around this by manually constructing the expected payloads and using TaskMatcher.payload() instead.
It also adds a TaskQueueHelper.assertTasksEnqueued() overload that accepts an Iterable<TaskStateInfo> so that you can cleanly assert that a queue contains the same tasks that were returned via a previous call to getQueueInfo("queue").getTaskInfo().
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156604901
This should be %SOURCE_DATASET% so that it's adjusted appropriately based on the parameter value.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155582718
This change means that RdeStagingAction now accepts POST requests and supports the API auth method, which is needed for the new GenerateEscrowDepositCommand (as of [] to be able to invoke the action in manual mode. Note that this shouldn't affect the cron setting that invokes it currently, which are GET requests with INTERNAL auth.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154764870
The logging for exceptions in FlowRunner - always at WARNING - has long been sub-optimal. For EppExceptions it's too aggressive/spammy to log at WARNING because it's generally not actionable - EppException gets properly thrown for all kinds of ordinary reasons (trying to create a resource when one already exists with that foreign key) and/or for client misbehavior that we can't control (sending bad parameter values, etc.). For non-EppException RuntimeExceptions, it's redundant with existing logging in EppController.
This CL resolves this by removing that logging in FlowRunner entirely in favor of the EppController logging, where we're now logging EppExceptions at INFO in parallel with the existing logging of RuntimeExceptions at SEVERE. This has the benefit that we're now logging EppExceptions that come from FlowPicker (by way of EppExceptionInProviderException), which previously were unlogged.
Note however that this does mean that in places where we run FlowRunner without EppController - exclusively test code as it stands today - we'd no longer be logging EppExceptions. If that seems like a loss, we could either reinstate logging there (at INFO) and just deal with redundant messages for most EppExceptions, or we could add it manually to places where we call FlowRunner.run() in tests and avoid the redundancy that way.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154733365
This snuck in from [] but was just a vestige of when I was testing with the tests still in FlowRunner test and wanted to make sure they still passed with the logging moved to FlowReporter. Now that the tests are in FlowReporterTest and FlowReporter is mocked out here, attaching the handler to that logger is a no-op.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154601472
Mostly these are calls to ForeignKeyIndex.create() (a static method) via subclasses, which is pretty misleading in this case since the type of the return value has nothing to do with the subclass you're qualifying the static method call with (the returned type depends only on the type of the EppResource parameter).
Note however though that while the style guide indeed prohibits qualifying static member references with things other than the class name, the subclassing case is apparently not considered subject to that prohibition in general:
https://groups.google.com[]d/msg/java-style/8ViX-Rh2_sc/48n2lz5nAAAJ
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154331605
As part of b/36599833, this makes FlowReporter log the tld(s) of every domain
flow it executes, so we can provide ICANN reporting totals on a per-TLD basis.
It also adds several other fields that we're computing anyway and which seem
useful, particularly for debugging any issues we see in production with the data
that we're attempting to record for ICANN reporting. The full set of fields is:
- commandType (e.g. "create", "info", "transfer")
- resourceType* (e.g. "domain", "contact", "host")
- flowClassName (e.g. "ContactCreateFlow", "DomainRestoreRequestFlow")
- targetId* (e.g. "ns1.foo.com", "bar.org", "contact-1234")
- targetIds* - plural of the above, for multi-resource checks
- tld** (e.g. "com", "co.uk") - extracted from targetId, lowercased
- tlds** - plural of the above, deduplicated, for multi-resource checks
* = only non-empty for resource flows (not e.g. login, logout, poll)
** = only non-empty for domain flows
Note that TLD extraction is deliberately very lenient to avoid the complexity
overhead of double-validation of the domain names in the common case.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154070794
Since this feeds into ICANN reporting, we don't want to muddy the data
there with dry-runs, which are always internal-only artifacts of tool usage
and shouldn't really count as real attempts to do SRS actions, since they
are always going to abort with no effect.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=153856915
This primarily adds accessors to EppInput that will be used for flow reporting
logging in FlowReporter. Specifically, it adds:
- Optional<String> getResourceType() -> domain/host/contact
- Optional<String> getSingleTargetId() -> for SingleResourceCommands
And in addition, it adjusts getCommandName() so that it's now named
getCommandType() for better parallelism with the new getResourceType() (since
getResourceName() would be misleading), and it changes the value returned to be
lowercased, again for consistency. This isn't an issue because getCommandName()
isn't actually used anywhere right now (it was formerly used for EPP whitebox
metrics, but no longer due to recent changes there).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=153851957
This prevents a possible failure mode of the logging where the logged
EPP input XML is very large (which can happen e.g. for domain creates
with large SMD values). In those cases, the XML might cause the overall
JSON string to be too large to fit within a single log entry [1], in which
case it gets split over multiple lines and breaks automatic parsing.
This mitigates that case by logging the EPP input (raw and base64-encoded)
in a separate log statement so that the more compact metadata (like clientId)
and derived values (like ICANN reporting field) will still be in an intact
JSON string even in that case, and can still be readily parsed. It's okay
if the actual EPP XML is harder to parse, since once we're logging the right
metadata fields we shouldn't need to automatically parse the EPP XML in any
normal cases.
[1] I haven't found this exact limit or splitting algorithm, or whether it's
a property of java logging or GAE log ingestion. The GAE logs page does note
that a single application log entry (within a request, which can have up to
1000 such entries) maxes out at 8KB, so that might be it:
https://cloud.google.com/appengine/docs/standard/java/logs/#writing_application_logs
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=153771335
Since this reporting is getting more complicated (see b/36599833), it'll
be better to have a dedicated class to encapsulate it, which also lets us
keep the tests separate and focus FlowRunner more on its core purpose of
actually running the flow.
Note that this doesn't move the legacy log statement logging because that
specifically must be logged from the FlowRunner.run() method to preserve
the existing log signature matching in our ICANN activity reporting query.
(The new statement is designed to be robust to moves like this since it
doesn't use the logging callsite to match log lines, and it's not in use
yet anyway.)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=153762008
This is better than calling assertTldExists() inside a for loop because you can throw a single exception reporting all bad TLDs at once rather than only getting as far as the first failure. And then it's also a one-liner instead of 3 lines.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152412876
It has 5 parameters, which is pushing it for a static factory method, and we're anticipating adding more for work that Larry is doing. Using a builder is preferable here since it makes it harder to accidentally mis-order the parameters (since @AutoValue's generated constructor is sensitive to parameter ordering).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152328220
RegistrarContacts are allowed to have no "types" specified (they can also have multiple types). However, the registrar console displays the contacts for the logged-in registrar grouped by type into sections, and contacts with no type were simply being omitted from the listing, which was confusing because you can't even log into the console unless your email is listed as a contact, and yet you might then visit the contact settings page and see (apparently) no configured contacts.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152302159
As part of b/36599833, this makes FlowRunner log the appropriate ICANN activity
report field name for each flow it runs as part of a structured JSON log
statement which can be parsed to generate ICANN activity reports (under the key
"icannActivityReportField").
In order to support this, we introduce an annotation for Flow classes called
@ReportingSpec and a corresponding enum of values for this annotation, which is
IcannReportingTypes.ActivityReportField, that stores the mapping of constant
enum values to field names.
The mapping from flows to fields is fairly obvious, with three exceptions:
- Application flows are all accounted under domains, since applications are
technically just deferred domain creates within the EPP protocol
- ClaimsCheckFlow is counted as a domain check
- DomainAllocateFlow is counted as a domain create
In addition, I've added tests to all the corresponding flows that we are
indeed logging what we expect.
We'll also need to log the TLD for this to be useful, but I'm doing that in a
follow-up CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151283411
This is a followup to [] that adds a similar explanation to our g3doc, warning that RegistrarCredits don't have any effect as implemented and may be removed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151041925
These columns were only necessary to support the old PremiumListData and
RecurringEventData views, which were removed in []
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151019824
Currently, the message you get when using e.g. assertAboutContacts().that(alice).isEqualTo(bob) is not very helpful, because we override the "actual" toString (for alice) to return just an abbreviated version, and dump the entire full ImmutableObject toString for bob:
java.lang.AssertionError: Not true that <ContactResource with foreign key 'contact_id'> is equal to ContactResource (@2125903542): {
authInfo=ContactAuthInfo (@2128169374): ...
// giant blob of contact info here
}
So you can't even figure out why they aren't equal. Rather than reverting the "actual" object's toString representation in this case, which would just require you to visually compare two giant blobs of properties, this special-cases to let you compare using the prettyPrintEntityDeepDiff() helper we use in MutatingCommand.
With the new version, you see exactly what differs:
java.lang.AssertionError: Not true that <ContactResource with foreign key 'contact_id'> is equal to ContactResource (@2125903542): {
authInfo=ContactAuthInfo (@2128169374): ...
// giant blob of contact info here
}
It differs as follows:
transferData.pendingTransferExpirationTime -> [2017-03-27T16:01:39.882Z, 2020-05-08T16:01:39.882Z]
lastTransferTime -> [2017-03-27T16:01:39.882Z, 2020-05-08T16:01:39.882Z]
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151004823
These were a few straggling special cases to deal with Registry 1.0 data;
that data was removed ages ago and I just never got around to cleaning these
up. This removes them at long last.
There were also some TODOs for the same bug around better TLD extraction that
supports multi-part TLDs (though that's pretty unrelated to Registry 1.0/2.0),
so I fixed those since it turns out supporting multi-part TLDs is trivial.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151003181
This tidies up some logic in the flows that checks registration periods, so that in the create flows we're consistently checking that the requested number of years is <= 10 right away (DomainCreateFlow was deferring it until very late, including after custom logic ran, for no good reason I can see).
It also refactors the validateRegistrationPeriod() overload used by DomainRenewFlow to take the newExpirationTime directly, and just check to ensure that it's >= to now.plusYears(10) (with leap-safety just in case). This is a much simpler check than before, which recomputed the newExpirationTime separately from the logic used by DomainRenewFlow itself (always dangerous) and did a more convoluted and unnecessary comparison involving extendRegistrationWithCap().
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151002960
The actual extendedRegistrationYears field was removed in [] but I
missed a few prose (space-separated) references.
While I was at it, I also swapped the javadoc for approvePendingTransfer() and
denyPendingTransfer(), since their descriptions after the summary fragment were
reversed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150782713
This is the third step of migrating to the new format: removing support
for the legacy format.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150512556
Now that transfers are always restricted to 1 year, it's unnecessary to store
extendedRegistrationYears on TransferData - it will always be equal to 1. This
simplifies logic in a few other places, e.g. RdeDomainImportAction.
I verified in BigQuery that no DomainBases exist with extendedRegistrationYears
values that aren't either null or equal to 1. At some point we should remove
the persisted fields from datastore via e.g. resaving all those domains, but
it's low priority and can wait until we have some more pressing migration.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150373897
This CL restricts domain transfer pricing lookups (on domain check and info) to
only support a 1-year period for inquiring about transfer fees. That treatment
matches what we do for domain restores, which are also always one year. This is
a followup to [] which disallowed actual transfer request flows from
specifying multi-year periods.
Since it's no longer necessary, this CL also changes the domain transfer pricing
logic to drop the years parameter, including removing the parameter from the
custom pricing logic TransferPriceParameters object.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150367839
Noticed that this is a bit out-out-date ever since these were
split into two types versus using the converters.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150352102
This tweaks the logic that prohibits domain renews during pending transfers to just use the regular verifyNoDisallowedStatuses() check instead of a special check on TransferData with a custom exception. This is simpler and produces a better error message: we get "Operation disallowed by status: pendingTransfer" instead of "Object with given ID (foo.com) already has a pending transfer" (which is intended for use when denying a transfer request for an object already being transferred, not for this case).
For the record, we originally prohibited renews for domains in pending transfer because there's no good reason to do such a renew: b/12533793. But in fact our transfer server-approve logic relies heavily on this behavior, because otherwise the domain's expiration time computed in cloneProjectedAtTime() will reflect the transfer year added to the post-renew expiration time, whereas all the transfer server approve entities (e.g. new autorenew billing event) will reflect the pre-renew expiration time at the moment the transfer was requested. As such, it would be quite difficult to ever support a renew during pending transfer, since it would need to change many fields within the transfer server approve entities.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150325501
This was created during the Registry 2.0 migration for use by a scrap servlet ([] and never removed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150325126
We were using verifyHasPendingTransfer() only in the domain transfer flows; now we use it in both. I also added a helper verifyTransferInitiator() even though it's only used in two places (the transfer cancel flows), because I think it streamlines the flow and makes it more consistent with the whole section of verification checking.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150324823
This changes ResourceStatusProhibitsOperationException so that we print out the list of StatusValues using their XML names rather than the literal enum name, i.e. we use "pendingDelete" rather than "PENDING_DELETE".
This seems more correct given that EPP clients will be used to seeing the status values in the XML representation, and it also matches the existing ResourceHasClientUpdateProhibitedException that hardcodes "clientUpdateProhibited":
http://[]/third_party/java_src/gtld/java/google/registry/flows/exceptions/ResourceHasClientUpdateProhibitedException.java?l=22&rcl=146111211
Also reorganized related test methods and added some missing tests, including for ContactTransferRequestFlow which previously had none. I also renamed the "clientProhibitedStatusValue" tests to instead say "statusValueNotClientSettable" to be clearer about what's being tested, and that it's not related to the "clientXXProhibited" statuses.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150248562
It turns out that this ICANN policy appears to prohibit transfers with
registration extensions other than 1 year (section A.8):
https://www.icann.org/resources/pages/policy-2012-03-07-en
This is backed up by the practical fact that we've never seen a registrar
request a transfer for any period other than one year.
And removing the support for multi-year transfers vastly simplifies
transfer logic and eliminates a bunch of annoying corner cases. Users
still can achieve the same thing by doing a 1-year transfer plus a
manual renewal afterwards for the remainder of the desired extension.
This change leaves in place lots of infrastructure to support multi-year
transfers that is now obsolete (e.g. TransferData.extendedRegistrationYears).
This should all be cleaned up, but it's a lower priority than fixing the
gap itself and insulating ourselves against needing to handle any real
multi-year transfer case. Once this CL goes in, we can start ignoring
extendedRegistrationYears entirely because it'll always be 1 year, which
makes the cleanup process easier.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150212864
This is the second step of migrating to our new XSRF token format. The
first step ([] made validate() start accepting new tokens
(basically, dual-read). This step cuts over our "writing" to write the
new token format. The third and final step will drop support for
validating the old token format (back to single-read). We'll do that
in a subsequent push so that we don't invalidate all the current XSRF
tokens that people might have in their browsers.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=149790648
This fixes longstanding bug b/19430703 in which domain transfers that were
server-approved would only handle the autorenew grace period correctly if
the autorenew grace period was going to start within the transfer window.
If the autorenew grace period was already active (e.g. the domain had
recently autorenewed, before the transfer was requested), the logic would
miss it, even if it was going to be active throughout the transfer window
(i.e. it would still be active at the server-approval time).
When the autorenew grace period is active at the time a transfer is approved
(whether by the server or explicitly via DomainTransferApproveFlow), the
correct behavior is to essentially "cancel" the autorenew - the losing registrar
receives a refund for the autorenew charge, and the gaining registrar's transfer
extended registration years are applied to the expiration time as it was prior
to that autorenew. The way we implement this is that we just have the transfer
essentially "subsume" the autorenew - we deduct 1 year from the transfer's
extended registration years before extending the registration period from what
the expiration time is post-autorenew at the moment of transfer approval.
See b/19430703#comment17 for details on the policy justification; the only real
ICANN document about this is https://www.icann.org/news/advisory-2002-06-06-en,
but registrars informally document in many places that transfers will trigger
autorenew grace, e.g. see https://support.google.com/domains/answer/3251236
There are still a few parts of this bug that remain unfixed:
1) RdeDomainImportAction repeats a lot of logic when handling imported domains
that are in pending transfer, so it will also need to address this case in
some way, but the policy choices there are unclear so I'm waiting until we
know more about RDE import goals to figure out how to fix that.
2) Behavior at the millisecond edge cases is inconsistent - specifically, for
the case where a transfer is requested such that the automatic transfer
time is exactly the domain's expiration time (down to the millisecond),
the correct behavior is a little unclear and this CL for now ignores this
issue in favor of getting a fix for 99.999% of the issue into prod. See
newly created b/35881941 for the gory details.
Also, there are parts of this bug that will be fixed as parts of either
b/25084229 (transfer exDate computations) or b/35110537 (disallowing transfers
with extended registration years other than 1), both of which are less pressing.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=149024269
This documents some slightly spooky behavior around domains that have an expiration time within their pendingDelete window (meaning the whole period from DomainDeleteFlow running to the actual deletionTime, not just the 5-day pendingDelete grace period). They will experience an autorenew in terms of expiration time and grace period status due to cloneProjectedAtTime(), but without the usual artifacts of an autorenew (billing event and poll message).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=149019980
This follows up on Brian's work to transition not just to a new format
with an empty scope value, but instead to replace the existing format
entirely with a new one that:
1) includes a version number to support future format migrations
2) doesn't include a field for the scope at all, since scoping the
tokens adds no real security benefit and just makes verification
more difficult
3) replaces the raw SHA-256 hash with a SHA-256 HMAC instead, as a
best practice to avoid length-extension attacks [1], even though
in our particular case they would only be able to extend the
timestamp and would thus be relatively innocuous
The new format will be produced by calling generateToken(), and the
scope-accepting version is renamed to generateLegacyToken() in addition
to its existing deprecation, for maximum clarity.
I changed the validateToken() logic to stop accepting a scope entirely;
when validating a legacy-style token, we'll test it against the two
existing legacy scope values ("admin" and "console") and accept it if
it matches either one.
Note that this means the xsrfScope parameter in @Action is now wholly
obsolete; I'll remove it in a follow-up to avoid bringing extra files
into this CL.
After this CL hits production, the next one will replace all calls to
generateLegacyToken() with generateToken(). Once that CL is deployed,
the last step will be removing the legacy fallback in validateToken().
[1] See https://en.wikipedia.org/wiki/Length_extension_attack
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148936805
I'm working on some changes to XsrfTokenManager (b/35388772) and ServerSecret
was crufty enough that I ended up rewriting it. Now it uses a LoadingCache
with a transaction instead of needlessly race-condition-y static init logic.
It also now supports retrieving its value as either a UUID (the old format
used by XsrfTokenManager) or a byte[]. The latter is more flexible and can
be directly used with HMAC which the new XsrfTokenManager format will employ.
And lastly, I added tests. In addition, I tested this code on alpha and
verified appropriate operation (XSRF tokens still work from the console and
from regtool; if you remove ServerSecret from datastore and memcache, it
persists a new one).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148931620
This adds a new method which will be used in an upcoming CL affecting domain
transfer logic. It also removes two older methods that are unused (they were
originally going to be used for TLD-specific logic which is now obsolete).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148928965
This fixes an issue where RdeUploadActionTest relies on connecting to a local dummy SFTP server via the IPv4 loopback (127.0.0.1), which causes the test to fail on machines that only support IPv6. This updates the test to use just "localhost" instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148698178
The BillingData view is intended to be the stable, clean source of data for the invoicing pipeline and detail report output. As such, cutting over to the synthetically created OneTimes is an implementation detail and shouldn't be visible in the output (esp. since that goes straight to the detail reports that registrars receive, and it'd probably just be confusing for them). I think it's fair to generically exclude the SYNTHETIC flag from showing up here - it will still be in BigQuery on the individual OneTimes if we want to look for it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148682719
This provides a safeguard against using TypeInstantiator to resolve the component class, where if resolution is done incorrectly, you end up with java.lang.Object. Formerly, that would have "succeeded" in generating a Router for Object, which of course has no methods that return @Action classes. Such a router is pretty useless, so it's better to make Router stricter and have it fail if you give it such a class by accident.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148353224
It turns out this type parameter was never necessary. A builder only needs the reflexive second type parameter when you want to have a builder inheritance hierarchy where the descendant builders have methods that the ancestor builder doesn't. In that case, the type param enables the ancestor builder's setter methods to automatically return the correct derived type, so that if you start with a derived builder, you can call a setter method inherited from an ancestor and then continue the chain with setters from the derived builder (e.g. new ContactResource.Builder().setCreationTime(now).setContactId(), which otherwise would have returned an EppResource.Builder from setCreationTime(), at which point the call to setContactId() would not compile).
Even then, it's not strictly necessary to use the type parameter, since you could instead just have each derived type override every inherited method to specify itself as the return type. But that would be a lot of extra boilerplate and brittleness.
Anyway, in this case, there is a builder hierarchy, but RequestComponentBuilder specifies all the methods that we're ever going to want on our builders, so there's never any need to be able to call specific derived builder methods. We only even need the individual builder classes so that Dagger can generate them separately for each component.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148269178
This fixes a bug in the interaction between ListObjectsAction and ListObjectsCommand/AppEngineConnection. ListObjectsAction was returning HTTP status code 400 when it caught an IAE, but also attempting to return a JSON response payload of {"status": "error", "error": "<exception message>"}. However, AppEngineConnection treats any HTTP error response as more like a crash on the server side - it attempts to scrape the error message out of the autogenerated HTML that AppEngine produces for uncaught exceptions, and throws an exception, killing ListObjectsCommand before it can extract the JSON which contains the nicer error (that stating the missing field, etc versus just "400 Bad Request").
The fix is just to have ListObjectsAction return a 200 and the error message so that ListObjectsCommand can correctly handle it.
I also de-scoped the catch to only catching IAE, since catching Exception was overbroad, and the only "expected" exception to be thrown is an IAE from the checkArgument() that tests if the requested fields all exist. Any other kinds of exceptions should actually just bubble up and kill the action, and get the regular AppEngineConnection error treatment.
I also added "billingId" as an alias for "billingIdentifier", parallel to clientId/clientIdentifier, since that's why I came across this issue in the first place.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148248834
This was an oversight I noticed ages ago, so resurrecting some old local changes I had to correct it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146812322
DomainApplications have nothing to project, so it's a mistake to call their cloneProjectedAtTime() method. Marking it @Deprecated helps prevent such inadvertent use.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146716189
Follow-up to comments on [] in particular to clarify that INACTIVE can be combined with other statuses and doesn't have any special relationship to OK.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146683905
Right now, it just NPEs, which is harder to debug. Also make it handle end-of-input more cleanly by assuming that means a negative response.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146674937
This fixes a long-standing bug b/26016322 to move BigqueryCommand off of using a service account to access the Bigquery API. It's now using Application Default Credentials, which can be easily auto-installed on a machine by running 'gcloud auth application-default login' and clicking through the OAuth consent screen.
The old method was a pain because:
1) individual users of the tool each needed to know to download and store a private key for the service account, and specify the key file via a CLI flag
2) BigQuery actions taken via the tool (e.g. load or query jobs) were listed as belonging to the service account, making them harder to find in the UI or for debugging, and difficult to audit (no idea which engineer invoked the tool)
3) within Google, this meant extra whitelisting headaches
The new method also isn't perfect because Application Default Credentials obtained via gcloud are supposed to be used primarily for local testing, and don't support setting any custom scopes. However, we don't need custom scopes for this, and the smoother flow is worth it.
In the longer term, once the CLI is using OAuth to talk to the app itself, we'll be able to switch to the "best practice" option of also using those credentials for talking to the BigQuery API.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145120770
We're only using it for generating multiparty boundaries, and there's no real need for the random boundary values to be cryptographically secure. The point of the randomness is just to make collisions with content in the payload sufficiently unlikely. The app itself controls the payload contents, and while it might be derived from user-submitted content, in practice it would be nearly infeasible to get the payload to contain arbitrary boundary values even if the RNG-produced boundaries could be determined in advance.
To further insulate against this, I've increased the boundary size (from 40 bits to 192) and added an actual check that the boundary isn't present in the input data, so that in the extremely unlikely event of a collision, we fail rather than producing an invalid multipart request.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142784289
This change removes ConfigModule from FlowComponent, since it's already present in all of the standard components that serve as "parents" to FlowComponent (i.e. it's in FrontendComponent, BackendComponent, ToolsComponent, and EppTestComponent). ConfigModule should only ever be included in top-level components, so that it's possible to swap it out without having to make changes deep within subcomponent code.
This change also removes SystemSleeperModule, which belongs at the top-level component as well, and is present in BackendComponent and ToolsComponent but was absent in FrontendComponent and EppTestComponent. I've added it to those two places.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=140053552
This refactors RequestHandler so that it handles the construction of the request
component itself, rather than being handed a pre-built request component
instance constructed by the invoking servlet.
The motivation for this change is so that RequestHandler can be extended in
future CLs to compute authentication results, and can provide those results as
an available binding in the constructed request component. An alternative
approach could have been to compute the authentication results within
RequestModule itself, but I think it's clearer to keep business logic like
that outside of Dagger providers.
This CL makes the following individual changes:
- Adds request component builders, which implement a RequestComponentBuilder
interface so they can all be manipulated by RequestHandler
- Instead of obtaining request components via factory methods on the global
components, one now can have global-scoped bindings just inject the request
component builders (which requires adding a module to each global component
declaring the subcomponent). This follows the recommended approach here:
http://google.github.io/dagger/subcomponents.html
- Instead of exposing request components on the global component interface,
we now expose module-specific subclasses of RequestHandler that @Inject the
appropriate request component builder's provider and pass it to the superclass
(note that inheritance isn't strictly necessary here but saves boilerplate)
- RequestHandler now takes the Provider<RequestComponentBuilder> and builds
the component itself using its own fresh RequestModule instance. This provides
some nice encapsulation but is mainly needed for adding a RequestAuthModule
in future work.
- RequestHandler also takes UserService now, which can be provided via Dagger
by the subclass. Longer-term that will go away in favor of instead providing
AuthStrategy instances, some of which will use UserService internally.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138815648
This change moves the reflective setAccessible() calls on the request component
methods (needed so that they can be invoked reflectively from RequestHandler)
to within Router itself, eliminating the need to manually call this from each
Servlet class and then pass in the resulting Method objects. Instead, we just
pass in the request component class and let Router do the rest.
Old comments say that cross-package reflection is not allowed on AppEngine, but
while it's quite possible this was once the case, I can't reproduce that
limitation, and the documentation seems to contradict any such restriction:
"""
An application is allowed full, unrestricted, reflective access to its own
classes. It can query any private members, call the method
java.lang.reflect.AccessibleObject.setAccessible(), and read/set private
members.
"""
https://cloud.google.com/appengine/docs/java/runtime#reflection
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138693006
This will make it much easier to detect issues with bad EPP XML (e.g. the one in the loadtest action fixed in [] based on the request logs, since otherwise the only indication of what went wrong is the EPP response returned to the client, which we don't store anywhere.
Now we'll get log messages that look like this:
google.registry.flows.EppController handleEppCommand: EPP request XML unmarshalling failed - "Syntax error at line 2, column 7: cvc-elt.1: Cannot find the declaration of element 'epp'.": (EppController.java:59)
{"clientId":"CharlestonRoad","resultCode":2001,"resultMessage":"Command syntax error","xmlBytes":"PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI\/Pgo8ZXBwLz4K"}
========================================
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<epp/>
========================================
google.registry.flows.EppXmlTransformer$GenericSyntaxErrorException: Syntax error at line 2, column 7: cvc-elt.1: Cannot find the declaration of element 'epp'.
at google.registry.flows.EppXmlTransformer.unmarshal(EppXmlTransformer.java:89)
at google.registry.flows.EppController.handleEppCommand(EppController.java:56)
at google.registry.flows.EppRequestHandler.executeEpp(EppRequestHandler.java:37)
at google.registry.flows.EppToolAction.run(EppToolAction.java:33)
<snip>
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137363446
This was inadvertently introduced in [] - the original code manually URL-encoded the XML, but the TaskOptions.param() method does that for you, so now we're double-URL-encoding the XML and as a result the actual /_dr/epptool invocation is failing with a syntax error (which was somewhat hard to diagnose, since it logs nothing and returns HTTP 200 in that case - to be fixed separately).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137321114
These are needed for now to get all nomulus tool commands working. Also some other minor doc cleanup.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136471375
This seems like a better description of the actual contents of the section. Expanded contents to mention the need for fully automated reporting and for crypto key storage. Also reshuffled the list a bit to put the things likely to be top concerns first.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136471298
Compile-time constant inlining may interfere with JCommander's processing if a field is made final - @ParametersDelegate fields are particularly misleading. Remove the one instance of that and add warning comments elsewhere. See
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136469351
This makes the usage of DnsQueue.create() safer, since we're no longer
forced to hardcode a copy of the @Config("dnsWriteLockTimeout") value
within that method. That value is only needed for leaseTasks(), which
is only called in one place (ReadDnsQueueAction), so we can just pass
it in from that callsite.
Also removes an unused overload of leaseTasks() that allowed specifying
a tag, which is a feature we no longer need.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136162491
This change consolidates gtech_tool into registry_tool. Since App Engine has
no actual ACLs on the remote API (any access is essentially root access), we're
removing this to avoid giving the impression to users that gtech_tool is truly
locked down from a security perspective compared to registry_tool.
In addition to merging GtechTool.COMMAND_MAP into RegistryTool.COMMAND_MAP, this
change also removes the {create,update}_sandbox_tld commands (which only made
sense for gtech_tool) and removes references to gtech_tool in the documentation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134828710
This improves the tests by:
1) Adding tests for alphabetical ordering of the command maps, to keep them
organized, and fixing existing mis-orderings. Note that this is a no-op
test for RegistryTool since it uses ImmutableSortedMap (to resort the
commands after inserting GtechTool.COMMAND_MAP), but it'll be relevant
in the upcoming CL when they get merged. I changed GtechTool.COMMAND_MAP
to use regular ImmutableMap.
2) Checking that RegistryTool.COMMAND_MAP (the full map, after the existing
GtechTool.COMMAND_MAP has been merged in) contains the exact same set of
commands as all the concrete classes implementing Command that we can find.
This is a stronger test than what we had before, which just checked that
every Command class appeared in RegistryTool (i.e. that RegistryTool's
commands are a superset of all Commands found). You'd think that it'd be
impossible for RegistryTool to contain commands that aren't in the set of
Commands we found, but it is if we're not searching for commands properly,
which we weren't (we were only checking within the .tools package and not
within any subpackages (e.g. tools.javascrap). This has now been fixed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134451859
nickfeltandjianglai
