The --superuser command in the nomulus command-line tool should be
bypassing checks on whether the passed-in registrar client ID has access
to the TLD in question, but currently it is not.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158974462
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
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
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 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
These methods will also be used for RDE imports (in a follow-up).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146955581
This CL adds an otherClientId field to be populated on domain transfers with client ID of the other end of the transaction (losing registrar for requests and cancels, gaining registrar for approves and rejects). This will be used for reporting in compliance with specification 3 of the ICANN registry agreement.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143775945
It can always be brought back if we find an actual use case for it, but for now, it shouldn't be in the standard distribution given that it has no users.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143044153
Also adds a mechanism to ensure that fee extensions are included when custom
pricing logic adds a custom fee, and fixes up the domain restore flow to
properly use the restore price.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142715136
This also adds a domain update pricing hook to DomainPricingCustomLogic.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142286755
The callsites were inconsistent between whether they were passing empty list or
null, and many of the ones that were passing null were not correctly annotated
with @Nullable. I'm now going with empty list throughout except for the final
step where the actual field that will be transformed into XML is set, where it
is coerced to null to avoid an empty element in the XML output.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=139340837
I added shared base classes to all of the Fee extension types that
make it possible to fully ignore the version in the flows. (You
ask for a FeeCreateCommandExtension, for example, and you get one
without having to worry about which). This is an improvement over
the old code that asked you to provide a list of possible fee
extensions and then ask for the first one in preference order.
As part of this I was able to make the Fee implementation a bit
simpler as well.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137992390
1) Don't do ofy().load() inside a model class (in DomainAuthInfo)
2) Move the one use of verify into the one caller in ResourceFlowUtils
3) Hosts don't support authInfo, so remove useless code
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137984809
This concludes your flow flattening experience. Please
fill out a flow flattening satisfaction survey before
exiting.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137903095
Now that the flows are flattened, the commitAdditionalLogicChanges() call, which used to come later in the flow to actually save the Datastore objects, is now happening right after the performAdditionalXXXLogic() call. So we can instead just do the saves in performAdditionalXXXLogic(), and get rid of the separate call. As a first step, this CL simply makes commitAdditionalLogicChanges() a private method that gets called internally by the extra logic manager. Later, we can move the saves into their proper position, affecting only the extra logic class itself.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137529991
This attempts to improve the organization of the helper methods in
DomainTransferRequestFlow created by the flattening in []
The primary changes are:
- new createTransferServerApproveEntities() method that now makes
all the server approve entities in one centralized place
- new createPendingTransferData() method that takes the server
approve entities and hides the slightly hacky code that parses out
the right ones to stuff into the TransferData
This seems like an overall simpler structure to me. With this change,
run() is 20 lines shorter and the flow overall is 40 lines shorter (not
counting a big blob of javadoc I added).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134315295
These were historically separate due to the old flow
structure, but now they should be one exception.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133984858
Also make minor javadoc tweaks to domain transfer flows
to match what we are changing in contact/host flows.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133955677
While working on an implementation of TLD-specific logic, it was realized that the extra logic methods would need access to the flow's HistoryEntry, so that things like poll messages could be parented properly.
Also, the update flow had not been fixed to perform the fee check.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132561527
This CL enhances various domain flows (check, create, delete, renew, restore, transfer, update) so that they invoke the appropriate methods on the object implementing the TLD's RegistryExtraFlowLogic (if any). TldSpecificLogicProxy is also updated to invoke RegistryExtraFlowLogic proxy (if any) to fetch the appropriate price. The tests use a made-up extra flow logic object which can be attached to a test TLD to make sure that the proper routines are being invoked.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132486734
When EAP is involed we current have one billing event for domain create that
has the create fee and EAP fee lumped together. Change it to record two
separate billing events for each.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132335349
This change replaces all Ref objects in the code with Key objects. These are
stored in datastore as the same object (raw datastore keys), so this is not
a model change.
Our best practices doc says to use Keys not Refs because:
* The .get() method obscures what's actually going on
- Much harder to visually audit the code for datastore loads
- Hard to distinguish Ref<T> get()'s from Optional get()'s and Supplier get()'s
* Implicit ofy().load() offers much less control
- Antipattern for ultimate goal of making Ofy injectable
- Can't control cache use or batch loading without making ofy() explicit anyway
* Serialization behavior is surprising and could be quite dangerous/incorrect
- Can lead to serialization errors. If it actually worked "as intended",
it would lead to a Ref<> on a serialized object being replaced upon
deserialization with a stale copy of the old value, which could potentially
break all kinds of transactional expectations
* Having both Ref<T> and Key<T> introduces extra boilerplate everywhere
- E.g. helper methods all need to have Ref and Key overloads, or you need to
call .key() to get the Key<T> for every Ref<T> you want to pass in
- Creating a Ref<T> is more cumbersome, since it doesn't have all the create()
overloads that Key<T> has, only create(Key<T>) and create(Entity) - no way to
create directly from kind+ID/name, raw Key, websafe key string, etc.
(Note that Refs are treated specially by Objectify's @Load method and Keys are not;
we don't use that feature, but it is the one advantage Refs have over Keys.)
The direct impetus for this change is that I am trying to audit our use of memcache,
and the implicit .get() calls to datastore were making that very hard.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131965491
We want to support multiple versions of the fee extension, to allow new features while maintaining backward compatibility. This CL extends the framework and adds one new version, 0.11 (spec version 7), to the existing version 0.6 (spec version 3). A follow-on CL will add version 0.12 (spec version 8).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=127849044
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
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
This refactors the existing premium list functionality into the new
class StaticPremiumListPricingEngine, which implements PricingEngine.
A backfill @OnLoad is provided to default existing Registry entities
into the static implementation. For now there is just this one
implementation. Dagger map multibinding is used to generate the total
set of allowed pricing engines, and allows other parties to plug in
their own implementations.
The pricing engine is a required field on the Registry object. If you
don't want a particular Registry to actually have a premium list, then
use the static pricing engine but don't actually set a premium list.
A subsequent CL will refactor the Key<PremiumList> field on the
Registry entity class to be handled solely by the
StaticPremiumListPricingEngine implementation. Going forward, all
configuration and implementation details that are specific to a given
pricing engine should be handled by that pricing engine, and not as
fields on the Registry object.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=121850176
The dark lord Gosling designed the Java package naming system so that
ownership flows from the DNS system. Since we own the domain name
registry.google, it seems only appropriate that we should use
google.registry as our package name.
This change renames directories in preparation for the great package
rename. The repository is now in a broken state because the code
itself hasn't been updated. However this should ensure that git
correctly preserves history for each file.
2016-05-13 18:55:08 -04:00
Renamed from java/com/google/domain/registry/flows/domain/DomainTransferRequestFlow.java (Browse further)
