In particular, I'd like to be able to write a JavaScript application that can run without an API key and yet still access the Wikidot API.
Perhaps this can be permitted as long as the JavaScript code is stored on the same site that is being accessed?
I'd like to write a few things using JavaScript and use them to enhance the functionality of my Wikidot site. However, the major hurdle is the requirement for an API key, in addition to JavaScript's visibility making the key accessible to anyone that knows where to look for it.
The solution would be to allow limited (i.e. read-only) access to the API via JavaScript somehow, as long as that JavaScript code is hosted on the site being accessed.
Is this possible in some way?
Can we use the new Code encrypting snippet which James has written for such an key making something "privte"?
Or am I far away from all targets here?
Service is my success. My webtips:www.blender.org (Open source), Wikidot-Handbook.
Sie können fragen und mitwirken in der deutschsprachigen » User-Gemeinschaft für WikidotNutzer oder
im deutschen » Wikidot Handbuch ?
Reversable encryptions can always be reversed. The decrypting key/function will always be seen in the source code… In the front end, no matter how you encrypt the key - you will still need to decrypt it for the API call. Unless we can create an external proxy to automatically authenticate, it will be impossible.
Kenneth Tsang (@jxeeno)
Just in case anybody was confused by what tsangk just said, he is referring to reversible encryptions.
The encryption I use in the password.wikidot.com site is not reversible, it's a one-way encryption.
That was I ment - can we not use this ?
Service is my success. My webtips:www.blender.org (Open source), Wikidot-Handbook.
Sie können fragen und mitwirken in der deutschsprachigen » User-Gemeinschaft für WikidotNutzer oder
im deutschen » Wikidot Handbuch ?
I = fail at explaining things :P
Kenneth Tsang (@jxeeno)
@Helmuti: no, we can't use one-way. Wikidot wants your actual API key in the end… Giving them a hash or one-way encrypted version is no good.
Kenneth Tsang (@jxeeno)
ok, thanks!
Service is my success. My webtips:www.blender.org (Open source), Wikidot-Handbook.
Sie können fragen und mitwirken in der deutschsprachigen » User-Gemeinschaft für WikidotNutzer oder
im deutschen » Wikidot Handbuch ?
You know, I had been thinking about what to do for this, and then I had an idea. What about a user that has certain permissions only for a certain site. The site's administration page handles one part of the key, and what permissions this particular user has (And I'm just saying user here because that's what the same thing would be on a server, but this doesn't necessarily have to be another user account, just an object that you can change settings and access rules with regardless of what actual user was logged in) and then in the javascript, you have the second part.
Even if someone reverse engineers or looks at your code, they can't do anything unless they have the other key which is stored in the site manager. And even if they have both keys somehow (like an admin accidentally leaking it) they can still only do what that 'user' has been allowed to do.
It's an interesting model to work with, however I would choose something besides user accounts, even though that's how it's done on a server.