Whitelist custom extensions in 6.5+
Background: Control 6.5 imposes a signature validation scheme to ensure the integrity of the Connect install (per this post). This is a net good for most of the community base. For the rest of us it's more trouble than it's worth.
Request: We need the ability to either whitelist custom extensions from validation or disable the signature validation scheme entirely.
Reasoning: I've developed quite a few extensions in an on-premise Control installation to automate significant portions of my business. I'm not willing to share some of this code since it exposes the inner workings of my business, sometimes usernames and passwords, trigger URLs, and plenty of other information that would be useless for the rest of the world, but could increase the risk of my own business data should it be shared with a third party -- even ConnectWise. Microsoft, Google and Adobe have each been hacked in the past, so it's safe to assume that anything I share with CW will eventually be exposed as well.
The hosted developer instance option requires me to share business logic and requires significant rewrites to the code for each of my extensions to be able to prevent business information exposure. Furthermore, as far as I can tell, some of the functionality can not be rewritten in a way that prevents this exposure.
I've submitted an extension to CW in the past and it took weeks to have it approved. It took weeks to be approved for a developer instance. I can only imagine initial approval of each of my extensions to be able to use them in my own on-premise install will take weeks as well, and even minor updates to my extension (such as cosmetic changes or field formatting) will likely take weeks to be approved as well.
On-premise users require the ability to continue to use and develop our extensions without exposure to ConnectWise. Please enable us to whitelist our custom extensions within the web.config so we can maintain the integrity of our own installations and source code.
Customer support service by UserEcho
ConnectWise's silence on this issue is deafening. I have yet to see one single logical reason put forth on why it is beneficial for customers that ConnectWise must review and approve private extensions that can only run in a private on-premise install. Of course it makes sense for public extensions and for cloud-hosted deployments, but not for private extensions. Please listen to your on-premise customers, especially those that you obtained through buying ScreenConnect.
I used to use the Guest Session Starter Exe extension, by Elsinore Support (Remember them?). This enables a guest to download a very small exe (suitable for placing on the desktop), which would initiate a Guest Session on demand. Now depreciated, Quick Support SOS is supposed to do similar. However I was able to customise the exe file to carry my brand & logo, and now due to "signature violation", this crucial feature has been "outlawed".
My brand and logo tells MY customers that it's ME at the other end of the remote support connection & not some scammer.
I have had to clean up after one client was actually scammed by some from "Microsoft" who used a ScreenConnect client. That's why I put MY logo on ScreenConnect.
Preventing me from doing so is interfering with my business. Branding customisation was the key reason why I chose ScreenConnect over other Remote Support packages. I host my own on-premise install & pay my renewal licences. You should not break things that worked perfectly before. And when you do, you MUST put them right quickly.
FAB-ITRescue, we have registered your request to customize the SOS deployer. In the meantime, you can submit your version of GSSE and we will get it signed for you. You can also sign up for a developer instance here: https://docs.google.com/forms/d/1xIku2r1fZgX5VlxXUNih_u6l25-vATYBwU9CxX1GOSE/edit. Thank you.
I agree with Davidson. There is NO good reason to prevent someone from using unsigned extensions ON THEIR OWN SERVER. This is functionality which has been a part of the tool for a very long time, and allowed many of us to incorporate the tool tightly into our businesses. Now that this functionality has been locked out, we are prevented from upgrading and receiving security fixes or new features, or getting resolutions to bugs in the software. You are incentivizing your customers to look at your competitors.
We have already chosen NOT to purchase another ConnectWise product due in part to this decision (you were eliminated from consideration for a new ticketing tool for our customer support department).
Do you have a potential ETA for future release? My ConnectWise Control renewal is due soon and getting this feature back is the deciding factor.
Any news on this feature request?
I would like to also add that we will be stopping support and switching to a different solution if this doesn't get resolved soon.
Any update on this? Roadmapped?
As an example of just how ridiculous reliance on a third-party resource is (such as ConnectWise signing our extensions), ConnectWise even removed the page from their site that said they were removing this ability.
Connectwise - this is awful. I have been paying to renew every year but hadn't upgraded for a while (my fault, but, no good reason to). Due to the disclosed vulnerability I had to upgrade and now basic functionality - WHICH THE SOLUTION WAS SOLD ON no longer works. I'm sorry, but, going via you for a cosmetic change and waiting weeks is simply not suitable., nor is sharing internal code.
I agree with everything shawnkhall said above.
To remind people, this was the selling point:
from 2017
When I bought it:
I submitted one of my extensions almost FOUR MONTHS ago to the "approval process" and it has yet to be approved by ConnectWise. As far as I'm concerned this is breach of contract.
Hi Shawn,
Sorry for the delay in extension review. I'll follow up with the team today and see if I can get that pushed through.
The ConnectWise Control team was recently restructured, leaving some extension reviews in an unknown status.
Best,
Caitlin
It's been well over 2 years now, and still no change. The message is clear - "Find another solution, ConnectWise does not care, and does not want your business."
I completely agree. I went with connectwise several years ago for the customization labtech and screenconnect offered. Now they keep taking features away and making the product worse. I can't ever get any real support out of them anymore when something breaks either. Endless ticket blackholes and basically told that is just how it is and maybe they will fix it someday. Really sad to see a tech company go this way.
As if punctuating my argument for the ability to edit our own extensions without having to deal with ConnectWise's "approval process," this is the current state of Extension Development as of March 2021 (and acknowledged for the last two months, but the sad reality much much longer):
Note specifically: "turn-around times for existing submissions may take 14 business days or longer." That's three "business" weeks OR LONGER. This is just so you can use your own code on your own on-premise installation. Insanity.
Can we please get an update from ConnectWise on this feature request?
CW has changed their sites several times since this was requested. The link for the forum post is now only available through the wayback archive here. Since the CW docs domain blocked the wayback machine it was never able to capture the other pages. :(
...so since the code is local for on-prem, and it's all asp.net and C# code...anyone delved into how to customize connectwise and disable blocking of the developer extension and adding your own extensions? #AskingForAFriend
Yes. Last year I installed an on-prem instance running 6.5 for testing and to look for how to disable the new "feature" myself so I don't have to get permission to use my own extensions. My instance was remotely disabled by CW after about 36 hours.
Before installing the 6.5 instance I read the license to make sure what I was doing was within the bounds of the terms of use, and it was, per my concurrent session license. Not once does the license stipulate how many on-prem instances I can install, only the number of concurrent sessions I can use. I never came close to the number of concurrent sessions across both instances (mostly because the second instance was NEVER used to login to any device and was used exclusively to review the code and test my extensions). There were zero external devices connected to it -- the only device it even had an Access client installed for was itself. I contacted CW when it was disabled to have it reinstated and they said that my use (installing a second instance for development purposes) was in violation of the license because I had the ability to use a "Hosted instance" for extension development and testing, which you can see from my concerns and screenshots in this thread, simply isn't true.
If anyone has a 6.5+ license installed and active I would love to be able to get a look at it in order to address this issue.
I'm not surprised at all. It seems like they want all extensions to go through their process.
I believe they want free development for future features by using developers code submitted along with their extensions.
I've submitted extensions in the past where they have been rejected since they might not work on a cloud instance due to possible issues in the code. These issues are completely irrelevant with our on-premise setup but the extension still would not get signed. A small example is included external DLL files (such as NewtonsoftJson) for easier JSON handling - not possible since the extension would never work on a cloud instance where you don't have access to include these files.
If they really wanted us to have our own extensions, they would allow all custom extensions for on-premise installs and only cloud instances require a signed extension
I have a meeting scheduled with CW tomorrow morning on this topic. If anyone has anything else they'd like me to bring up before them please reply here or email me directly thru my name.
Missed your meeting deadline...but from what I've seen Connectwise doesn't want to work with 3rd parties unless the 3rd parties are willing to let them rent seek double-digit profits from their partners.
I've moved my development efforts to MeshCentral and Tactical RMM which are much more open (on github) and willing to work with integrations. Screenconnect will probably one day leave my infrastructure entirely after 10+ years of use.