Details about this thread
  • State Not Answered
  • Replies 3 replies
  • Subscribers 293 subscribers
  • Views 1733 views
  • Users 0 members are here
Related content from around SugarClub

Why is the Outlook plugin asking for Sugar password repeatedly?

Adam Muencheberg

I am running an "onsite" instance of SugarCRM (version 7.6.2.1) with the Outlook 2010 32 bit Plugin (version 2.1.0) and throughout the day I am repeatedly asked for my Sugar password within Outlook. Once entered it works fine for a period of time (hour or two) and then the username/password dialog pops up with the password field empty. The username seems to be stored properly within the plugin setting, however the password is not. Other users I have spoken to within my place of business do not have this issue. I seems to be a local situation. Is there a timeout setting or something of that nature that I'm not seeing within the plugin settings?

Any suggestions would be appreciated, Thanks.

Parents
  • 0

    We frequently see this behavior:  OPI loses its credentials and requires a re-login.  Word Plugin also loses it's credentials and requires a re-login.  Presumably the Excel plugin will also misbehave.

    No other known applications are logging in as us,

    Our IP is static and

    Our token expiry is high:

      array (
        'access_token_lifetime' => 86400,
        'refresh_token_lifetime' => 86400,
      )

    Are there other reasons our OAuth Tokens are becoming invalid?

    What are those "corner cases" you mentioned?

Reply
  • 0

    We frequently see this behavior:  OPI loses its credentials and requires a re-login.  Word Plugin also loses it's credentials and requires a re-login.  Presumably the Excel plugin will also misbehave.

    No other known applications are logging in as us,

    Our IP is static and

    Our token expiry is high:

      array (
        'access_token_lifetime' => 86400,
        'refresh_token_lifetime' => 86400,
      )

    Are there other reasons our OAuth Tokens are becoming invalid?

    What are those "corner cases" you mentioned?

Children
  • 0 in reply to Kevin Cook

    Hi Kevin,

    IP-Wise, the IP that the server sees the user come from can impact it, not the IP the server is at.

    However, if I was taking a guess, I'd surmise that folks are getting logged out most likely once a day minimum. Likely on the web UI too.

    86400 seconds, at 3600 seconds per hour, is 24 hours of token lifetime for both tokens. The refresh being set identically to the access token means that when the access token expires, it will always require a new login.

    Normally access tokens are short-lived (30-60 minutes, for example) with the idea that they are multiple-use credentials and if they are sniffed, you don't want them to be able to be used for a long time. When the access token expires, the client is denied access and told the token is not usable. The client then presents the refresh token, which is a single-use "Get a new pair of tokens" token. If the refresh token is valid, the client is given a new access token and a new refresh token,

    Having both of the tokens expire at the same time obviously means that the refresh token will not be valid when the access token expires, so a new log-in will be required. You'll most likely want to reduce the lifespan of the access tokens for proper security, and increase the lifespan of the refresh tokens. The refresh token lifetime should reflect "The longest period of time that you want somebody to 'stay logged in' after logging in and while not actively using the system

    If they are getting logged out more frequently than once a day, some examples of edge cases...

    • A windows server was found to have antivirus software deleting certain session files on occasion
    • A session handler cache server repeatedly crashed on an instance, causing all sessions to become invalid.
    • A database was misconfigured in a way that caused the oauth_tokens table to not store data accurately.
    • A person with database access decided to tamper and randomly delete entries from the oauth_tokens table.
    • A server had a bad DIMM that intermittently corrupted data in some tables, including the oauth_tokens table.
    • A user logged in on two different computers in OPI, (which counts as "somewhere else logging in as you"). Or in the Web UI, on two different browsers because they normally used Chrome for SugarCRM but when they clicked on a link in Email, it opened Sugar in Edge, so they logged in there, peeked at the record, closed that, and found Chrome logged out as a result.

    Other examples of things that can cause issues are known bugs in some versions that cause sessions to be lost and some users to be logged out when server cache or metadata rebuilds occur. Those bugs are corrected in the most up to date versions (7.8.2+ and 7.9. If any of these bugs are impacting the server, they would occur generally when any changes are made from any Administration menu system,

    So in your case, if it's daily, it's the settings. If it's multiple times per day, see the above, and if all else fails, if you're on a supported version, go ahead and drop a case in with us so we can look at your specific situation for you.