Skip to main content

Filter by idea status

10000+ Ideas

Document and officially support POST for API authenticationNew

I've seen many customers have a security review that comes back flagging the use of GET on the API and putting client id and secret on the URL. Apparently people are somehow convinced that that's "in public". https://developers.marketo.com/rest-api/authentication/#using_an_access_token developers.marketo.com/rest-api/endpoint-reference/authentication-endpoint-reference/#!/Identity/identityUsingGET I've explained to people that it doesn't put it in cleartext to the public exactly (which is what people seem to think), as all connections are HTTPS. There is an abstract risk related to logging or something like proxy intercepting - if they log full URLs somewhere then that would be logged in a file somewhere and then that file and who can see it is important. Regardless, it's not how OAuth 2.0 is supposed to work and there is risk associated with GET, which is why it's not allowed in the OAuth 2.0 spec. Would it be possible to update these pages to show that you can use a POST? i.e. both of these work perfectly well:   curl --location --request GET '123-ABC-456.mktorest.com/identity/oauth/token?grant_type=client_credentials&client_id=<client id>&client_secret=<client secret>'     curl --location --request POST '123-ABC-456.mktorest.com/identity/oauth/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'grant_type=client_credentials' \ --data-urlencode 'client_id=<client id>' \ --data-urlencode 'client_secret=<client secret>'I'm not sure if the POST is officially supported at Marketo, but it absolutely should be, and if it is, I think the documentation should have that as the default, not the GET, and maybe even deprecate the GET, up to you.Security is more and more on people's minds and this has been flagged in numerous companies. I tried the POST like 2 years ago, and saw that it worked, and have told people they can use that instead - I just told someone else today and I think it might be best to just support this and change the documentation.Thanks for the consideration.

john-baldwinNew Participant

Improvements to Document Custom IntegrationsNew

The Workfront experience for Document->Custom Integrations lacks several critical pieces of functionality that have resulted in extended downtime on our systems. For example, we have had instances where the Adobe Enhanced Connector will stop processing project properly. However there is no indication in Workfront that there is any problem. In the case of a failure is with the Workfront functionality, Workfront will stop sending data to the connector if it detects too many failures when sending data. Although detecting failures and halting communication to avoid complication has merit, the implementation within Workfront is deeply flawed. The communication from Workfront to the Enhanced Connector happens through the Custom Integration system in Workfront (Setup -> Documents -> Custom Integration).The Custom Integration Feature uses an API key that must match between AEM and Workfront. Generally, this works acceptably.The Custom Integration Feature, however, is flawed in significant ways:There is no way to remove old integrations. We have 27 integration configurations in the system, but only 4 are needed.When a custom integration is marked “frozen” or “disabled” in Workfront, there is no indication in the UI.When a custom integration is marked “frozen” or “disabled” there is no notification to alert admins.There is no UI to un-freeze or re-enable a custom integration.There are no logs that we can view that show the state of the custom integration.The authorization token for the interface is not visible, but if it is not the same between systems, the interface will fail.Multiple custom integrations can share the same name and same destination. This can (and has) resulted in confusion regarding which custom integration should be made active.If a new integration is set up, its auth token will be different, and existing project communications will fail. Recently, we had to revert the auth token value to a previous state using methods described below.There is an API call we can use to access the event subscriptions, which are the message identifiers for current integrations:The API results do not show the name of the integration. Only the GUID is shown for the specific event subscription in the API. The GUID is not visible in the UI, so alignment is difficult.The API returns 160,383 results currently, so it can be a fishing expedition to locate the relevant records to determine current state.Even if we locate the record that tells us whether the custom integration is frozen or disabled, we cannot fix the state with this API. It has some benefit for identification.The authorization token is visible in the API results, but to verify it against AEM requires hashing the token (using asystem/console/crypto interface in AEM) to compare to the existing configuration. In addition to not being visible, most of this is not documented and requires getting to the Workfront engineering team to restore our connection communication to resolve the issue. We cannot simply create a new connection, because a new connection would disable all existing communication between the systems and would break all existing projects. So we need to restore the existing connection. Because of the above complications, when we encounter a connector issue, we face hours, and sometimes days, of downtime while we explain to initial support team the issue. We need to repeatedly escalate to resolve. What would we like changed: We would like to be able to remove outdated custom integrations.We would like to be able to see the current status of any custom integration.We would like to ability to unfreeze and re-enable any custom integration.We would like a UI to allow us to match the auth token between the two systems. This ideally would happen automatically.We would like to be able to review logs to understand the current state of the integration without requiring assistance from Adobe.We would like the custom integration process to be documented to ensure both ourselves and Adobe support understand and can resolve the problem quickly.