app_key is saved as part of persistance file

[countly]

app_key is saved as part of persistance file

[yuriy128]

To resolve this, do not add [self queryEssentials] to the queue, but add it right before sending the request over. This will also reduce your file storage size as this data is constantly being duplicated.

[ar2rsawseen]

I would not say that scenario is not so bad.

Because when you update an app and change app_key to new one, you expect new data after update to be sent to new app, and that is exactly what is happening. Because queued requests with old app key would be old requests before update, and only new ones will be with new app_key.

And properly configured production Countly server will still respond with success even if the app does not exist, so these requests won't pile up (aka Safer API responses disabled)

But another point is that we need to store queryEssentials with queued requests for many other reasons. Like when switching deviceId when multiple different users use the app, etc, we need to ensure that queries are executed with the data the events occurred. And not tampered afterwards.

Our whole structure depends on that :)

[yuriy128]

Fair point about device id. Then, perhaps take out app_key from query
essentials and treat it just like host?
On Thu, Apr 28, 2016 at 3:04 AM Arturs Sosins [email protected]
wrote:

I would not say that scenario is not so bad.

Because when you update an app and change app_key to new one, you expect
new data after update to be sent to new app, and that is exactly what is
happening. Because queued requests with old app key would be old requests
before update, and only new ones will be with new app_key.

And properly configured production Countly server will still respond with
success even if the app does not exist, so these requests won't pile up
(aka Safer API responses disabled)

But another point is that we need to store queryEssentials with queued
requests for many other reasons. Like when switching deviceId when multiple
different users use the app, etc, we need to ensure that queries are
executed with the data the events occurred. And not tampered afterwards.

Our whole structure depends on that :)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#80 (comment)