Uploaded image for project: 'Artifactory Binary Repository'
  1. Artifactory Binary Repository
  2. RTFACT-18524

When loginBlockDelay is set to 0, upgrades since version 6.7 will fail

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 6.7.0, 6.7.3
    • Fix Version/s: 6.8.1
    • Component/s: None
    • Labels:
      None
    • Environment:

      Both test Postgres DB 9.6.2

      One one RPM installation and one Zip installation.

      RPM was ugpraded 6.4.0 to 6.7.3, Zip was upgraded 6.6 to 6.7.3.

       

    • Support Tickets:
      Show
      Rackspace - Support Case , ADTRAN, Inc. - Support Case
    • Support Comments:
      Hide
      There is a bug that Loren and I have found during a call that affects upgrades to versions 6.7.0 and above.
      The bug doesn’t affect new installations, only those that have changed the `system property artifactory.security.loginBlockDelay` and set it to 0

      The reason some customers have this property is because we used to offer it as a workaround for different issues with admins or other users being locked. Setting the previously mentioned property to 0 would get rid of the delay. This is one of the JIRAs for which we offered this workaround:
      https://www.jfrog.com/jira/browse/RTFACT-12656

      The main JIRA for this issue is “Login backoff will grow indefinitely” and was fixed on 6.7.0
      https://www.jfrog.com/jira/browse/RTFACT-18301

      The problem with that JIRA was the calculation of the delay, which before 6.7.0 was
        ```private static final long SEQUENCE_BASE = 2;
         private long calculateBackoff(int attempts) {
              long baseDelay = ConstantValues.loginBlockDelay.getLong();
              long maxLoginDelay = ConstantValues.loginMaxBlockDelay.getLong();
              long timeToBackoff = (long) pow(SEQUENCE_BASE, attempts) * baseDelay;
              if (timeToBackoff >= maxLoginDelay) {
                  return maxLoginDelay;
              }
              return timeToBackoff;```
      Now this was changed to
      ```private final long LOGIN_BASE_DELAY = ConstantValues.loginBlockDelay.getLong();
          private final long MAX_BLOCKED_DELAY = ConstantValues.loginMaxBlockDelay.getLong();
          private final long MAX_FAILED_ATTEMPTS_FOR_CALCULATION =
                  64 - Long.numberOfLeadingZeros(MAX_BLOCKED_DELAY / LOGIN_BASE_DELAY - 1); // ceil log_2 of max wait units

      private long calculateBackoff(int attempts) {
              return (attempts > MAX_FAILED_ATTEMPTS_FOR_CALCULATION) ?
                      MAX_BLOCKED_DELAY :
                      LOGIN_BASE_DELAY << attempts;
          }```
      Which when the system property is set to 0, will cause a division by 0 error. Changing the value to “2" seemed to work fine to fix the issue.
      Artifactory doesn’t seem to set this value itself, but it will keep it during an upgrade if not overwritten.

      We only know of one case so far (96858, We don't think it was Artifactory that set the variable to 0, but the customer has no recollection of having changed it in the past.), and Loren reproduced this as well. However there are plenty of customers we have found that were given this workaround. When they upgrade next we expect they will see this issue:

      Box Inc - *This is a SaaS customer and we changed the property for them. SaaS is in 6.6.5 so there could be issues soon* - 72651
      Citi Bank - 88169 & 88169
      The Sherwin-Williams Company - 70105 & 80534
      IHS Markit - 71737
      Software AG - 80534
      Comerica - 88208/88202
      Show
      There is a bug that Loren and I have found during a call that affects upgrades to versions 6.7.0 and above. The bug doesn’t affect new installations, only those that have changed the `system property artifactory.security.loginBlockDelay` and set it to 0 The reason some customers have this property is because we used to offer it as a workaround for different issues with admins or other users being locked. Setting the previously mentioned property to 0 would get rid of the delay. This is one of the JIRAs for which we offered this workaround: https://www.jfrog.com/jira/browse/RTFACT-12656 The main JIRA for this issue is “Login backoff will grow indefinitely” and was fixed on 6.7.0 https://www.jfrog.com/jira/browse/RTFACT-18301 The problem with that JIRA was the calculation of the delay, which before 6.7.0 was   ```private static final long SEQUENCE_BASE = 2;    private long calculateBackoff(int attempts) {         long baseDelay = ConstantValues.loginBlockDelay.getLong();         long maxLoginDelay = ConstantValues.loginMaxBlockDelay.getLong();         long timeToBackoff = (long) pow(SEQUENCE_BASE, attempts) * baseDelay;         if (timeToBackoff >= maxLoginDelay) {             return maxLoginDelay;         }         return timeToBackoff;``` Now this was changed to ```private final long LOGIN_BASE_DELAY = ConstantValues.loginBlockDelay.getLong();     private final long MAX_BLOCKED_DELAY = ConstantValues.loginMaxBlockDelay.getLong();     private final long MAX_FAILED_ATTEMPTS_FOR_CALCULATION =             64 - Long.numberOfLeadingZeros(MAX_BLOCKED_DELAY / LOGIN_BASE_DELAY - 1); // ceil log_2 of max wait units private long calculateBackoff(int attempts) {         return (attempts > MAX_FAILED_ATTEMPTS_FOR_CALCULATION) ?                 MAX_BLOCKED_DELAY :                 LOGIN_BASE_DELAY << attempts;     }``` Which when the system property is set to 0, will cause a division by 0 error. Changing the value to “2" seemed to work fine to fix the issue. Artifactory doesn’t seem to set this value itself, but it will keep it during an upgrade if not overwritten. We only know of one case so far (96858, We don't think it was Artifactory that set the variable to 0, but the customer has no recollection of having changed it in the past.), and Loren reproduced this as well. However there are plenty of customers we have found that were given this workaround. When they upgrade next we expect they will see this issue: Box Inc - *This is a SaaS customer and we changed the property for them. SaaS is in 6.6.5 so there could be issues soon* - 72651 Citi Bank - 88169 & 88169 The Sherwin-Williams Company - 70105 & 80534 IHS Markit - 71737 Software AG - 80534 Comerica - 88208/88202

      Description

      The bug doesn’t affect new installations, only those that have changed the system properties to have artifactory.security.loginBlockDelay=0

      Previously to workaround a different JIRA (RTFACT-18301) we recommended to set this value. However to fix that same JIRA, the formula to calculate was delayed, adding a division into the equation. When this value is set to 0 this division will be undefined (division by zero).

      After boot the upgrade will output the following:

      2019-02-14 20:09:17,444 [art-init] [ERROR] (o.a.w.s.ArtifactoryContextConfigListener:96) - Application could not be initialized: / by zero

      ...

      Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'userLockInMemoryServiceImpl' defined in URL [jar:file:/opt/jfrog/artifactory/tomcat/webapps/artifactory/WEB-INF/lib/artifactory-storage-db-6.7.3.jar!/org/artifactory/storage/db/security/service/UserLockInMemoryServiceImpl.class]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.artifactory.storage.db.security.service.UserLockInMemoryServiceImpl]: Constructor threw exception; nested exception is java.lang.ArithmeticException: / by zero

       

      After setting artifactory.security.loginBlockDelay=2, we were able to restart and fix the issue.

       

       

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                nadavy nadavy
                Reporter:
                angellom angellom
                Assigned QA:
                andreyt
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: