A CurrencyUnit-to-BillingAccountEntry map is persisted in the Registrar entity. It provides flexibility for billing systems that assign different account ids for accounts under different currencies of the same registrar.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151022753
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
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 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
In fact, completely eviscerate cloneProjectedAtTime (to be removed in
a followup CL) in favor of doing the projection of transfers and the
loading of values from the superordinate domain at call sites. This
is one of the issues that blocked the memcache audit work, since the
load inside of cloneProjectedAtTime could not be controlled by the
caller.
Note: fixed a minor bug where a subordinate host created after its superordinate domain was last transferred should have lastTransferTime==null but was previously reporting the domain's lastTransferTime.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=149769125
A test has been added to RequestHandlerTest, making sure that, while we merely log errors for the time being, the correct dummy AuthResult is being created.
Most actions use the default settings, which have been changed to INTERNAL / APP / IGNORED. Actions with non-default settings are:
INTERNAL/NONE/PUBLIC (non-auth public endpoints)
CheckApiAction
WhoisHttpServer
Rdap*Action
INTERNAL,API/APP/ADMIN (things currently protected by web.xml)
EppTlsAction
EppToolAction
CreateGroupsAction
CreatePremiumListAction
DeleteEntityAction
List*sAction
UpdatePremiumListAction
VerifyOteAction
WhoisServer
INTERNAL,API,LEGACY/USER/PUBLIC (registrar console)
RegistrarPaymentAction
RegistrarPaymentSetupAction
RegistrarSettingsAction
EppConsoleAction
INTERNAL,API,LEGACY/NONE/PUBLIC (registrar console main page)
ConsoleUiAction
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=149761652
Refactor command and component code in RegistryCli so that we can handle a
LoginRequiredException from whereever we are likely to ever get one.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=149329171
Refactor the auth code into its own dagger module, add tests and use the new interfaces to implement the login and logout commands.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=149108266
For constant field declarations, you should use the immutable type (such as ImmutableList) instead of the general collection interface type (such as List). This communicates to your callers important semantic guarantees ([]
This change replaces constants (static final CONSTNAT_CASE) declaration type which use the general collection interface (e.g. List) with an immutable type (e.g. ImmutableList).
For more info, see: []
Cleanup change automatically generated by javacflume/refactory
Refactoring: //third_party/java_src/error_prone/project/core/src/main/java/com/google/errorprone/bugpatterns:MutableConstantField_refactoring
Tested:
TAP --sample for global presubmit queue
[]
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=149010021
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
There's a deleted domain with bad host resource keys. Since FKIs won't help us here, load a domain directly by key (i.e. by ROID) if we so choose.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148685240
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
It was kind of messy having all of that logic living alongside the
entities themselves.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148498024
This also cleans up the PremiumList API so that it only has one
method for checking premium prices, which is by TLD, rather than two.
I will be refactoring a lot of the static methods currently residing in
the PremiumList class into a separate utils class, but I don't want to
include too many changes in this one CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148475345
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
Store the auth credentials under a name qualified by the set of OAuth scopes
as well as the client id. This is implemented as the base64 encoded SHA1 hash
of the concatenation of client id and sorted auth scopes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148127911
Seems silly that one command uses --tlds for the required parameter, while the other one doesn't.
As part of this change, create a DateParameter for commands that require only a date (i.e. a DateTime parameter restricted to midnight UTC).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=148106721
The one-day validity period is also moved from the caller into XsrfTokenManager.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=147857716
Implement client-side OAuth in non-local HTTP connections. Also add tests to
verify that the different modes of connection are set up correctly.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=147636222
It was somewhat unsafe to run because it bypassed some of the checks
that are usually run when attempting to delete EPP resources. The
DeleteDomainCommand is a recommended replacement that uses SOY templates
to delete a domain using EPP. Similar commands to delete hosts and
contacts can be written if required.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=147634146
There are about 25 active domains that have keys that point to deleted nameservers. In all cases, there are active nameservers with the same FQDN that these domains should be pointing to. Given the domains in question (pulled via BigQuery, see the bug), update the domain with the correct keys whenever a deleted host is found.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=147346660
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
Move all of the code to create the request factories into
RequestFactoryModule. Also add the --force_http_connection flag to allow us
to force the use of HTTP connections instead of HTTPOverRPC for our internal
connections.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146116640
Among the Futures methods that run user callbacks, those that don't take
an Executor will be deleted. This CL migrates them to the counterparts
that take MoreExecutors.directExecutor() as such Executor in the
parameter list, exactly the way that the old method works.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145358533
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 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
Effectively a revert of [] now that synthetic billing events have been verified in production.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144473744
