Hi all!
I would like the URL to be encrypted
https://baserow.io/database/13701/table/27091
https://baserow.io/5f03bcbb60dc47da7662631bd0a8df6373a67f7d3f82eefd9b438f5d01a7d5d5`
Security, privacy
https://baserow.io/hash/type/sha256/
- database/id/table/id
Hi James,
we have received similar requests in the past to hide the table ids etc. from URLs and so this is something we are thinking about, although we don’t have any specific plan to support this in the near future. Also the implementation would probably work with generated ids. Is there any reason why do you think it would be useful to use hash instead? Do you have a use-case for that?
By the way, encrypting URL would imply an encryption key which IMHO doesn’t make sense. Also hiding the ids don’t really improve security, although they do improve privacy.
In App Inventor there is something called obfucated text. It doesn’t really improve security also but for a standard hacker it could be enough to be stopped.
This is the code in java.
Blockly.Yail[‘obfuscated_text’] = function() {
// Deobfuscate the TEXT input argument
var setupObfuscation = function(input, confounder) {
// The algorithm below is also implemented in scheme in runtime.scm
// If you change it here, you have to change it there!
// Note: This algorithm is like xor, if applied to its output
// it regenerates it input.
var acc = ;
// First make sure the confounder is long enough…
while (confounder.length < input.length) {
confounder += confounder;
}
for (var i = 0; i < input.length; i++) {
var c = (input.charCodeAt(i) ^ confounder.charCodeAt(i)) & 0xFF;
var b = (c ^ input.length - i) & 0xFF;
var b2 = ((c >> 8) ^ i) & 0xFF;
acc.push(String.fromCharCode((b2 << 8 | b) & 0xFF));
}
return acc.join(‘’);
}
Like it says it acts like xor.
When i make an app where i use for instance a baserow url, I put the url in the obfuscated textbox instead of putting it in a normal textbox.
So if you use a xor function to make the url less readable you wouldn’t need an encryption key.
It was just an idea, a vision… an example.
Cool no problem, as I said we received similar requests in the past, so this might come up in the future!