Building a front end for Wasabi Storage - Anyone do it?

I totally forgot about revivi’s. I actually use his on my old app and had 0 problems with it.

That’s just impossible.

Hehehe. I haven’t used any of Bubble’s storage options for a LONG time. I always build my own now (ever since WU became a thing, which is also a total scam).

Yeah, bubble storage was never even an option for me. The screw you on the WU’s anyway because it’s a bunch of WU’s to manipulate the files from the bubble front end.

Pretty quickly I had to move away from Bubble storage too once I saw the old storage pricing, and when I found out everyone was piled into one bucket, no control on file structure, no actions available for copy, rename, or generating your own temporary expiring download URL, no way to make your own API keys, and more recently weirdness going on where they started serving files through a CDN and changing URL structure, random CDN extra parameters compressing images when we don’t ask to, and a lot of properties about a file are hidden like you can’t’ get the MIME type, file size, among other things.

So @ZeroqodeSupport, now you’ve been clearly made aware that there’s a critical issue with two of your plugins used across 3,000 apps that could lead to anyone having full read/write access to a company’s S3 bucket, you gonna fix it? Or inform your plug-in’s users if you’re not going to fix it?

Paid plugins (or even any plugin) that leaks critical data shouldn’t even be possible to be on the plugin marketplace. There has got to be some moderation on the marketplace.

You’d think so.

I’m just interested in holding the ‘Gold Tier Agency’ to at least the standards that mean one doesn’t need to pay $50 for the privilege of allowing anyone to do whatever they want to your S3 bucket :innocent:

Don’t make changes + inform users, or fix it ASAP. Any other option is gross negligence…

Don’t get me started on the fact that this company charges $50 for an iFrame :joy:

Hi @georgecollier,

If you’re running the wasabi plugin server side, are you still able to see able to see the wasabi access and secret key? I was always told to run secrets server side as anything run or saved as a workflow on the front end is exposed.

Thank you,
Gilles

You could find the secret key:

  • if you have an element containing the key on the page
  • if the key is used in any workflow action in the front-end

If used in the backend, either (and I can’t remember which):

  • then the secret key wouldn’t be visible to the user, as it’s in the backend
  • if you don’t provide a key, then the plugin is probably referencing the API keys in the plugin settings, which are protected safely as below.

Thanks @georgecollier for clarifying. Yeah, this was always the advice given to me. @ZeroqodeSupport, maybe put a warning on your elements / documentation that saving the secrets on the front end element / workflow can expose the secrets / key. What’s great about Bubble is that it’s open ended and flexible, maybe someone has a use-case to run their Wasabi on the front end with access and secret keys saved, without security being a priority.

Can? It unequivocally does!

The problem with Bubble users that aren’t as experienced as yourself is they’ll look at that kind of message and say ‘eh, it’s probably not as bad as they say and it’s unlikely someone will know how to get it’ and then proceed to do exactly the same thing as before. It’s like how people encounter the default User privacy rule and proceed to check all the boxes so everyone can see everything :man_facepalming:

There isn’t a single use case for the client to have the secret key :sweat_smile:

Yeah, very true. Takes time to learn the ins and outs of bubble, especially app security.

We need someone to put together a bubble security 101 summary, things to be aware of, like setting up the right privacy rules (i.e. User is this user), don’t check all the boxes in default privacy rules (lol), running secrets on server side etc, would be helpful for everyone as well as the new users joining bubble.

Maybe this has been done already.

Hello everyone :wave:

Apologies for the delayed reply as we were double-checking the information we have :pray:

To reduce the possibility of viewing keys in the developer console, even if the plugin is not installed on the page, it was decided to move the keys to the plugin element. In this case, the keys are also visible, but not on any page of the site, but only on the one on which the plugin is installed. We have also implemented temporary key functionality, which allows you to make keys available for a short period of time. We understand that this solution is not ideal, but we rely on our capabilities as plugin developers.

Unfortunately, we are limited here because the visibility of any keys depends on how the Bubble handles client-side actions. Unfortunately, we cannot influence this process. This is not the responsibility of the plugin, but of how Bubble works. Keys can only be private in server-side actions, and we’ve definitely made them that way in these types of actions. Client-side actions work differently in a bubble, so we’re limited here.

Best regards :hibiscus:

Yikes…

So you’re going with option 3…

@redvivi @tylerboodman @georgecollier I’m using @redvivi wasabi plugin, is the secret key not exposed on this plugin?

Also are you using the mentioned CloudConvert Plugin to compress file size with this plugin? I’m keen to find a way to reduce the file size on page load

His plugin is fine :slight_smile:

Awesome :raised_hands:

Wasabi plugin comes with image compression.