- 🇺🇸United States japerry KVUO
8.x-1.x is now EOL, which ran on the WebDam/Bynder platform.
Problem Statement
Currently once the user authenticates successfully to the Acquia DAM through the this module an access token is provided by the acquia dam using this access token user can access all the acquia DAM assets in drupal, but this access token is valid only for 45 minutes and expires after 45 min, hence due to this the user need to login to acquia DAM after every 45 mins to access media assets from acquiaDAM.
Proposed solution
As upon authentication acquia DAM sends accessToken, accessTokenExpiry & refreshToken as a response the use of refershToken to request new accessToken to be done programmatically to provide seamless experience to the user.
Modules current workflow
Currently upon successful authentication with aquiaDAM, the accessToken, accessTokenExpiry & refreshToken are stored in user_data table against each user.
After every 45 minutes the accessToken gets expired, this expired token gets deleted in two places as below
1. hook_cron :-
https://git.drupalcode.org/project/media_acquiadam/-/blob/8.x-1.x/media_...
hence hook_cron implementation has a function
media_acquiadam_purge_expired_tokens();
which purges the expired token
2. In controller oauth action authPage:-
https://git.drupalcode.org/project/media_acquiadam/-/blob/8.x-1.x/src/Co...
hence upon visiting acquiaDam route on user profile, it first check if the token is valid, if not then delete this token even if we have a valid refershToken.
Hence even if the refreshToken functionality is already available in the module due to deletion of the expired token, the refreshToken function never gets called as seen in the checkAuth
function at
https://git.drupalcode.org/project/media_acquiadam/-/blob/8.x-1.x/src/Cl...
Hence if we don't, delete the expired token then the refreshToken function will be called at
https://git.drupalcode.org/project/media_acquiadam/-/blob/8.x-1.x/src/Cl...
and getting the new accessToken programatically providing seamless exprience to the user.
Proposed approach to implement this solution
We found two approach suitable to resolve this problem explained as below:-
As the token gets expired every 45 minutes, a cron job is set to execute the refresh token function every 30 minutes hence all the valid tokens based on the accessTokenExpiry time stored in user_data db table will be refreshed every 30 minutes using the cron job hence no user is logged out.
1. User wont get logged out of acquia DAM hence no need to reauthenticate unless refershToken expires.
1. This will keep on refreshing all the access Tokens hence for non frequent user there would be redundant data present in the user_data table as the token wont get expired hence wont get deleted.
2. The implementation of cron job to run an linux crontab will have to be setup on the servers or dependency on contrib module like ultimate cron which again need site to have traffic to run the cron hence external dependency.
The second approach we propose is to provide a new config where admin can set maximum number of days the expired tokens can be persisted, and creating a function will check all the token expired for more than the set maximum date and deleting all such tokens which are expired and have passed maximum days. This function can be called in the hook_cron implementation.
1. Here we will be deleting all the expired token if the users who has not visited the portal for more then set days, hence no redundant token data will be present in the user_data table.
2. As we aren't deleting the token from the db before the set days, refreshToken function will be utilised and accessToken will be renewed due to which seamless experience will be provided to the user.
Hence we need to know which method/approach suits more and is generic enough for other to use, we also would like to know if any better approach is though over other than the above two to solve this problem.
Closed: won't fix
1.0
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
8.x-1.x is now EOL, which ran on the WebDam/Bynder platform.