How safe is BOL technique?
Hi Dan, I have been reading the BOL technique and it appears it is built on the concept of probably hacking, for the lack of a better word "vulnerability" or open patch within quickbase. Is that tr...
Forum Discussion
BOL is a hack that only an administrator can implement so you can consider it safe from a security viewpoint. But if you don't trust your administrator there are many other more direct ways the administrator could mess with your application and data without implementing BOL.
The one benefit BOL has over other injection techniques is that once implemented it applies to the whole application. IOL only applies to the table it is implemented on and SW applies to either the entire account or an individual dbid. depending on how the scope is set when registered.
My guess is that eventually QuickBase will probably support some way of supporting user supplied JavaScript and we will not need to rely on hacks that only an administrator can implement.
Any of these techniques (IOL, BOL and variats) could break overnight if some code a QuickBase developer checked changed something. I think the word is that they are not going to make a breaking change. Service Workers probably can't be blocked by QuickBase in the current architecture because the browsers don't yet support the relevant header (this is bleeding edge stuff) .
Content Security Policy
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/worker-src
There is a big opportunity for QuickBase to support Service Workers through CloudFlareWorkers..
The bottom line is that I would encourage you and everyone else to engaged in a healthy dialog with QuickBase over your needs the technical features that are available. I think they are receptive.
The one benefit BOL has over other injection techniques is that once implemented it applies to the whole application. IOL only applies to the table it is implemented on and SW applies to either the entire account or an individual dbid. depending on how the scope is set when registered.
My guess is that eventually QuickBase will probably support some way of supporting user supplied JavaScript and we will not need to rely on hacks that only an administrator can implement.
Any of these techniques (IOL, BOL and variats) could break overnight if some code a QuickBase developer checked changed something. I think the word is that they are not going to make a breaking change. Service Workers probably can't be blocked by QuickBase in the current architecture because the browsers don't yet support the relevant header (this is bleeding edge stuff) .
Content Security Policy
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/worker-src
There is a big opportunity for QuickBase to support Service Workers through CloudFlareWorkers..
The bottom line is that I would encourage you and everyone else to engaged in a healthy dialog with QuickBase over your needs the technical features that are available. I think they are receptive.