I agree. In my case the main requirement was to be able to automate the entire release into a script that runs by it’s self. The whole signing process with headless browser takes about 30 seconds, which isn’t hateful although it is wasting a bit of resources…
Nov '18
3.5 years later and it looks like you guys are bent on keeping developers from automating deployment instead of adding an API. This really makes life hard…
The login changes are coming from an overall Trimble change. It’s not been a deliberate change from the EW team. I fully agree that lack of automation is a pain. Hoping to see some changes coming in the future. Can’t say much more at this point though.
I understand the captcha wasn’t your idea. Nevertheless it renders my script useless. ![]()
That is why ‘unsported api’s’ are a bad idea.
You can be sure I will bring it up at the next developer meetup ![]()
Same thing here, I was confused about why our build pipelines started to fail recently at the “signing” step.
After trying it on my local machine, I was greeted by this:
That change doesn’t make our lives easier ![]()
@fleawig Did you end up finding a satisfying solution?
Nope. We have to interrupt our automated build process now to manually sign the extension. It’s a drag.
Wouldn’t it take a good dev about four hours to expose an API to sign extensions? ![]()
It seems relatively simple.
- Username
- Password
- File Upload
- Return result with file download.
We really badly need an API that just works. (regardless of the zip utility used)
Simple username and password is enough these days in terms of security. As you see more and more places require to factor authentication to combat attempts to steal account logins.
For APIs you have to have some sort of system with API access tokens, with more limited access. (You see GitHub for instance have system like that.)
The API endpoint isn’t the hard part here, that itself is trivial. But security is never trivial.
We’re staffing up EW, so should start to see some more movement on EW improvements going forward.
Is authentication really necessary for this endpoint? There is no interaction with the developer account, we just need an .rbz to be signed.
Are you worried about abuse? In that case, wouldn’t an aggressive rate-limiting be enough?
Isn’t part of the signing process a guarantee that it was signed by a registered developer? I understand it’s easy to get e dev account, but opening it to anyone would allow anyone to sign an extension even if they were not registered.
I wonder if rate limiting paired with simple authentication would be enough security. It’s not like there are passwords or confidential info to be leaked if credentials are compromised.
Good point!
+1 for a quick solution. We have customized build pipelines for B2B customers and cannot afford to sign every build manually. We don’t have another choice than finding a workaround without signed extensions…


