LINKED is a virtual status that needs to be computed on the fly
when creating an RDAP response.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145583415
This also bypasses signed mark validation during domain creation if
the flow is being executed as superuser.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145435268
This implements the basic framework that allows global YAML
configuration, per-environment custom configuration, and unit-
test-specific configuration.
TESTED=I deployed to alpha, ran some EPP commands through the
nomulus tool, and verified no errors.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145422680
Also more narrowly scopes a catch block in TmchCertificateAuthority.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144744847
We no longer care about ROID suffix uniqueness in a post-Registry-2.0-migration
world, and the Registry cache is sufficient for efficiently grabbing the ROID
suffix for TLDs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144483726
The command still enforces uniqueness (which is fine), but by changing the cache
from a BiMap to a Map, we can support non-unique suffixes if they happen to be
configured as data. The only reason the cache was ever a BiMap in the first
place was to support the Registry 2.0 migration, which was finished a year and a
half ago. It's only being read one way now, so a Map is fine.
See https://github.com/google/nomulus/pull/53 for context.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144381946
This allows us to use util methods from within config, which is a useful thing
to be able to do for, e.g., being able to log errors while loading configuration.
It makes sense that the util package should be at the very base of the
class inheritance hierarchy; config seems logically higher than it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144324273
This is probably best from a code-cleanliness perspective anyways,
but the rationale is that tightly coupling the resources to the
info responses was a straightjacket that required all status
values and fields to be directly available on the resource. With
this change, I already was able to get rid of the preMarshal()
hackery, and I will be able to get rid of cloneWithLinkedStatus()
and most of the contents of cloneProjectedAtTime() for non-domains.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144252924
In the previous CL I added filter support for the test server, but
even though I could verify that filters were being run when debugging,
in practice the side effects of the filters (notably, ObjectifyFilter
clearing the session cache) were somehow not present in tests (and
therefore causing new as-yet unsubmitted tests that rely on proper
session caching to break).
Investigating further, the way TestServer works is that it creates
a wrapper Servlet for each route, and in that wrapper just pushes
a future onto a queue and waits on it. The actual target servlet
is run within the queue, not within the wrapper servlet's context.
I had added filters to the *wrapper* servlet, which meant that even
though they were invoked before adding the task to the queue, they
were not invoked in the process of actually running the task.
In this CL I pushed the filters into the task itself, just like the
target servlet.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144123637
This is the final preparatory step necessary in order to load and load
configuration from YAML in a static context and then provide it either via
Dagger (using ConfigModule) or through RegistryConfig's existing static
functions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143819983
We are now ready to begin configuration using YAML, mediated by ConfigModule.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143818507
The next step will be to get rid of RegistryConfig descendants and RegistryConfigLoader entirely.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143812815
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
This primarily addresses issues with TMCH testing mode and email sending utils.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143710550
The HistoryEntrySubject.actualCustomStringRepresentation() was calling a superclass method which ultimately called HistoryEntrySubject.actualCustomStringRepresentation(). So any test which failed due to a HistoryEntry problem resulted in a stack overflow error instead of a more helpful error indicating the actual problem. The solution is not to call the superclass method.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143702856
Currently, the recurring billing expansion chokes when looking for existing OneTime events for domains that are deleted or transferred at the MR execution time. To fix this, change the FKI query to look for a key at either execution time or recurrence end time, whichever is earliest.
(This one is distinct from [] in that this bug occurs when domains are [] deleted.)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143693153
The recurring billing event expansion fails when handling domains that are transferred or deleted before the initial renew. Quietly ignore these recurring events.
(This one is distinct from [] in that this bug occurs when domains currently exist under new ownership.)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143594317
This is a necessary prerequisite to subsequently injecting the configuration
dependencies.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143567753
I'm setting it to three buckets across all tests, because the default one bucket
wasn't realistic enough, and allowed some tests to pass that shouldn't have,
essentially by accident.
This also changes RegistryConfig from being an interface to being an abstract
base class. The medium term goal here is to have it be a static class so that it
can provide fields from the YAML-derived POJO in situations where Dagger
injection isn't feasible.
The expected end state is as follows:
default-config.yaml -- The master config file that provides defaults for all
values.
nomulus-config.yaml -- A per-environment config file that overrides the defaults
from the previous file.
YamlConfig.java -- The POJO that the aforementioned YAML files are deserialized
into.
RegistryConfig.java -- Contains a static, memoized instance of YamlConfig and
provides static methods for getting some of those values.
ConfigModule -- Will become a static inner class of RegistryConfig, using Dagger
to provide most of the fields from the memoized YamlConfig instance. This way,
all configuration will be coming from a single place: RegistryConfig.java.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143567288
We're now using java_import_external instead of maven_jar. This allows
us to specify the relationships between jars, thereby allowing us to
eliminate scores of vendor BUILD files that did nothing but re-export
@foo//jar targets, thus addressing the concerns of djhworld on Hacker
News: https://news.ycombinator.com/item?id=12738072
We now have redundant failover mirrors, which is a feature I added to
Bazel 0.4.2 in ed7ced0018
A new standard naming convention is now being used for all Maven repos.
Those names are calculated from the group_artifact name using the
following algorithm that eliminates redundancy:
https://gist.github.com/jart/41bfd977b913c2301627162f1c038e55
The JSR330 dep has been removed from java targets if they also depend
on Dagger, since Dagger always exports JSR330.
Annotation processor dependencies should now be leaner and meaner, by
more appropriately managing what needs to be on the classpath at
runtime. This should trim down the production jar by >1MB. As it stands
currently in the open source world:
- backend_jar_deploy.jar: 50MB
- frontend_jar_deploy.jar: 30MB
- tools_jar_deploy.jar: 45MB
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143487929
This is the first in a decently long series of commits to delete RegistryConfig
entirely and centralize all configuration in ConfigModule using Dagger. Once
this is done, then the text-based YAML configuration work can begin in earnest.
Note that the configuration settings from TestRegistryConfig will be moving
into ConfigModule.LocalTestConfig. This way they can be referred to in a static
context from test and test utility helpers, rather than having to be injected
everywhere, which we don't typically bother with for tests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143473089
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 some clarity on when to use the non-incrementing version.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143037508
It wasn't being used by any actual code, and having helper methods handling
saving/persistence on entities like this is not a pattern we want to encourage,
since it hides Datastore transactions from further up in the call chain. The
idea is that you can always look for ofy() calls in the same layer of code to
see where persisted data is being changed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143036027
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
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
By moving []s into the batch package, which is not included in the frontend service, we pave the way to remove the dependency of frontend on the [] library.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142265351
The open source build uses a single shard for the rde package's tests. In order to account for the longer runtime, increase the timeout for this package.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142261623
Per a passing conversation with Corey, want to make sure that anchor tenants can still register during an active LRP period. No changes to the flows, just some explicit testing.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142181395
We should be able to remove the dependency on the App Engine [] library from the frontend service, since no []s actually run there. In order to do this, we need to remove the various []-reliant classes from the frontend service build. This CL begins the process by moving the two async "flows" to a different package which is not included in the frontend service.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142159568
In my previous refactoring I failed to realize that getResource() was not
returning the contents of the file.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=142065550
