I am assuming we are storing the query IDs per client on the server side, right? How about storing client ID on the server side as well, together with the query-id and returning an error whenever the clientID does not match?
On Wed, Nov 4, 2015 at 1:13 AM, Alexey Kuznetsov <[email protected]> wrote: > Igniters, > > I found that we have following problems with HTTP-REST sql query API. > > After user execute sql query he will receive queryId to be able to fetch > next page. > See docs: https://apacheignite.readme.io/docs/rest-api#sql-query-execute > > And current implementation of queryId is a long that simply incremented. > > First problem: > 1. client1 execute query and get queryId = 1. > 2. node where query was executed is restarted (queryId generator > initialized to zero). > 3. client2 execute some query and also get queryId=1. > 4. client1 fetch next page for queryId=1 and GETS results of client2!!!! > > Second problem: > As queryId is generated sequentially it is very easy to brute force and > some client could get data of other clients too easy. > > What we could do: > 1) Add nodeId to execute sql query response and fetch next page should > pass queryId + nodeId to get next page. > 2) Generate queryId as random long. > > OR > > Generate queryId as random UUID in this case it will be globally random, no > need for nodeId. > > But I'm afraid this will break backward compatibility. > > Thoughts? > > -- > Alexey Kuznetsov > GridGain Systems > www.gridgain.com >
