Hey all—on @tt_su 's suggestion I just checked my script to make sure the Trimble ID sign in still works. (@tt_su mentioned there may have been recent changes to the sign in.)
I’m happy to report it still works!
If anyone wants further details or help about how to sign extensions this way via script, feel free to ask.
The automatic sign no longer works. I suspect that trimble changed the login. Has anyone found a solution yet?
@Josef, thanks for letting me know. Can you confirm a couple of things for me:
Did you have something working before?
Did you get any helpful error messages?
Thanks!
Error:
Traceback (most recent call last):
File “/builds/tsk/3skeng-install/src/sign.py”, line 195, in
sketchup extension signing
starting session with Trimble Identity
main(sys.argv[1:])
File “/builds/tsk/3skeng-install/src/sign.py”, line 188, in main
session = cas_sign_in(username, password)
File “/builds/tsk/3skeng-install/src/sign.py”, line 38, in cas_sign_in
login_html = html.fromstring(login.text)
File “/usr/lib/python3.9/site-packages/lxml/html/init.py”, line 875, in fromstring
doc = document_fromstring(html, parser=parser, base_url=base_url, **kw)
File “/usr/lib/python3.9/site-packages/lxml/html/init.py”, line 763, in document_fromstring
raise etree.ParserError(
lxml.etree.ParserError: Document is empty
Yes, the Trimble ID login system rolled out an update this week. Things changed again.
Thanks! I will look into this first thing on Monday. If you happen to make any progress before then, please share.
Hm. So the error is being raised by ETree, when it tries to parse the hidden fields on the login form (from which you used to need to get a token). As far as I can tell, there no longer are any hidden fields, so we can get rid of those lines. I would guess the credentials are being passed through by some other method. I haven’t been able to confirm what this method is yet, so I am stuck getting error messages from my POST request. Incidentally, it seems like the action_url value (where the form should actually get POSTed to) has changed to 'https://id.trimble.com/ui/api'.
It’s possible this is related to the state value on the page, which you can follow from watching the chain of requests and responses in a browser. When I pass this through to the new action_url, I get a 502 Bad Gateway error, so either my state token isn’t doing what I think it is, or I’m not using it correctly. I could be off-track here—please take a look if you think you might be able to help. Otherwise, I’ll be back at it tomorrow.
All right, after more investigation, it looks like what’s happening is that our login form POST requires some Optanon cookies. I’m not seeing that the browser ever gets these cookies in any of the redirect responses—they just appear in a request, which makes me wonder whether some JS on the page isn’t injecting them. This wouldn’t be a problem if our session could pick them up during the redirect chain, but I was also finding that this chain wasn’t getting to this point (the API request) by itself—I needed to make the last GET request manually in order to supply the correct URL. Still working on it…
Thank you so much for taking care about this! I tried to investigate myself, too, but I’m no web scraping expert, so I gave up at some point.
Really appreciate it and looking forward to a solution!
Hi Fleawig,
any news on this topic? How are you doing?
Best regards!
I’m using this script and I had to modify the sign in portion to get it to work. With a few changes I have my deployment script back up and running. My computer crashed so I can’t post code at the moment.
Hi, thanks for the tip! Works good enough, not as lightweight as fleawigs python script, but does the job!
Hey folks, glad some of you have found other solutions. In our case, it is far preferable to be able to do the signing without running a headless browser, otherwise I would’ve gladly made that move—and I do recommend it if it works for you.
I did learn a little bit more about the cookie-based authentication. In order to get his Optanon cookie for the POST request, the page calls into a CDN at cookielaw.org, which fetches a dense, not-very-human-readable JS function. Running the function gets you some JSON which seems like it represents the cookie somehow, and this is then added to the headers in the following request. I had not quite connected every dot here yet, and there is the possibility that there’s some other security that ultimately will make this a dead end.
In order to get a SketchUp 2022-compatible release out quickly, we’re going to just sign manually for this round. Afterwards, we still have some ideas to look into for getting this to work, and I will of course update here if I have something.
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 
