Hi
Bubble strings are shown everywhere in code. It is not too hard to find out what platform your app is build on even you are allowed to use your own domain.
Does this bother you? Is there a way to get around this? Thanks.
Hi
Bubble strings are shown everywhere in code. It is not too hard to find out what platform your app is build on even you are allowed to use your own domain.
Does this bother you? Is there a way to get around this? Thanks.
Doesnāt bother me, and exactly zero of users know about it. Even if they did, not sure why anybody would care. Itās also easy to tell when an app is built with React or Angular, or Wordpress, or Bootstrap. Just doesnāt matter as long as your product is valuable, stable, and well executed.
Doesnāt bother me at all.
Iāve been using the wappalyzer plugin on chrome for a couple years now. I always know which stack the website Iām on is built with. Itās second nature for me to look at the stack before I even start interacting with a website, especially if itās enterprise sized or an interesting start up.
Sometimes wappalyzer doesnāt load the stack on page load. Iāll even refresh the page until it catches it!
But yea, like @potentialthings says - users donāt know or care what stack you use, as long as it works.
Nope, doesnāt bother me at all.
Hi all,
Thanks for your options. I think i was being too overreactive
Yeah, itās not like you can keep client-side code a secret, and even if you expand to all internet code, the whole internet was grown by leveraging open code.
I think itās actually in our best interest to not hide the fact that apps are built on Bubble. If weāve invested in Bubble as a platform then we want other people to see itās an option and join us on it. Otherwise Bubble might disappear, taking our investment with it.
I agree with everyone. Iām putting the made with bubble logo on my app. To promote it not hide it. I wNt to do my part to support it.
Iām actually proud of what I can accomplish with Bubble. I understand your worries, but weāre living in a time where even big companies arenāt afraid of making some of their codes open source.
No matter what you use to build your app, someone somewhere will object.
āOh you are ACTUALLY using Angular* are you ?ā
*insert favourite framework
I have several remarks:
Bubble is a enabling platform that I believe in and will continue to support.
Enterprise customers of Bubble should absolutely be allowed to disable the āthis was entirely built on Bubbleā text that is visible in the console. Considering the current security vulnerabilities, such as any visitor being able to view the version-test of any Bubble app (private or not) to name one, I think it is more than an appropriate request for enterprise users on dedicated hardware to have some white-label features.
For business users, a construct of convenience is to minimize friction and anxiety with customers/potential customers. If Iām using a proprietary platform to build enterprise applications, I want to utilize all possible opportunities to reduce dialog around āyou built my app on a website builder?! This canāt scaleā¦what if my data is lostā¦how secure is this platformā¦what if they disappearā¦what if things go the route of Parseā with non-technical customers. In my business life (not associated with Bubble). I have frequently experienced enterprise customers āfreaking outā when they do not understand something, costing my company either significant consulting fees (legal, etc.) or a significant allocation of employee time that could have better utilized building a better service and product. For technical customers, they (usually) have a better understanding of engaging in a debate around preferred technologies and it is not so much of a concern, as theyāll be able to āseeā Bubble anyway.
If Bubble is open-sourced, then the table shifts in a different direction. As of now, Bubble branding does present a level of resistance that could be easily avoided. Personally, Iām willing to pay for white-label features and am also comfortable with that option going away if/when the platform is open sourced.
I have observed this behavior as well. I have seen an instance where a third party - entirely isolated from any Bubble account credentials - on a device with no relevant stored password/login info in browser ā was able to view and interact with the version-test.
So I can confirm that.
I donāt know how recently you experienced this? But its good that you have made note of it.
That being said though - I do almost all of my testing via the version-test URL inside a mobile browser (as opposed to the bubble iOS app). And the ability to just access the link without authenticating myself as a bubble user can in fact be convenient (for me).
However - the notion of the version-test being accessible for viewing to anyone, regardless of authentication (assuming the viewer is clever enough to somehow find the viewing link); is a little unsettling - Particularly if the Bubble app in question, is one that is continuously releasing new functionality etc.
The likelihood is incredibly low; but competitors, having access to view a web app that is still in āstealth modeā or working on unreleased functions etc - seems like an unnecessary risk; and could be circumvented with a secondary Bubble account login on the version-test page (assuming the bubble user isnāt already logged in).
All you have to do is look at the page sourceā¦all that would have to change, which isnāt going to happen.
It is no different to an app being covered in angular tell tales or wordpress etc. The very nature of web apps is that there are usually markers to libraries and frameworks all over the place.
I completely agree.
For technical customers, they (usually) have a better understanding of engaging in a debate around preferred technologies and it is not so much of a concern, as theyāll be able to āseeā Bubble anyway.
For technical folks, we can dissect most web apps using an inspector or viewing the source code. For non-technical people (think industries and people that cannot make sense of code), itās not as obvious in the source code that a codeless framework is being used (div tags aside). What is obvious: ābuilt entirely without code on Bubbleāā¦that could change with a very small adjustment. Every business and user has different needs, this happens to be one.
@jordanfaucet Yeah, Iāve noticed this a few times over the last couple of monthsā¦definitely unsettling. Youāre right, popping up safari and Chrome on mobile is super easy to test things out. I like your idea of creating a second dummy Bubble account to share access to an app - sharing access to other Bubble accounts could be a great way of controlling access during development.
@emmanuel, any room in the pipeline to enable a āonly share version-test with Bubble users: X, Y, Zā ?
See this, itās been there for a while now
Appologies, I didnt make myself clear: I wonder if it is possible not to allow people to go to āmydomain.comā/ version-test url? And if they do manage to write this url, redirect them to the main (home) page of the Live Version?
you canāt prevent anyone to go to a URL, but you can add a password protection. Thatās what we offer.
Thank you!
Limiting Access in the āGeneral/Designā tab did the trick!
Does the Enterprise plan allow one to get rid of the Bubble print() in Console?
No one on a dedicated plan has asked for this, but weāll consider if someone does, yes.
When we go to dedicated plan - expected hopefully next 3 months, I will take you up on that.
I am very much up for promoting Bubble - I think it is a superb application. Just want to be able to do it in a controled manner.