The main thrust of this is to create a common POJO that contains email content in a simple way, then have one class that converts that to an email and sends it. Any class that uses email should only have to deal with creating that POJO.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=237883643
This is no way to make Blaze and Bazel happy at the same point. Without [] Blaze complains about import orders. However the new order breaks Bazel. Bazel suggested to add a suppression to suppress order check, which fixes the Bazel problem, but the suppression string is not recognized by Blaze.
I cannot think of another way to solve this other than MOE. Luckily we'll delete all the BUILD files when we move to Gradle anyway.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=237501133
Note that the Bazel closure rules run the linter at head, while fixjs/cider/critique/etc run the released version, so they will complain about the formatting introduced by this CL until a new release is out.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=237358273
Changed the order of the create registrar form fields and updated the delegate email and country code labels to be more intuitive
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=236354256
This removes the "create Domain/Host/Contact" forms that were supposed to be used instead of regular EPPs for CC-TLD that wanted to support it.
We're removing it because we don't use it and want to reduce unneeded code for the registry 3.0 migration.
Also, this is a security risk, as it allowed to do "billable actions" (creating a new domain for example) with the only authentication being access to the registrar's G Suite account.
This bypassed the certificate, IP whitelist, and EPP password, which is bad.
PUBLIC:
Remove the web console EPP endpoint
This removes the "create Domain/Host/Contact" forms that were supposed to be used instead of regular EPPs for CC-TLD that wanted to support it.
We're removing it because we don't use it and want to reduce unneeded code for the registry 3.0 migration.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=236244195
We set the initial value to the "icann referral email", but registrars can change it later if they want.
Although this value isn't strictly required, we assume it exists in the spec11 report.
Also changed the name of the contact email from "email" to "consoleUserEmail"
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=235734200
We now display the results of each check in addition to the overall result.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=231051913
The most common issues were:
* Arrays.asList() shouldn't be called with a single parameter.
* Broken Javadoc @links.
* Unnecessary casts and type declarations.
* Unnecessary unused variable initializations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=230994311
Most common:
- Unnecessary parentheses and operator precedence clarify (self-explanatory)
- Reference equality--there were a few instances of using == or != improperly
- Qualification of Builder (and similar) imports so that it's clear which type of Builder we're referring to
- Marking some immutable classes with @Immutable since EP desires that all enums be deeply immutable
- String.split() having "surprising behavior"
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=230971531
For now, it only displays a status of "Passed: true|false" or an error message in simple text. In further work we will make the UI nicer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=229971564
There was no reason to have several different modules all providing a single
thing. This approach, which creates a single UtilsModule for everything in the
util package, is cleaner. This also removes provisioning of Random and
StringGenerator objects in RegistryConfig.ConfigModule, which don't belong
there because they aren't configuration options.
This also removes insecure random entirely; it was only used in a
single place to generate 24 bytes a couple times per day. We can live with the
lower speed if it means we don't have to worry about multiple types of Random,
or possibly using an insecure random accidentally in a place that security
actually does matter.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=229751915
This console is only to be used by Admins (either GAE admins for this project, or Support accounts). It is for "internal" use only, not for use by the registrars themselves.
To prevent abuse, the registrar is created in a non-functional PENDING state and can only be made functional from the nomulus shell tool.
While in "PENDING" state, the registrar can be updated from the registrar-console by admins.
Also - moving all the web consoles to the same directory (moving the otesetup/* files into registrar/)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=229681011
This removes the configuration ability on both Registry and Registrar entities
to allow operations on premium domains to succeed without acking the fees using
the fee extension. We only ever used this ability during the minna launch, and
it was a fiasco. We have no intention of ever allowing creation, renewal,
transfer, restoring, etc. of premium domains without acking the fees ever again,
and haven't done so since 2013, so removing this ability allows us to simplify
our code, data model, and tests.
Note that all TLDs in our production system currently require price ACKing
anyway, so from an external partner perspective this commit is a noop.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=229423650
Our goal is to be able to address every Action by looking at the class itself, and to make it clearer at a glance what you need to access the Action's endpoint
Currently, we can know from the @Action annotation:
- the endpoint path
- the Method needed
- the authentication level needed
This CL adds the service where the Action is hosted, which also translates to the URL.
NOTE - currently we don't have any Action hosted on multiple services. I don't think we will ever need it (since they do the same thing no matter which service they are on, so why host it twice?), but if we do we'll have to update the code to allow it.
The next step after this is to make sure all the @Parameters are defined on the Action itself, and then we will be able to craft access to the endpoint programatically (or at least verify at run-time we crafted a correct URL)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=229375735
This makes the validation rules much simpler, thus placing less cognitive load on the users of the console and nomulus tool. The changes are:
1. Don't allow hyphens. No real registrars use hyphens in their client IDs, and it's better to reserve these solely as the delimiter between the base client ID and the number representing the environment.
2. Allow the first character to be a number. This has affected multiple real registrars, causing their OT&E and production client IDs to be different. There's no reason for this restriction, as the only reason motivating it was that there are no TLDs that start with a number. However, the OT&E TLDs are created only in sandbox and never have DNS syncing enabled, so this restriction is purposeless.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=229187198
Added a separator between the fields, and marked required fields as "required", so you can't submit without them
Also - changed from base64 to base58 in for the auto-generated password. It's conceivable that someone might need to read it outloud to someone else - and not having "visually similar" characters (like O and 0) can be helpful.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=228810158
The Visibility field isn't in public Guava yet, so just remove it.
This fixes the breakage caused by []
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=228759870
This also deletes the associated commands and domain application specific
entities.
We haven't used any of these TLD phases since early 2015 and have no
intent to do so in the future, so it makes sense to delete them now so we
don't have to carry them through the Registry 3.0 migration.
Note that, while there are data model changes, there should be no required
data migrations. The fields and entities being removed will simply remain
as orphans. I confirmed that the removed types (such as the SUNRUSH_ADD
GracePeriodType) are no longer used in production data, and left types
that are still used, e.g. BillingEvent.Flag.LANDRUSH or
HistoryEntry.Type.ALLOCATE.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=228752843
Generated code is now also covered by @VisibleForTesting, including Dagger @Inject
This CL is a cleanup of auto-generated code by ghm@ from the Error Prone team
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=228748874
We create a new endpoint with a simple form that will let admins (including
support) setup OT&E for registrars.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=226570568
see b/34094769 for context
The webdriver tests don't choose a correct font when we specify "monospace". As a result, we don't render correctly pages that use monospace.
Here we instead explicitly reference a monospace font we know exists in the webdriver: Courier New.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=226233831
A few nullable parameters were not marked as nullable, which causes exceptions
to be thrown in debug mode.
This had no effect in the deployed web server, because these assert sanity
checks aren't performed - but on our local test server this failed.
Note that all these fields are checked for "nullness" in the code itself. It's
just an oversight in the declaration.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=226187227
SendEmailUtils is a general utility of the web console, and not specifically "only"
to the Registrar console.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=226187094
Currently there's a margin on the top, making the textarea be unaligned with
the text naming it. This is annoying on the eye, and will be more annoying in
the OT&E cl that will be added soon.
- So why not just do this change in that CL?
- Because the changes in the Screenshot tests here are irrelevant to that CL
and I found make it harder to actually review the actual screenshots we're
adding there.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=226057985
Currently the /registrar-settings backend endpoint will fail to update any
OWNER fields that a non-OWNER tries to change.
However, the front-end (soy, js) still allow non-OWNERs to try and change
these fields (there's the "edit" or "add" button, and it only fails when you try to "save")
This CL changes the front-end to remove the ability for non-OWNERs to even try
and change these fields. However, it will still let them *view* these fields as
it has interesting and important information.
-------------------------------
In addition - it changes the webdriver tests to include the "edit buttons". Those were never tested before, and now we will test to see if they are indeed displayed or not.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=223845883
The console will have 2 different "updatable things":
- only ADMINs (GAE-admins and users in the support G-Suite group) can change the things in the "admin settings" tab (currently just the allowed TLDs)
- only OWNERs can change things from the other tabs: WHOIS info, certificates, whitelisted IPs, contacts etc.
Also, all ADMINs are now OWNERS of "non-REAL" registrars. Meaning - we're only
preventing ADMINs from editing "REAL" registrars (usually in production).
Specifically, OTE registrars on sandbox are NOT "REAL", meaning ADMINS will
still be able to update them.
This only changes the backend (registrar-settings endpoint). As-is, the console
website will still make ADMINs *think* they can change everything, but if they
try - they will get an error.
Changing the frontend will happen in the next CL - because I want to get this
out this release cycle and getting JS reviewed takes a long time :(
TESTED=deployed to alpha, and saw I can't update fields even as admin on REAL
registrars, but could change it on non-REAL registrars. Also checked that I can
update the allowed TLDs on REAL registrars
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222698270
EppConsoleAction still "manually" checks access by going over the
RegistrarContacts. We need it to use AuthenticatedRegistrarAccessor just like
every other part of the registrar console.
We still need to remove the (now unneeded) login EPP sent by the console, but that's left for a followup CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222404208
This is a temporary measure until we implement access control for Support.
Once we implement access control, we will only block Support from removing TLDs
on production.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222180321
It is starting to be used in more places than just ur/server/registrar. Even now it's used in the RDAP, and we are going to start using it for the registrar-xhr endpoint meaning it will be used in EPP flows as well.
Also logically - this is part of the request authentication.
While moving - we also refactor it to make it easier to use in tests. Instead of mocking, we will be able to create instances with arbitrary roles.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221645055
After this CL, "support" accounts (accounts that are part of the "support" G-Suite group) will the same access to the registrar console as GCP "admins". However, they don't won't have access to the GCP project itself.
We could give them their own Role in the future (say SUPPORT) and give them different access than "admins", but right now we don't need it and YAGNI or something :)
NOTE: we identify users by their email (they need to be logged in to a google account). I don't know if that's best practice, since I guess different google accounts might have the same email address. However, G-Suite groups' membership is by email so there's not much we can do about it if we want to use G-Suite groups.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220804273
This tab will set the "allowedTlds", but might have other functionality in the
future.
It is based on (branches from) the security-settings tab, because I'm copying the functionality of the "whitelisted IPs" to the "allowed TLDs": they are both lists of "arbitrary" strings that you can remove from and add to.
There are a lot of moving parts in this CL, because of how all the different elements need to interact, and how intertwined they are (for example, we need to disable the admin-settings view for non admins both in the soy and in the JS code)
It's really time to refactor the console given all we've learned... :/
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220373443
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
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
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
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
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
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
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
