Annoying Dashboard bug

When working with the Volt Dashboard (e.g., managing Storage items for a given user) I often run into the situation, that the Dashboard no longer responds - I have to explicitly sign out, sign in and navigate to the previous form - which is really annoying.

The browser console gives me the following error messages:

Error encountered:
  Uncaught TypeError: Cannot read property 'dataAdapter' of undefined 
  Line: 631 
  Column: 30
code.js:631 Uncaught TypeError: Cannot read property 'dataAdapter' of undefined
    at displayStorageItems (code.js:631)
    at getAllItemsCallback (code.js:622)
    at XMLHttpRequest.<anonymous> (volt.js:294)
hfunc.js:3493 Uncaught TypeError: $.i18n is not a function
    at Object.NSB._parseButtons (hfunc.js:3493)
    at Object.NSB.MsgBox (hfunc.js:3343)
    at window.onerror (hfunc.js:4031)

Are there any earlier messages? These indicate that a couple libraries have not been loaded.

Can you reproduce this at will?

I haven’t seen any earlier messages yet - but, yes, I can reproduce the situation.

For the beginning, here is a recipe to reproduce the problem: (in Chrome 77.0.3865.120 on a MacbookPro running macOS 10.12.6)

  • navigate to
  • sign in to
  • choose an application
  • click on “Users”
  • click on “Storage” for an existing user
  • in the list of key-value items, “delete” an item (screen will be refreshed)
  • now, delete another item (screen will no longer be refreshed!)

et voila, the dashboard is broken…

Well, after clearing the browser console and following the above recipe, I indeed saw more messages, but…

what really surprises me is that many of these messages sound as if the dashboard would INTERPRET THE CONTENTS of the key value pairs (which, in my current case, contain some HTML)

I double-checked that: many console messages turn up when opening the list of key value items - and they are definitely related to the contents of these values

Did you forget to encode them in order to become HTML safe?

Wow - do you want to have some fun?

Then, in your list of key value pairs

  • add one key with arbitrary value (let’s say “Test”)
  • add another key with the following content: “<script>window.alert("How dangerous!")</script>

Now follow the above recipe and delete the first key…

(Addendum: it’s even sufficient to have the second key only and to delete that immediately)

Have fun - and, please, fix this bug instantly!!!

Thanks for finding these - and yes, we will fix them quickly!

Does your first problem happen only if you do “Users” then “Storage”?
Or does it happen when you go directly to “Storage” and access the application storage?

HTML in the data field problem: The Dashboard probably shouldn’t prevent HTML strings from being entered into fields. Yes, in this case, it does have a bad result.

However, I can see use cases where people might want to store HTML strings as values. Since the Dashboard will only be operated by an Admin, I think we can rule out this being done maliciously.

Indeed, Volt must not touch strings stored as the values of keys - or the key-value storage becomes useless.

But HTML in <input type="text"> or <textarea> never causes problems - and for the purpose of displaying, the text to be shown can simply be encoded in an HTML-safe way…

Perhaps, I did not point it out properly: the (HTML) values were written by a program, not entered manually via Dashboard - the latter was only opened to inspect the existing keys and manually delete obsolete ones.

Thus…it’s not only a matter of an admin entering malicious values (as mentioned above, there should not be any malicious values) but a general one. Or, if you want it so: of a user(!) entering malicious values into an app which then stores that in ServerStorage - and, whenever the admin opens his/her Dashboard, that does not work properly because of those values…

I just recognized, that the bug has not yet been fixed!

Please, be aware, that you have a severe security problem here: it’s quite simple for a user to make the dashboard for the administrator completely unusable - even if he/she does not want it so…(not talking about real hackers)

On the other side, it’s almost trivial to fix that bug!

Kind regards,

Andreas Rozek

It’s not as trivial as you think - but it’s still on our list.