Folks, The question is not about "+1" or "-1". The question is "why?".
This looks like some special feature to solve some special security issue but may be just a bad/broken/obsolete/unrefactored code. Changing this semantic we'll fix bad code or break some contract. 50% to 50%. Let's keep REST case as is for now but start an investigation to gain security consistent across all APIs, if possible. On Tue, Mar 31, 2020 at 4:59 PM Andrey Kuznetsov <stku...@gmail.com> wrote: > I'd prefer marking ADMIN_CACHE as deprecated, but postpone its removal from > GridRestProcessor till next Ignte release (2.10 or 3.0?). For now we could > just add checks for CACHE_CREATE / CACHE_DESTROY there along > with ADMIN_CACHE. > > вт, 31 мар. 2020 г. в 12:30, Nikolay Izhikov <nizhi...@apache.org>: > > > Hello, Sergey. > > > > > > I’m +1 to make this change. > > > > I think we should make security consistent across all APIs. > > > > > 31 марта 2020 г., в 12:14, Sergei Ryzhov <s.vi.ryz...@gmail.com> > > написал(а): > > > > > > Hello! > > > Now the work of permissions for API IgniteClient and REST is different. > > > To create/delete a cache: > > > IgniteClient authorises > > CACHE_CREATE/CACHE_DESTROY.(GridCacheProcessor#authorizeCacheCreate < > > > https://github.com/apache/ignite/blob/aefad946ebd7720f81b460aa39e205c10dc24b26/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheProcessor.java#L3983 > >, > > authorizeCacheDestroy < > > > https://github.com/apache/ignite/blob/aefad946ebd7720f81b460aa39e205c10dc24b26/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheProcessor.java#L3973 > > >) > > > REST authorises ADMIN_CACHE.(GridRestProcessor#authorize < > > > https://github.com/apache/ignite/blob/aefad946ebd7720f81b460aa39e205c10dc24b26/modules/core/src/main/java/org/apache/ignite/internal/processors/rest/GridRestProcessor.java#L841 > > >) > > > I think this is inconsistent. > > > > > > I suggest ADMIN_CACHE mark @Deprecated > > > and replace it in the GridRestProcessor with CACHE_CREATE / > > CACHE_DESTROY > > > while maintaining backward compatibility for ADMIN_CACHE. > > > > > > This will allow us to remove ADMIN_CACHE in the future. > > > > > > > > > > > > Sergei Ryzhov > > > s.vi.ryz...@gmail.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Best regards, > Andrey Kuznetsov. >
