ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: HTTP-REST sql query ID problem
Date Wed, 04 Nov 2015 09:16:35 GMT
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 <akuznetsov@gridgain.com>
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message