Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 5.1.2, 5.2.3, 6.0.5 GA
    • Fix Version/s: --Sprint - SP, 6.1.0 CE RC1
    • Component/s: WCM
    • Labels:
      None
    • Branch Version/s:
      6.0.x, 5.2.x, 5.1.x
    • Backported to Branch:
      Committed

      Description

      CaptchaImpl wires "Captcha" instances 2 ways:

      1.) The plugin sets the instance using the plugin's class loader. This is how Hooks override the default Captcha implementation. This works all the time.

      2.) The portal sets the name of the Captcha class, but does initialize it on startup, to make startup speed faster.

      The first time a user hits a page that requires a captcha, it will now try and initialize the Captcha (if we're using the portal one and not the hook). This will work MOST of the time because the class loader for the class initialization is the correct one - the portal's. Sometimes, the thread context class loader may be a plugin's, which will then cause it to break.

      Since this block is never reached except by the portal, the fix is to have it use the portal class loader all the time.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                support-lep@liferay.com SE Support
                Reporter:
                brian.chan Brian Chan
                Participants of an Issue:
                Recent user:
                Esther Sanz
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Days since last comment:
                  6 years, 40 weeks, 3 days ago