SDL Trados Studio
SDL Trados GroupShare
SDL Trados Business Manager
SDL Trados Live
SDL Speech to Text
SDL Managed Translation - Enterprise
Translation Management Connectors
SDL LiveContent S1000D
SDL Contenta S1000D
SDL Tridion Docs
SDL Tridion Sites
SDL Content Assistant
SDL Machine Translation Cloud
SDL Machine Translation Connectors
SDL Machine Translation Edge
Tridion Docs Developers
SDL User Experience
Language Products - GCS Internal Community
SDL Community Internal Group
SDL Access Customer Portal
SDL Professional Services
SDL Training & Certification
Language Technology Partner Group
SDL Academic Partners
SDL Enterprise Technology Partners
ETUG (European Trados User Group) Public Information
Machine Translation User Group
Nordic SDL Tridion Docs User Group
SDL Tridion UK Meetup
SDL Tridion User Group New England
SDL Tridion West Coast User Group
SDL WorldServer User Group
Tridion Docs Europe & APAC User Group
Tridion User Group Benelux
Tridion User Group Ohio Valley
SDL MultiTerm Ideas
SDL Passolo Ideas
SDL Trados GroupShare Ideas
SDL Trados Studio Ideas
SDL Machine Translation Cloud Ideas
SDL Machine Translation Edge Ideas
SDL Language Cloud TMS Ideas
SDL Language Cloud Terminology Ideas
SDL Language Cloud Online Editor Ideas
SDL Managed Translation - Enterprise Ideas
SDL TMS Ideas
SDL WorldServer Ideas
SDL Tridion Docs Ideas
SDL Tridion Sites Ideas
SDL LiveContent S1000D Ideas
SDL Contenta S1000D
SDL XPP Ideas
Events & Webinars
To SDL Documentation
To SDL Support
What's New in SDL
Detecting language please wait for.......
If you run Fiddler when authenticating to SDL Knowledge Center, you see:
But appended after this <xenc:EncryptedData> block in step 3 is a <Signature> block that contains a <DigestValue> and <SignatureValue>.
How is the <DigestValue> calculated?
How is the <SignatureValue> calculated?
The two standard protocols you are digging deeper into are part of the OASIS standards body organization
Perhaps it helps if you share what you want to achieve?
I'm working on a Python client for SDL using the WCF/SVC endpoints. Since the main Python library for SOAP (zeep) doesn't support all the expected protocols, I'm manually building the SOAP header and body. I've completed the first round of message exchanges, but to continue I need to generate a valid value for both <DigestValue> and <SignatureValue>. Do you know how Publication Manager does this?
In Publication Manager this is solved through the Microsoft WCF components offered by the .NET Framework (and before by Microsoft Windows Identity Framework (WIF)). In essence Publication Manager does it very similar to the open-sourced API client 'ISHRemote'
For example in https://github.com/sdl/ISHRemote/blob/master/Source/ISHRemote/Trisoft.ISHRemote/InfoShareWcfConnection.cs you'll recognize ChannelFactory. But the magic on the SOAP envelope is hidden in .NET.
Personally I think it is pretty courageous to build that up from scratch. As an alternative the Content Manager on your version still holds the DEPRECATED ASMX based API. This one is probably quite a lot faster to get working in python but is going to be removed eventually (at the time of writing it will still be available in upcoming Tridion Docs 14, then again still deprecated).
Adding some reasons for deprecation... First it relies on the built-in security system so where the CMS owns the username and the password which is not where the world is heading. Second, the ASMX-based SOAP implementation is old and bypassed by various other standards - then again that makes that there are a lot of libraries to help you implement it.
Were you successful in creating code that connects to the API using Python?
Good luck, and please share if you have success.
I wasn't able to connect with Python using the WCF/SVC endpoints. But I was able to access the API with Python using the ASMX endpoints.
You can see this brief example of using Python to authenticate to SDL's old API: https://gist.github.com/tintinno/4e8953259c8588332e2a7bf96dc8aa13
Hope that helps!