Diplomat is atomising all property names (which can be atoms or strings)
recursively in order to compare them with the exclude list (which is always
atoms). This means new atoms will be dynamically generated, filling up the
atom table.
If there was an expectation of a predefined schema, this would put an upper
bound on the number of the generated atoms, but in Google Cloud Datastore,
there is not. Users can potentially store entities with dynamically generated
property names.
This can easily become a security vulnerability. Imagine an API which stores all
requests to it in DataStore for analytics using Diplomat. If the headers are
represented as a map, it will be atomising user input. Anyone on the internet
can now crash it by sending enough requests with randomly generated headers and
exhausting the atom table.
This changes that part of the code so that atoms are being converted into
strings instead.
Diplomat is atomising all property names (which can be atoms or strings) recursively in order to compare them with the exclude list (which is always atoms). This means new atoms will be dynamically generated, filling up the atom table.
If there was an expectation of a predefined schema, this would put an upper bound on the number of the generated atoms, but in Google Cloud Datastore, there is not. Users can potentially store entities with dynamically generated property names.
This can easily become a security vulnerability. Imagine an API which stores all requests to it in DataStore for analytics using Diplomat. If the headers are represented as a map, it will be atomising user input. Anyone on the internet can now crash it by sending enough requests with randomly generated headers and exhausting the atom table.
This changes that part of the code so that atoms are being converted into strings instead.