There's so little meat here that there's not much
reason to break this cl up any further
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133171754
This allows handling of N asynchronous deletion requests simultaneously instead
of just 1. An accumulation pull queue is used for deletion requests, and the
async deletion [] is now fired off whenever that pull queue isn't empty,
and processes many tasks at once. This doesn't particularly take more time,
because the bulk of the cost of the async delete operation is simply iterating
over all DomainBases (which has to happen regardless of how many contacts and
hosts are being deleted).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133169336
The RFCs are ambiguous.
5733 (contacts):
3.2.4. EPP <transfer> Command
...the
<transfer> command MUST contain a <contact:transfer> element that
identifies the contact namespace. The <contact:transfer> element
contains the following child elements:
...
- A <contact:authInfo> element that contains authorization
information associated with the contact object.
However, the xsd explicitly marks it as optional:
<complexType name="authIDType">
<sequence>
<element name="id" type="eppcom:clIDType"/>
<element name="authInfo" type="contact:authInfoType"
minOccurs="0"/>
</sequence>
</complexType>
The language in 5731 (domains) is [] The only example given in both is for a transfer request, which is the one flow that obviously requires the authInfo.
We had decided that for transfer approve and reject, which are done by the losing client, requiring the authInfo is silly because it's available to that registrar from an <info> and there's no extra security in having them present it (although if they do present it we validate it). The question about cancel was whether the gaining client, which had to present the authInfo in the original transfer request, needs it again for cancel.
I can't come up with any reason this would be beneficial, and I'm making the decision: authInfo is not required on transfer cancel.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133168739
Other flows to come. This removes the need for
most of the flows to inject the command at all.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133163030
Although the delta implies that this is actually adding code, it's
better than it looks, because some of the stuff in ContactFlowUtils
is duplicating more generic methods in ResourceFlowUtils, which
can be deleted when the domain and host flows are cut over.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133149104
This allows us to inject an optional once, in FlowRunner, and
inject a non-null value in the flows (not done yet, after this
goes in).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133130485
There was very little meat in the contact hierarchy and it
flattened quiet easily.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133080191
The exceptions created for generic problems with the flags extension (invalid flag, etc.) should be in a common location, so they can be used by all interested TLDs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133040831
This factors out a huge chunk of boilerplate that
would otherwise be in every single flow.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133014837
By duplicating rather than moving them, I can keep both versions
around while I port the flows over to the new flat form.
I could have made these g4 moves from the original sources, but
there's barely anything in these files and it didn't really seem
like it was adding anything useful.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132999387
Getting rid of builder boilerplate makes my heart sing. Since we can no
longer @Inject the Builder() constructor, this change adds a provider
in WhiteboxModule that calls a special builderForRequest() factory method,
which gets passed a request ID and Clock and preserves the existing
EppMetric magic that sets the start and end time for you.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132714432
This disentangles GaeUserCredentials and UserService, which lets us remove a
bunch of hacky and brittle code from LoginFlowViaConsoleTest.
Previously, GaeUserCredentials was constructed for a user, but then was still
directly calling UserService to check if the user was an admin. UserService
can be adjusted in tests (via AppEngineRule / LocalServiceTestHelper) but it's
a pain, especially to do dynamically within a single test file. The hacky
code in LoginFlowViaConsoleTest was working around that restriction.
With this CL, you can pass into GaeUserCredentials whether the user is an
admin or not (for testing) or construct one directly from a UserService object
(for production, and for convenience in tests using an AppEngineRule user).
Note that I also changed EppConsoleAction to @Inject UserService.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132696391
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
This change refactors EppMetrics from the mutable self-exporting thing that it
was into a real value type EppMetric, and delegates exporting functionality to the
BigQueryMetricsEnqueuer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132387660
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
It's better that it always takes a non-null ImmutableSet, which may either be
empty or contain elements. That way the ugliness of nullness is contained
just to the entity class itself, and all other code that interacts with it
can always be assured of having a real set to deal with.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132066238
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
This CL adds the hooks necessary to implement TLD-specific flow info and update flow logic. Usage of the hooks follows in a separate CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130108832
ECatcher seems to trigger on warnings, even if no exception is thrown (?). This warning doesn't really need to be a warning if it's WAI and not something we're actually going to bother to reach out to registrars about (in this case, 101domain apparently isn't declaring the launch extension, but we let them use it anyway).
If at some point we decide to be stricter about declaring extensions and want to go determine how often this is happening, making it INFO vs WARNING doesn't make that any harder.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130016606
This is an internal-only feature that breaks the open source build.
CL created with:
dr-replace '(compatible_with.*)' '\1 # MOE:strip_line'
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=128852873
For the .app discounting logic, we need a new extension which will let
registrars set, clear and query custom flags on a domain. Hopefully
this will be reusable for other custom TLDs later. This CL adds the
XSD, the associated classes for marshalling and unmarshalling, and some
marshalling tests, and links the classes into the system-wide extension
lists.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=128178999
This feature would have been useful earlier when I was changing the TLD
state on a sandbox TLD on-the-fly for testing purposes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=128088578
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
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
