The cardinality of this new metric is:
buckets - 16
path + method - around 100 (the number of Actions we have)
authLevel - at most 3
success - 2
Total: 16*100*3*2 = 9,600
This is still low, especially for the value it could give in understanding our system (graphs of all endpoints, how often are they called, how long they take, how often do they fail)
Instead of "success true/false", we might want to give the actual status code. This can be a bit annoying because HttpServletResponse doesn't have a getStatus.
But it's possible, and worth considering.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219312400
Having a log at the very begining of "our" code helped us find issues with
App-Engine's dispatcher, where we could clearly see in the logs that "our" code
started many seconds after the request came in.
We now suspect there is something similar going on after the end of "our" code
- where the reply is sent back many seconds after our code finished running.
To make sure - we add a log statement at the very last line of "our" code, so
we know exactly when it ended.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219309962
Move the shell output encapsulation so that we don't double-wrap on a
premature exit.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219136896
AppEngineConnection can now connect to all services and not just the tools.
The default is still the tools.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218734983
Cardinality of this metric:
clientId: there are currently 650 (on sandbox, because of OTE), and 200 on production.
explicitClientId: 2
roles: 2 now, might be 3 soon if we add vendors
status: 2
So we're talking about a cardinality of 2,000-8,000. Less when you consider that registrars only seldom actually need to access the console (certainly not daily or even weekly).
Compare with, e.g., the /epp/processing_time from the above EppMetrics.java which has:
Epp commands: 26 (manual counting)
client IDs: 200 on prod
status: the actual status CODE of the command. Can have many values, but looking at the past few weeks' metrics I counted 20
Note that not every command results in every status. Looking a few weeks back we can see around 80-100 (commands+status) combination.
buckets: 16
so that's over 250,000-1,000,000 cardinality, on a very high-volume metric.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218699280
The main goal of this CL is to make the clock constructor injectable (so that tests do not need to use InjectRule to override the clock). The complication is that the clock is used by two static caches (ROOT_CACHE directly and CRL_CACHE indirectly). The clock is not actually used to construct the lock, but rather to verify that the root certificate is within its validity period.
For ROOT_CACHE we move the verification to its call sites. This adds a bit overhead because the validity check happens every time the cache is called, not just when the cache is built or refreshed. However this check is rather cheap. Also the resources are included in the jar and the cache is valid for 1 year. Given that we deploy every week, there's not much point making it an expiring cache rather than a static map.
For CRL_CACHE we change the key to a tuple of TmchCaMode and X509Certificate. The certificate is no longer provided from the ROOT_CACHE directly and must be verified before it is provided as a cache key. We left the CRL verification inside the cache loader because it (signature verification) is more expensive compared to simple expiration check, and we do not want to do this every time the cache is called.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218385684
Instead of verifying interactions on the mocks, we instead assert on the real test subject directly.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218209556
This CL removes the "READ vs UPDATE" feature completely. Now anyone with access
has full read+write access.
We still keep track of which role a user has (did they get access "explicitly"
because they are an "allowed access" contact? Or do they have access because
they are admins?) for the logs and UI, and also so we could in the (very near)
future have features only available to admins.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218169608
Make every dependency request explicit on what encoding is used. Also get rid of InjectRule in XjcToDomainResourceConverterTest.
Random number generator providers are separated to secure and insecure ones. The insecure ones must be explicitly requested (usually for use cases where security is not of concern, for better speed).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217921422
All RDAP actions inherit from a common RdapActionBase class.
All RDAP search actions inherit from a comman RdapSearchActionBase class, which inherits from RdapActionBase
Each of the base classes has @Before initialization needed for the tests, as well as utility functions (such as login and logout).
Currently, these were copied in all test classes. Instead, we created a similar test inheritance tree to centralize the initialization and place common utility functions.
This way, the @Before of every test only needs to initialize the variables new to the specific action, making the code somewhat clearer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217856844
Made it clear that it is a util class and moved some of the functions only used in NordnUploadAction (to NordnUploadAction). Also used Retrier to handle retries when leasing tasks.
These changes allow us to no longer use InjectRule in related unit tests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217761117
When creating the various registrar objects in Sandbox for OTE, we also give access to all the registrars' data to a given google account (identified by the email)
This email has to belong to the registry's G-Suite account, just like in the registrar_contact command.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217728407
This is what you want most of the time when you're running the command to
see recent domains, as this will list all the real billable domains and
exclude the prober ones.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217603275
Someone may @Inject a Random at some point in the future where security matters,
so always provide a secure one.
Also, this shouldn't be in ConfigModule (it's not configuration) -- but that can
be changed separately. We might want a larger refactor that has a utils module
or similar to provide extremely generic things like random number generators.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217602486
com.google.common.base.Randoms.insecureRandom is not open sourced.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217598084
Random used to be a static variable which requires InjectRule to mock it in unit tests. It is now a singleton, which ensures that the same instance is called every time and Random.nextBytes() generates results that distribute uniformly between each call.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217592767
This allows us to inject it with Dagger and avoid using InjectRule to set it
in unit tests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217571475
Whenever a registrar is changed via the registrar console, we send out a
notification of that change.
Since we're going to allow Admins and soon Vendors to use the console in
addition to the registrars, it becomes important to know who actually performed
the changes if the registrars complain.
In addition, we will now send notifications for changes in Sandbox since we're
going to actually allow registrars to update sandbox data.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217539534
This is an additional signal we can use for the billing/invoicing pipeline that
will be helfpul in targeting invoice rows that may need adjustment.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217524250
We limit the maximum number of concurrent connections that a client can make the proxy. The quota is implemented as a (thread-safe) map of client certificate hash to available number of connections. When a new connection is made, we decrement the availability counter by one. When the counter hits zero, no more connections can be made and any new connection from the same client is terminated by the proxy.
Currently, the counter is incremented when a connection is terminated, including connections that are terminated *because* the quota is reached (i. e. the connections for which the counter is not decremented because the counter is already zero). This means that the first time the quota is reached, the next connection is dropped, the counter is incremented to 1 and new connections can be made again, bypassing the quota. This process can be repeated to achieve, theoretically, infinite quota.
This CL fixes this bug by only incrementing the counter, upon connection termination, for connections that have decremented the counter in the first place.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217231593
There is no "google_project" resource managed by terraform, so we are not worried about the new terraform binary destroying/re-creating GAE resources.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217206226
SessionUtil is renames AuthenticatedRegistrarAccessor, as it's used to access a registrar for an authenticated user.
It will now be injected with the AuthResult instead of receiving it in every function call, since there's only one "legal" AuthResult to use.
The AccessType names are changed from READ_ONLY/READ_WRITE to READ/UPDATE, as it was confusing that a user could have both READ_ONLY AND READ_WRITE access to the same registrar.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=216958306
This uses a Dagger-provided map of Keyring implementations, with two currently available,
"KMS" and "Dummy". The active keyring is configured in the YAML file, so we no longer
require MOE directives to choose which one to use for internal/external builds.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=216898058
The following issues are addressed:
- XML sanitizer should preserve input encoding. Gradle loses any that is not UTF-8. Bazel loses any that is not ASCII.
- Verify that XML sanitizer works with non-UTF8 encoding
- GpgSystemCommandRule breaks when $TMPDIR env variable is not set
- TestDataHelper throws exception when loading resources if resources are plain files on default file system as opposed to being in a jar file.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=216537258
These are simply too costly in their current form now that we are handling double-digit QPS, so at a minimum we'd want to refactor these for batched exports using a background thread (like how Stackdriver metrics work). However, upon further review, that work isn't worth doing if this BigQuery table isn't actually being used for anything, and it seems that we aren't using it anymore given that ICANN transaction reporting no longer requires it.
So the simplest thing to do is simply to get rid of this entirely, and just use a combination of Stackdriver metrics and App Engine logs. The eppMetrics BigQuery table is ~1.2 billion rows and takes up 223 GB, so that's not an insignificant GCP billings saving if we can delete it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215905466
Note that the check flow does not yet handle any kind of allocation token
handling at all. Step 2 will be to add allocation token handling there, so a
RESERVED_FOR_ANCHOR_TENANT or RESERVED_FOR_SPECIFIC_USE domain will show as
available instead of reserved if the right token is specified using the
extension. Then once that's done, we can use that information to adjust the
price accordingly as well.
Right now the behavior with a domain check is that reserved domains always show
as reserved, even if they're anchor tenants.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215599350
We want to be able to view / test / debug how the registrar console looks for our clients.
However, we don't want to accidentally change the data for registrars, especially in a "non-accountable" way (where we later don't know who did that change)
So we do 2 things here:
- Add a "mode" (read-only and read-write) to the getRegistrarForUser function. We set it according to what we want to do with the registrar. Currently, read-write is only requested for the "update" RegistrarSetting action. Admins will have read-only access to all registrars, but read-write access only to the "admin registrar" (or whatever registrar they are contacts for).
- Support an undocumented "clientId=XXX" query param that replaces the "guessClientIdForUser" function in the original page load. We can then set it when we want to view a different account.
We also change the navigation links on the HTML page to preserve the query.
-------------------------
This might be used also for a better user experience for our clients, especially those with multiple "clientId"s (some registrar entities have multiple "registrar" objects)
Currently, they have to have a separate user for each clientId, and only have one user allowed which has both read and write permissions.
Using this change, we can give them the possibility to add users on their own, some with read-only access (to view billing information without being able to change anything), and use a single user for all their clientIds.
-------------------------
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215480610
All credentials provided by these modules have been
replaced by those in the config/CredentialsModule,
with a new set of Qualifiers. With Dagger 2, a successful
build means that the removal is safe.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215258792
RegistrarSettingsAction is a JSON in / JSON out endpoint, meaning the reply is consumed as JSON.
The current state is that if an error occurs, there are two possible replies:
- a JSON error reply is sent out, or
- a 402 HTML reply is sent out with the exception.getMessage()
The difference is only - do we actively catch the exception to translate it to JSON or not.
This fix catches ALL exceptions and translates them to JSON format. Note that there's no security change by giving the getMessage in the JSON reply since we were returning that anyway (in the HTML).
In addition - changed the "gaeUserId" to "user.getEmail" as the identifier, since it's clearer to the users who see that error - and I do want to transition to a more "email identifier" way of checking access (since that's what users put in the registrar contact info)
This too isn't leaking new information because
- the initial HTML page load already gives the user's email, and
- the logs already log the user's email for every request
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215213807
com_google_truth has a dependency on diffutils that we're not exposing. This
becomes problematic in cases where certain tests fail and the equality check
can't show the difference. If this happens, instead of the original failure
all we see is a failure to load diffutils.
Note that com_google_truth appears to have some other dependencies that we are
also not exposing, but that so far these have not been problematic.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214774587
We now require the URL to be filled out by all registrars and so there is no
default needed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214774054
Looks like a copy-paste error from the reserved list export disclaimer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214773560
Replaced the plethora of inter winding access functions and inputs in SessionUtils with just 2 functions, that both accept the same type for the user (AuthResult):
guessRegistrarForUser: given an AuthResult, finds a registrar that they have access to. If none is found - a ForbiddenException is thrown.
getRegistrarForUser[Cached]: (maybe should be called getRegistrarOnBehalfOfUser?) given an AuthResult and a clientId, loads and returns the registrar ONLY IF the user has access to it. Otherwise throws a ForbiddenException.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214630657
This is an intermediate CL, part of the Registrar Console cleanup.
TL;DR:
- the current state: resource.js points to a resource TYPE on the server (only registrars can be resources right now), but the specific resource is selected based on the user (we select the "first resource of this type that the user has access to)
- new state: resource.js points to a SPECIFIC resource (TYPE + ID).
In this CL the server still chooses the resource like before (first one that user has access to) but we make sure the returned resource is the same one we requested.
In a subsequent CL we will use the requested ID to load the resource, and then make sure the user has access to that resource.
---------------------------
When loading the RegistrarConsole HTML page, the server determines which clientId belongs to the user ("guesses" it by looking for the first registrar that has this user as contact). It sends the relevant clientId back with the page load.
However, this information isn't currently used in the JS requests to read / update the registrar. Instead, currently the client ID is guessed again for each JS access to the server. It is also saved again in the client's "session" cookie.
As a result, it is theoretically possible to have the JS access a different clientID than the original page load (not likely, since it requires a single user registered for multiple registrars AND that the contacts change for the original registrar).
So our goal is to only have a single clientID "value" instead of the 3 we currently have for JS requests (the one from the initial page load, the one saved in the session cookie, the one guessed on the JS request)
As a first step, we send over the "initial page load" clientId on every JS request, and make sure the "session + guessed" value is equal to that one. Later we will remove the "session+guessed" values from the RegistrarSettings, using the "initial page load" clientID instead.
In addition to the "nicer code" implications, having the clientID from the initial page load always used means it'll be easy to have a clientID selection option for users who have access to multiple clientIDs (such as admins)
SECURITY NOTE:the choice of clientID has no security implication since we make sure the user has access to the clientID no matter how we actually choose the clientID on every single server request.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214459506
We need this to efficiently query which tokens have and have not been redeemed.
I'm also marking it as nullable for consistency with the domain name field (it's
already null for unredeemed tokens).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214366534
*** Reason for rollback ***
Automated tools sometimes don't have default credentials, and can't set them up. We should redo this CL once we figure out the credential thing.
*** Original change description ***
Add metrics for the command used in the registry CLI tool
Puts the metric in <project>/tools/commands_called
It counts the use of the tool, with the following labels:
- environment
- tool (nomulus/gtech)
- command called (class name)
- success true/false
- from the shell true/false
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214048616
We have several "consoles" ("views" in the registrar console). They all affect the same resource - the registrar itself.
Currently, each view creates its own "RESTful resource", even though it's the same resource for all of them, meaning we have copied code and copied "URL endpoint" across multiple files.
I assume this was made so that IF one day we have a "view" to another resource, we can easily add it. But we currently don't have any such view, nor plans to add any.
So according to the YAGNI paradigm, it's better to move the resource creation outside of the console.
Also, IF we do add a view to a different resource - it'll still be more readable to have a map from the "view" to the "resource URL endpoint" alongside the existing map from the "view" to the "console"...
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213992967
This fixes the Kokoro tests broken by []
Unfortunately this means that the return type changes from a Map to an Object as well,
so all of the .get() lines need to turn into []. Yay weakly typed languages. And
apparently in some error conditions this method could already return the Object type
anyway, even if you passed in a Map, so it's just poorly designed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213808477
