mirror of
https://github.com/google/nomulus.git
synced 2025-07-25 20:18:34 +02:00
6bddd5a8cb
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
|
||
|---|---|---|
| .. | ||
| backup | ||
| batch | ||
| beam | ||
| bigquery | ||
| builddefs | ||
| config | ||
| cron | ||
| dns | ||
| env | ||
| export | ||
| flows | ||
| gcs | ||
| groups | ||
| idn | ||
| keyring | ||
| loadtest | ||
| mapreduce | ||
| model | ||
| module | ||
| monitoring/whitebox | ||
| pricing | ||
| proxy | ||
| rdap | ||
| rde | ||
| reporting | ||
| request | ||
| security | ||
| storage/drive | ||
| tldconfig/idn | ||
| tmch | ||
| tools | ||
| ui | ||
| util | ||
| whois | ||
| xjc | ||
| xml | ||
| BUILD | ||
| repositories.bzl | ||