Heather Laine wrote:
> Tom Glod wrote:
>> This is a great best-practice explanation. Perhaps someone can turn
>> it into a blog post and put it on the site.
>
> Yes indeed. See Blog.
https://livecode.com/best-practice-for-api-keys-and-security/
Tip: Dropping in-bound link
Yes indeed. See Blog.
Best Regards,
Heather
Heather Laine
Customer Services Manager
LiveCode Ltd
www.livecode.com
> On 25 Jun 2022, at 04:34, Tom Glod via use-livecode
> wrote:
>
> This is a great best-practice explanation. Perhaps someone can turn it into
> a blog post and put it on the
This is a great best-practice explanation. Perhaps someone can turn it into
a blog post and put it on the site.
Thanks again
On Fri, Jun 24, 2022 at 6:24 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Mr. (Or should I say Doctor) Waddingham! This is a really
Mr. (Or should I say Doctor) Waddingham! This is a really brilliant essay on
the risk, benefits and rewards in multiple scenarios concerning the storage of
keys. I’ve mentioned before that I came up with the idea of “poisoning” the
encrypted data before the data was transmitted. If intercepted
On 6/24/22 10:04, Mark Waddingham via use-livecode wrote:
The only way to use these keys is from server scripts running on a
server which you do your best to maintain the security of. Ideally these
keys should be stored in files which are only readable by specific users
- usually the
,
> rather than anything else, made it 'more secure' - the answer is 'no
> more than putting it anywhere else in a password protected script'.
>
> However, what I should have probably expanded on is what my
> understanding on the best practice for API keys in general is...
>
&
as a LiveCode 'constant',
rather than anything else, made it 'more secure' - the answer is 'no
more than putting it anywhere else in a password protected script'.
However, what I should have probably expanded on is what my
understanding on the best practice for API keys in general is...
I have come
