Product ideas | Community
Skip to main content

Filter by idea status

10000 Ideas

Ryan_T
Ryan_TNew Participant

Enhancing Workfront API Integration: Adopting Standard OAuth2 Authorization Code FlowNew

Description - Workfront's API does not use the default standard for OAuth2 Authorization Code Flow. Using out-of-the-box tools available in Integration Platforms or Microsoft Power Platform or other web frameworks is not possible because these solutions expect OAuth2 Authorization Code Flow to use access_token as a Bearer token returned via the and not as sessionID.Why is this feature important to you - There is an increase in development cost and maintenance when creating or connecting third-party apps to Workfront via the Workfront API because of the non-standard OAuth implementation. Limits or even prevents our ability to continue orchestrating and automating work by placing Workfront at the center of our operations.How would you like the feature to work - Ultimately, we would like to be able to use the access_token as part of the Authorization Header as a Bearer token described in the OAuth and standards documentation. This would mean that the token_type be set to Bearer (default, industry standard) and not sessionID (custom Workfront, non-standard) and for subsequent API calls to handle this appropriately.OAuth 2.0 Bearer Token UsageRFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage (ietf.org)Current Behaviour - Workfront’s OAuth API implementation is non-standard, in that once you’ve gone through the usual Authorization Code Flow, the access_token needs to go in the Request Header “sessionID” in each API call. This non-standard approach makes it very difficult and sometimes impossible to integrate with other third-party and custom built applications unless significant time is invested into workaround. In other cases we are left to use a fixed API Key, which isn’t ideal from a security perspective.

digitalNickNew Participant

Allow Flexible Consent Management via AEP SDKNew

Description -While conducting our first real-life implementation case for data collection via the AEP Web SDK and the Edge Network, we wanted to rely on the out-of-the-box customer consent preferences:https://experienceleague.adobe.com/docs/experience-platform/edge/consent/supporting-consent.html?lang=en However, while experimenting with the different options available, we were facing major limitations with regards to the flexibility of handling the consent - in particular with the current consent object:  consent: [{ standard: "Adobe", version: "2.0", value: { collect: { val: "y" }, metadata: { time: "2021-03-17T15:48:42-07:00" } } }]  Mainly, I'm referring to these two limitations stated in the official documentation:#1 No granular consent handling:"Currently, the SDK supports only a single all or nothing purpose." #2 No overwriting of the collected consent:"After a user has opted out, the SDK will not allow you to set the users collect consent to y." Why is this feature important to you -RE#1: Modern consent management solutions such as OneTrust offer great flexibility and granularity for the user to decide which type of cookies and tracking solutions he/she is opting-in or not (e.g., first- vs. third-party). However, this can't be reflected with the current AEP consent object as it only takes binary inputs. This can result in fewer opt-in rates and/or data coverage because few users decide to go "all-in" and respectively the consent object has to be set to "n" which prevents any tracking to happen. Since data is key to the measurement of all kinds of marketing activities, the amount of data points captured is key, less coverage means less meaningful insights which ultimately can make client-side tracking solutions redundant. RE#2: As the user can opt-out this value of "n" will be irreversible written onto the AMCV, meaning in reality, for this particular user we will never ever be able to track any kind of data (unless they empty the browser's cache, switch devices etc.). This is even more severe as it drastically limits the potentially tracked users and can even have a disastrous impact when for instance, the value has been set to "n" by mistake. How would you like the feature to work -RE#1: Instead of just offering "y" or "n", give the flexibility to set different tracking categories within the consent object which correspond to different cookies/technologies (e.g., functional, first-party, third-party):  consent: [{ standard: "Adobe", version: "2.0", value: { collect: { functional: "y", tracking: "y", marketing: "y" }, metadata: { time: "2021-03-17T15:48:42-07:00" } } }]  RE #2: Just add the capability to either reset and/or update the value that has been previously submitted as the consent object would tremendously help in overcoming the initially described limitation. Current Behaviour -As explained above.