Forum Discussion

prasadu507's avatar
2 years ago

LithiumSSO token || How to calculate session inactivity

Hi Team,

As per the documentation
https://developer.khoros.com/khoroscommunitydevdocs/docs/lithiumsso-token


The  session key expires after 30 minutes of inactivity, after 24 hours, or when the community is restarted (whichever comes first).

Reg 24h limit : For every 24hrs ( Using scheduler ) we can refresh the token.

But, How to calculate the inactivity. What is the best practice for it.

  • Hello prasadu507 
    We use to calculate the inactivity of a user by last_visit_time field in the users table.
    You can use the following LiQL to get the last_visit_time of a user:

    Select last_visit_time from users where id ='<user.id>'

    Let me know if you need any further help in this. 


    Regards,
    Abhishek Gupta 

  • prasadu507 The best practice here would be to implement retry logic that can detect an expired session key error response from the API, acquire a new fresh session key, and make the API call again.

    Trying to track the session key inactivity period may be futile, as you would still need retry logic to account for the "when the community is restarted" scenario.

    Additionally, artificially attempting to keep the session active by making a passive request every 30-X minutes may unnecessarily tie up system resources, and again you would still need to account for the other scenarios of expiring after 24 hours or after a restart.

  • Hello prasadu507 
    We use to calculate the inactivity of a user by last_visit_time field in the users table.
    You can use the following LiQL to get the last_visit_time of a user:

    Select last_visit_time from users where id ='<user.id>'

    Let me know if you need any further help in this. 


    Regards,
    Abhishek Gupta 

  • AdamN's avatar
    AdamN
    Khoros Oracle

    prasadu507 The best practice here would be to implement retry logic that can detect an expired session key error response from the API, acquire a new fresh session key, and make the API call again.

    Trying to track the session key inactivity period may be futile, as you would still need retry logic to account for the "when the community is restarted" scenario.

    Additionally, artificially attempting to keep the session active by making a passive request every 30-X minutes may unnecessarily tie up system resources, and again you would still need to account for the other scenarios of expiring after 24 hours or after a restart.