Can one app have multiple Volt scopes/IDs/accounts?

Before I kill myself on my own trying to see if this works, let me first ask…

Is it possible to have a single app use multiple Volt accounts?

My thought is to do one of two things:

  1. Switch NSB.voltAppId to whichever appId I want to begin working with (each time logging the user in and out)
  2. Call $volt.init(appId) with whichever appId I want to begin working with (each time logging the user in and out)

I’m concerned the $Volt API is not expecting to be (ab)used in this way, i.e. having the AppId switched behind its back, or calling init many times per session.

Any advice on how best to go about the ability to access multiple Volt storages from a single app (if it’s possible to do)?

I’m curious why you’re needing to switch from one to another? Can you share more about what the goal is?

Not fully committed yet but exploring design options. But…

My application needs to share data between two users, like a mailbox. I would rather not share passwords (hashed or otherwise) between users for security reasons. I can’t have multiple accounts for the same user email because Volt checks that. I can’t use a non-email address because Volt checks that. I can’t use a “decorated” email address as the second account because the confirm-email function will try to send a confirmation email to that address. I can’t use AppStorage because it’s read only for user accounts.

So, my thought was to create a second AppId scope that doesn’t have the confirm-email feature enabled. That way I can use the user’s real email address for the second/shared mailbox account and use whatever password scheme I want, knowing the user’s real password to their real account has not been shared.

At this point, I think I’ve convinced myself that hashing the passwords and sharing them between users is not really a security sin. Or I could leverage AppStorage if I embed the admin’s password into my app for all user’s to use and switch in and out of.

Creativity welcome.

I think my best option now is to use a hash of the user’s email address for their password.

This sounds like an interesting project. It’s definitely a bit outside of the bounds of the API, and I don’t claim to understand all the ins and out of what you’re describing, but I do have a couple of thoughts:

  1. I believe the volt.js should handle an application ID switch without issue. If it doesn’t let us know and I’ll see if it’s an easy problem to fix. This hasn’t been tested and so it’s officially unsupported, but I’m willing to see if we can get it working.
  2. Be careful about which hashing algorithm you choose. A lot of the common algorithms are for document hashing and not password hashing. At the very least I would choose bcrypt (keeping in mind its limitations) if not something newer like argon2.

Good luck and keep us updated on your progress!

  1. Roger that. I’ll share anything I learn. Thank you!
  2. So you’re suggesting full on encryption vs a simple hash? Is bcrypt the same as Stanford Crypto? Anything wrong with using Stanford Crypto from the toolbox library in AppStudio, in your opinion?

There are several kinds of hashes. Some are meant for speed, like the SHA series. These hashes aren’t appropriate for hashing passwords because they are easy to brute force (because they don’t take much time to compute). Algorithms like bcrypt are meant to make it computationally infeasible to brute force passwords.

It looks like standford crypto says it includes PBKDF2, but in actuality only implements SHA256. Unless security isn’t a priority, I would not use this algorithm for hashing anything that needs to withstand an attack. Instead I would take a look at bcryptjs - npm

This is a pretty subtle topic and it depends heavily on your use case. There’s a lot of good reading on the internet that can help guide your decision.

Indeed. This is great input. Thank you!