Did Javascript just stop working in both live and editor? (no, it's UNPKG)

I totally agree with you @dorilama , I didn’t mean to say that not choosing a static version is a best practice, nor do I engage in it myself, I was just listing some of the reasons why CDNs are useful. I also agree that most of the time, a library developer will minify and compile the package into a single file for the plugin dev, but I’ve had to deal with instances of that not being the case when trying to build a plugin for bubble and need to use something like browserify or webpack to compile into a single file.

I think my overall point was just that if OP’s concern is with external services, there’s no difference between one CDN over another solely in terms of being an external service that can go down at any time and it 100% beyond Bubble’s control; some are better than others, and some are good now but can deteriorate later. Hosting internally via Bubble is always an option, and is extremely attractive for plugin dev’s when the library is pretty stable and well established and doesn’t need too many bug fixes, but sometimes CDNs do have their advantages.

I get your point but this cycle:

  • dependency gets update
  • upload new dependency on bubble’s cdn
  • check that the plugin works with new dependency
  • publish updated plugin

is a normal safe way of development.

The other way:

  • point to an external cdn to dynamically load the latest version of the dependency

it’s NOT safe and can expose LIVE apps to random bugs at best, supply chain attacks at worst, that will happen unnoticed and unmonitored.

So if that is the main reason to choose unpkg, or another cdn, it’s not a good deal and maybe the plugin user should be warned about the risk.

absolutely, @dorilama, which is why I mentioned that

My point was that, especially if there’s a reason for it, there’s a variety of ways and reasons why using a semver range or latest is the plugin dev’s best option. It’s probably not most of the time, but especially if it’s a library where they are both the library dev and the plugin dev, there’s a reason.

I understand your point that this is a normal way, but when we’re talking about free plugins, not everyone is going to go this route, especially when the original library developer does not compile into a single file for the plugin dev to use, and may have used a non-static version or used a cdn for their own reasons, made the plugin for themselves, but took the time to also make it free and open-source instead of a private plugin just for them. I upload to Bubble’s direct content delivery, you may do it too, but we’re talking about someone producing an open-source plugin, for free; when dealing with open source, you get what you get, if you don’t like it, fork the plugin and make the changes yourself. That’s the point of open-source plugins.

Any API Connections pose the exact same risks if they are not robust to support things like versioning and API version control, so unless an app is going to be 100% inside bubble and not use any external services, APIs or CDNs or otherwise, we’re stuck with what we can do 100% in Bubble, which is an extremely old-fashioned way of web-dev, given that APIs and external services and driving the modern internet, and even blockchain tech relies on external services and interconnections. Also, as the bubble app developer, its your job to monitor you app so that the “unnoticed and unmonitored” bugs get fixed, just like its a plugin developer’s job to monitor their codebase. To your point, we’re all responsible for managing our codebase, plugin developers and bubble app developers both the same.

I’m not sure if you refer to me as the OP, I don’t think I initially voiced any concerns since I had no idea what was going on :slight_smile: However, learning more during the discussions in the thread and talking to Bubble support. I don’t believe the concern with UNPKG lies in it being an external service, rather that it’s not a supported service with known reliability issues (despite it still being widely used) and other services such as jsdelivr have superseded it and are supported. Which would be 100% valid for Bubble to request as part of its approval process. The service you rely on must be a supported/stable service to safeguard the integrity of Bubbles’ ecosystem. And if at some point point a current service becomes obsolete etc, Bubble could again request plugin devs to move to a different service.

This is the recommended way from Bubble. And again, enforcing that, and where not possible give a reasonable explanation for not hosting on Bubble, would again be a valid requirement for tapping into Bubble’s eco system, I would think?

I mean… look at Apple for god’s sake, or even running an ad on Reddit. They will go over your page with a fine-tooth comb and a broken link anywhere on your site will see your ad campaign cancelled :slight_smile:

I hear you @casheets123 , but

UNPKG is still supported and the uptime issues are things they’re working on. It’s an active project thats powering approx. 10% of the clear web. That’s a pretty big task, and they’re doing their best for what is a free service. It’s not the top of the market like jsdelivr, but bubble plugin devs are often at the mercy of the original library developer who chose what CDN to use, and then we as plugin devs port their work into Bubble.

The day Bubble gets to tell me how to code my app is the day I quite using Bubble, barring illegal content or content that violates their terms of service. I code open-source plugins for my own use, and instead of making them private and keeping them to myself, I open them up for free for everyone to use.

There is no approval process, nor should there be one, for free/open-source plugins. I’d agree with you for paid plugins, but for open-source, like the plugin you originally mention, there absolutely should not be any Bubble oversight beyond ensuring that illegal or terms-of-service violations are not occurring. As a developer, Bubble telling me what I can and cannot do (beyond legality and terms of service) is frightening; on their end, they would have to charge a whole lot more to be able to support this type of screening (think the 30% markup Apple tacks on to its app store that developers have to put up with).

I don’t mean to make this overly nuanced or argumentative @keith @dorilama @casheets123 , and its probably strayed far from the original concern. I apologize if I came off a bit rude or snobbish, I’m not trying to turn the Bubble forum into StackOverflow and didn’t mean anything personal.

Wait what? There’s an approval process for templates (quite stringent too actually) but you’re saying bubble lets any ol’ stuff into the plugin marketplace?

I would say that’s a big problem since it’s injecting code into your bubble app, and it’s not something I was aware of. As users I think we should have full trust in that what’s part of bubbles eco system should have some oversight.

Again, as I’ve mentioned earlier over the years I’ve learned to limit the use of plugins. There are an incredible amount of atrociously bad plugins available that will wreak havoc in your application, or completely broken and not supported and so on. I guess now I know why…

See What is the 3rd-party plugin approval process? - #2 by williamtisdale, but free/open-source plugins are not reviewed (unless flagged/reported, to my knowledge), only paid ones. Free plugins are instantly available on the Bubble marketplace.

Very interesting. Is private the same as free here? It’s a bit of a confusing wording there. Sounds like if you’re only using it in your own app, bubble won’t review it (rightly so) but as soon as it’s public, it will go through review, but then it mentions charging a fee.

Where does that leave public but free plugins?

There’s three types of published plugins:

  • free/open source: it’s published under the MIT license and available instantly on the marketplace, only reviewed if reported to Bubble to contain terms-of-service violations including illegal content; bugs can and are frequently in free plugins, and there’s nothing Bubble does to remove them (as far as I’ve ever heard on the forum)
  • private: only I can access the plugin, no one else can, unless I authorize their app to use it; same review as above
  • commerical/paid plugins: not free, you cannot view the original code, you cannot fork the plugin to make changes, but Bubble does review them from what I can tell. I only publish open-source plugins and don’t believe in charging for them, so I wouldn’t know a ton about the paid plugin review process.

That’s quite alarming. Wouldn’t that mean that a plugin could essentially do whatever it wants to your app with no oversight?

For example, could you write a plug in that logs all your users signing up and sending that information to the plugin dev? Or any kind of crazy thing you really shouldn’t be doing. I fail to see how this would be a matter of free vs. paid, and not a matter of oversight for what code is injected into potentially thousands of bubble apps?

Or am I just being paranoid here?

Perhaps @sam.morgan would have an answer to whether free public plugins go through any type of review?

or @Keith who has some very popular free public plugins.

It’s a valid concern. I’m positive that there is no pre-publishing review of free plugins; as I said, if plugins get reported for ToS violations, I’m sure Bubble investigates.

There is no pre-publishing review of free plugins bc they are open-source. You can go in for yourself and see exactly what a plugin does. You can see the code; you can fork the code and modify it to your unique case, and even republish it as Private, Free, or Commercial. The whole idea of open-source code is to use it at your own risk, because you got it entirely for free; that’s the whole idea of the MIT license, to allow you as much freedom to use the code, but freedom to use comes with responsibility to review before using.

1 Like

Well this is turning into a highly informative thread. I’v been using bubble for 4-5 years and never even considered clicking “see plug in code” since I rarely ever use plugins.

But I see now that I could use jsdelivr’s unpkg migration tool and then change the header myself if needed.

I can’t find an option for forking the plug in if it’s not enabled tho, and having to rebuild it is a bit of task.

There is nothing to aplogize, this is a forum and it is nice to discuss and express opinions.

I also agree about the spirit of open source and I am perfectly aware that the MIT license comes without warranty.

This is the point that you are misunderstanding. Tha API connections will not change in production without notice in the next hour. Unpkg default to the latest version unless you intentionally pin a single version: unpkg.com/aos will always load the latest available version, you need to request unpkg.com/aos@2.0.4 if you don’t want to load the code that the author will publish next. This happens in your live app.
Think about how plugins work in Bubble:

  • install a plugin at a fixed version
  • test it in your app
  • publish the app, the plugin is now live in your app
  • plugin author updates the plugin with a patch/minor/major change.
  • Your live app is still with the version you tested, it’s still working good for your users. You need to manually update the plugin and publish it.

When your plugin loads always the latest version from an external cdn you are literally bypassing this safeguard because what happens is:

  • install a plugin at a fixed version
  • test it in your app
  • publish the app, the plugin is now live in your app
  • external dependency author updates the library with a patch/minor/major change.
  • Your live app automatically loads the new dependency. You don’t know if it’s breaking your app untill your users complain with you. You don’t know if malicious code was introduced. You don’t even know that the update happened in the first place.

How the developer of the app is supposed to monitor and check the app if does not know in the first place that the plugin is dynamically loading dependencies without notice.

Anybody is free to use this technique but maybe there should be a notice about the potential risk. Even if the version is pinned there should be a notice saying that the plugin requires external dependency.

This is just wrong. The developer does not choose to use unpkg or another cdn. If the documentation says to load the script from unpkg it is meant only for suggestion. It is well known in the javascript ecosystem how to bundle a library for different use cases. Everybody knows unpkg is a quick example for demonstration because it automatically uploads npm packages.

100% agree. Other nocode platforms have sane and modern developer experience and allow you to make very interesting stuff.

2 Likes

@casheets123 click on the “Plugin Page” option in the editor, and you get a page like this (one of my free plugins where you can see the fork): Google Service Account Plugin | Bubble

Yeah that button is greyed out on the AOS plugin, assuming the dev is able to enable or disable allowing forking of their plugins, even if it’s free?

All I meant was that the way the API works, not the connection itself changing in Bubble, but what is on the other side of the connection in the same way as a link to a CDN has code coming into Bubble from another side; the underlying functionality of an API can change in the same way the underlying functionality can change in a CDN. That’s all I meant.

Totally get this; I think I worded what I was trying to say wrong; I’ve used some libraries where they go with a private CDN, not UNPKG (where you can easily migrate) and don’t automatically compile source code for you into single files, so you need to take the existing CDNs code and go to another service (perhaps directly into Bubble). I totally get that this works. I was just speaking to why a CDN might be used, not a best practice.

Sorry I didnt see that on this plugin specifically; I’ve never seen the fork option greyed out, so perhaps its possible for it to be disabled? Maybe the original author needs to push it to github so it can be forker? I’m not entirely sure to be honest on that one.

All good. thanks man, this is the first time I’ve even clicked the view code button so.

I’m still trying to wrap my head around the fact that malicious code could be injected into thousands of bubble application through plugins with absolutely no oversight.

And relying on bubble users to sniff out T&C violations is bordering on lunacy, assuming that the majority of bubble users have no idea what the code does by looking at it, being a no-code tool and all that. And further, most people stuffing their apps full of free plugins are even less likely to be comfortable with code at even a very basic level.

At this point, my chin has fallen through the floor.

Should this at least have a big disclaimer on the plugin page? 4-5 years in, and I had no idea that free plugins have no oversight whatsoever and are directly published on the market place, I still struggle to believe it.

This topic was automatically closed after 14 days. New replies are no longer allowed.