Summer does bring out those pesky bugs, and the CodeTogether dev team has been hard at work swatting them across the product. We didn’t want you to have to wait until the 4.2 release to see these improvements, so we’ve added this maintenance release which will be of great benefit if you use CodeTogether in VS Code, or you use the on-premises version with single sign-on.
For VS Code you will see improvements in content assist and remote development. On-premises customers will now have support for Oracle IDCS and Keycloak as SSO providers, along with other fixes in SSO support.
With VS Code 1.58 as a host, there were cases where content assist proposals would simply not show up, leaving you stuck with an indefinite loading popup. This was caused by an API change that has now been addressed.
Another long-standing issue—based on the circumstances in which it was invoked, content assist proposals could take over 10 seconds to show up, a problem exacerbated by slow Internet connections. The root cause was the host sending hundreds of unfiltered proposals down the wire instead of just a handful. We now correctly filter the proposals on the host side.
With these two changes in place, you should find content assist in sessions hosted by VS Code to be much improved—far more usable and reliable.
If you used the remote development capabilities in VS Code, either working with WSL or on a remote server, a couple of bugs could render some sessions unusable.
If VS Code was started in an untrusted folder, you could get into a state (especially on Windows > Linux Remote Server) where URL mappings would fail. Files opened by the host would not be visible to guests.
We were also not enabling proposed APIs correctly on the remote system, due to which features like shared Terminals were unavailable.
These fixes should now make CodeTogether fully compatible with remove development environments in VS Code—host away!
For our on-premises customers using self-signed certificates, VS Code clients would not be able to connect to the server. This was due to a change in VS Code 1.56 onwards which has now been addressed. Make sure you use an updated client to get the fix.
Oracle’s IDCS needs a bit more love to work well with CodeTogether’s SSO integration—we’ve now added a new CT_SSO_SECURE_JWKS_ENDPT_ENABLE variable to support it.
Speaking of variables, we’ve also renamed the CT_SSO_AUTHORIZATION_ENDPT variable to CT_SSO_SYSTEM_BASE_URL to better reflect the value we expect here. The older variable will continue to work as an alias. Please read our documentation for more details.
Additional fixes in CodeTogether’s SSO internals address issues that were reported with Keycloak integration.
Finally, if you use a self-signed certificate for your SSO, CodeTogether may not be able to communicate with it and you will see an “INFO SSO initialization error: self-signed certificate in certificate chain” message in the log. We are currently addressing this by starting the Node process with the NODE_TLS_REJECT_UNAUTHORIZED=0 flag. Future releases will allow you to provide the corresponding certificate for a more secure solution.
These fixes make CodeTogether’s SSO integration now compatible with a much wider range of SSO providers.
Now that we’ve done a little cleanup, we’re back on track to bring you the new features you’ve been asking for! Here’s just a bit of what you can look forward to in our next release:
Have a feature you’d like to see implemented in the near future? Consider creating an issue, or voting for an existing one to increase its priority.
As always, thank you for the support and feedback, send us a shout on Twitter, or if you’d like to catch our team live, drop in on our CodeTogether Gitter community. If you like working with CodeTogether, please do us a favor and tell your friends and colleagues about us!
Work with a team? Start your 30 day trial of CodeTogether Teams*
*Includes up to 32 participants and unlimited session durations.
