• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
every now and again SDK becomes unusable...
#11
Hi Stan,

We found an issue with the current libraries that could cause problems.

When you do specific api calls like cdb_sdk() or cdb_auth(), your authKey (used to decrypt your config file) are updated in memory. Your config file is then saved with the updated authKey. The problem is that we were not storing the updated authKey in the initializeCanelaDB handler for you. Subsequent runs would cause canelaDB to be unable to decrypt the config file.

This usually will not bite most users as the exported SDK from LiveCloud Manager knows your authKey and provides the working key in your code.

For some apps, like LCM, the authKey will change based on different developer accounts accessing the same app. We solved this internally by saving the updated handler outside of the API. This may not be your particular problem.

The other thing we solved is that you can now have your initializeCanelaDB code be anywhere. Internally, we check your mainstack script and card 1 of your mainstack. If your initializeCanelaDB is in some other place, the APIs were not able to find and update your code for you.

We have not pushed this through LCM yet. Once we finish testing, we'll do an update.

-Mark
  Reply
#12
We just pushed a new update to the libraries. Please give this a try and use the new API that will give you more control over your authKey being saved properly in your config file. The authKey is used to encrypt and decrypt your config as your config gets updated. Anyone that wants to use this API should export their toolkit as normal.

Please see the docs for details on the new API: https://docs.livecloud.io/AutoSetupAuthKey/

Your config file is updated when you modify your tables, keys to tables, sdk().

Normally your config's authKey will not change unless your app is designed to support multiple developer sign-ins from different accounts. The only apps we are aware of that do this would be LiveCloud Manager, Appli, and NurseNotes. If anyone plans to do this in their app, please shout out to us for guidance.

-Mark
  Reply
#13
Dear Mark and team,
I haven't yet started using AutoSetupAuthKey - however i did (as per the recommendation at LCM startup) download updated SDKs and now cannot connect to cloud data.

as previously, i get the messages:

Code:
(2021-06-03 20:40:49.519): Local authentication unsure: no local data to verify
(2021-06-03 20:40:52.105): Cloud authentication - received nonse value
(2021-06-03 20:40:53.962): Cloud authentication - received apiKey
(2021-06-03 20:40:53.962): Cloud authentication passed

but then I also get two new messages:

Code:
(2021-06-03 20:40:53.962): The authentication key changed. Successfully requested a new API authentication key
(2021-06-03 20:40:53.963): Error reading cloud records.

The last error occurs on trying to read cloud data after initialisation and auth. It's probably worth noting that gCDBAuthKey is empty at the end of this...

the InitialiseCanelaDB script is in the mainstack's script and is called from the on preOpenStack on the 1st card of the mainstack - the app is not currently built as a stand-alone.
Does this relate to autoSetupAuthKey?

The code use to work just fine previously...

----------------
EDIT 1: I'm not sure i understand where exactly i'm supposed to call autoSetupAuthKey as, as opposed the comments in the example, i haven't ever used cdb_SDK(). But calling this as per the example in documentation  (moving the initialisation script to a script only stack etc) didn't fix my issues.

EDIT 2: I was able to resolve this by reverting to an older version of the SDK and script. It's probably something i'm not doing right, but using the newer SDK/script does't work for me (i can always auth() but can never read data - i just get an unhelpful message saying 'Error reading cloud records' which goes away when i use older version of the SDK/script.
  Reply
#14
Further to this, i think I've identified a source of issues i was encountering - nothing to do with the issues above. But sadly still doesn't fix the issues i'm having.

I had cloned a project (keys + data) for testing purposes with the new SDK, downloaded the new SDK etc.
However it wasn't finding the cdbUsers table (the cdb_userTableName was just returning cdbUsers-, without the UUID that used to follow after the hyphen).

I recreated a new project from scratch and imported the existing data after exporting to JSON - that seems to fix this.
So the issue seems to be that associated with cloning a project - something is buggy behind the scenes.

Having said that, i'm still informed in the message output that the authentication key has changed (why?? this is a 'fresh' copied from the export SDK screen and this occurs on immediately running the app 1st time) and that a new key has been requested, but then end up with 'error reading cloud records'.

It is very likely 'i'm not doing it right' but i'm currently not able to use LiveCloud at all with the new SDK.

My set up at present is all initialisation scripts are the mainStack script, being called from an On PreOpenStack handler on the 1st card of the mainStack and this is being run in the IDE, not standalone). The scripts are copied directly from the 'export SDK' screen with one minor amendment as put the canelaDB folder in a subfolder of my 'Documents' folder as a writeable location.


On a related note, there appears to be a further bug in the new version: 
In the 'download SDK' screen, if i click Create project it just creates a folder with the project name that only contains one empty folder "canelaDB" and no files whatsoever. 
This used to generate a sample project with a login screen, but this doesn't happen at present (i thought maybe this had been updated with the new cdb_AutoSetupAuthKey and was keen to see an example).

As it stands at present i can only get my app to work by reverting to an older SDK & script that worked prior to the new version. 

Grateful for any suggestions to fix this unhappy state of affairs...
Stam
  Reply
#15
Hi Stam,

I'll respond to your comments in-line.

Dear Mark and team,
I haven't yet started using AutoSetupAuthKey - however i did (as per the recommendation at LCM startup) download updated SDKs and now cannot connect to cloud data.

as previously, i get the messages:

Code:
(2021-06-03 20:40:49.519): Local authentication unsure: no local data to verify
(2021-06-03 20:40:52.105): Cloud authentication - received nonse value
(2021-06-03 20:40:53.962): Cloud authentication - received apiKey
(2021-06-03 20:40:53.962): Cloud authentication passed

but then I also get two new messages:
[/quote]

This is a successful authentication. Things look good here.

Quote:
Code:
(2021-06-03 20:40:53.962): The authentication key changed. Successfully requested a new API authentication key
(2021-06-03 20:40:53.963): Error reading cloud records.

The last error occurs on trying to read cloud data after initialisation and auth. It's probably worth noting that gCDBAuthKey is empty at the end of this...

the InitialiseCanelaDB script is in the mainstack's script and is called from the on preOpenStack on the 1st card of the mainstack - the app is not currently built as a stand-alone.
Does this relate to autoSetupAuthKey?

The code use to work just fine previously...

Your experience here has nothing to do with the recent library update. It is just an unfortunate coincidence. Your app lost its authentication and needed to reauthenticate.

Should your app lose authentication, CanelaDB will, on your behalf, authenticate for you. What it does not do is attempt to do another read. Reading your comments inspired us to address this. We reworked the experience and will now have the API read your data after successfully authenticating again. 

I'll push a library update through LCM that will do this for you. 


----------------

Quote:EDIT 1: I'm not sure i understand where exactly i'm supposed to call autoSetupAuthKey as, as opposed the comments in the example, i haven't ever used cdb_SDK(). But calling this as per the example in documentation  (moving the initialisation script to a script only stack etc) didn't fix my issues.

Under most situations, you do no need to use cdb_autoSetupAuthKey(). LiveCode can update the script of mainstacks as long as they are not turned into a standalone. 

Thus, anything you run in the LiveCode IDE will work just fine no matter where you put it. 

Moving your init code to a script-only stack is still a good idea. But, you will need to use cdb_autoSetupAuthKey() after calling your cdb_auth() handler. Those two go well together. There is no need to call it at any other time. I'll go over the docs to clear this up.



Quote:EDIT 2: I was able to resolve this by reverting to an older version of the SDK and script. It's probably something i'm not doing right, but using the newer SDK/script does't work for me (i can always auth() but can never read data - i just get an unhelpful message saying 'Error reading cloud records' which goes away when i use older version of the SDK/script.

It is hard to say what you are experiencing here. If you want to package up your project so that it fails, we can have a look. 


[/quote]
  Reply
#16
(06-06-2021, 11:00 AM)stamatis Wrote:
Quote:Further to this, i think I've identified a source of issues i was encountering - nothing to do with the issues above. But sadly still doesn't fix the issues i'm having.

I had cloned a project (keys + data) for testing purposes with the new SDK, downloaded the new SDK etc.
However it wasn't finding the cdbUsers table (the cdb_userTableName was just returning cdbUsers-, without the UUID that used to follow after the hyphen).

I recreated a new project from scratch and imported the existing data after exporting to JSON - that seems to fix this.
So the issue seems to be that associated with cloning a project - something is buggy behind the scenes.

Having said that, i'm still informed in the message output that the authentication key has changed (why?? this is a 'fresh' copied from the export SDK screen and this occurs on immediately running the app 1st time) and that a new key has been requested, but then end up with 'error reading cloud records'.

It is very likely 'i'm not doing it right' but i'm currently not able to use LiveCloud at all with the new SDK.

My set up at present is all initialisation scripts are the mainStack script, being called from an On PreOpenStack handler on the 1st card of the mainStack and this is being run in the IDE, not standalone). The scripts are copied directly from the 'export SDK' screen with one minor amendment as put the canelaDB folder in a subfolder of my 'Documents' folder as a writeable location.


On a related note, there appears to be a further bug in the new version: 
In the 'download SDK' screen, if i click Create project it just creates a folder with the project name that only contains one empty folder "canelaDB" and no files whatsoever. 
This used to generate a sample project with a login screen, but this doesn't happen at present (i thought maybe this had been updated with the new cdb_AutoSetupAuthKey and was keen to see an example).

As it stands at present i can only get my app to work by reverting to an older SDK & script that worked prior to the new version. 

Grateful for any suggestions to fix this unhappy state of affairs...

Stam

I'll put in a bug report for the 'clone project' feature in LCM. It sounds like we are not building the internal tables correctly. Using the export and then import data feature is a good workaround for now.

I just tried the Create project feature in LCM. It exported all the expected parts fine in my test. But, the cdbUsers table is not properly setup in the config file. We will get this looked at.

Thanks for your report Stam.
  Reply
#17
One more thought. If your mainstack is just a splash or loader that in turn loads up your actual app, you can place your init code in one of the mainstacks that are loaded after the fact. LiveCode can update those stacks because only the splash stack has been turned into a standalone.

You will not need to use cdb_autoSetupAuthKey(). Internally, CanelaDB calls cdb_autoSetupAuthKey() for you, after a successful cdb_auth(), and checks the mainstack relative to the code for your init handler.

cdb_autoSetupAuthKey() is for those that want to place their init handler is a custom location that is not part of the script stack of a mainstack or card 1 of script of a mainstack. As an example, Appli has its init code in a stack that is loaded long after the standalone is started. We use cdb_autoSetupAuthKey() to manage updating our init code with the current authKey by calling cdb_autoSetupAuthKey() right after a successful cdb_auth() call in our log in screen.
  Reply
#18
(06-09-2021, 04:43 PM)mark_talluto Wrote: One more thought. If your mainstack is just a splash or loader that in turn loads up your actual app, you can place your init code in one of the mainstacks that are loaded after the fact. LiveCode can update those stacks because only the splash stack has been turned into a standalone.

Hi Mark,
I think discovered the source of error reading cloud data -- since the new SDK, cdb_sync seems to require that tables be loaded first.
i added a loader/splash stack and that did not resolve the issue. I was always able to auth() so it's never been a case of losing authentication. But the app is better for it so sticking with this setup Wink

The app is set to sync all data tables from cloud to local db on user log in - the error was happening here. This evening I noticed a series of error messages that all tables that were to be synced hadn't loaded (this never used to happen with the previous SDK). This would then lead to 'error reading cloud data' (again, never had this error before).

I added code to cdb_loadTable all tables that were to be synced prior to syncing, and lo and behold the errors all went away.
On limited testing with the new SDK, it seems cdb_loadTable is not required for cdb_read (as previously) but is now obligatory for cdb_sync.

This seems to be what caused the endless confusion as prior to the new SDK this wasn't the case. I could just call cdb_sync without loading the tables to memory first. 

Is this intentional? If it is, it should be specified in the documentation (maybe it is, I may have missed it).
If it is intentional, then it seems inconsistent as i can do a cdb_read without loading the tables first...

I've not yet had a chance to do further testing - as with all such things, the issue may prove to be elsewhere, but this has got me up and running with the new SDK (so far at least!)

Regards
Stam
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)