Details

    • Type: Bug Bug
    • Status: Closed
    • 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
    • Similar Issues:
      Show 5 results 

      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.

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            SE Support
            Reporter:
            Brian Chan
            Recent user:
            Randy Zhu
            Participants of an Issue:
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              4 years, 15 weeks, 2 days ago

              Development

                Structure Helper Panel