4 Replies Latest reply on Jan 23, 2016 8:58 AM by mcollinge

    Preventing spam in different languages.

    jocdrew30

      I want to create a plug-in that only allows ASCII keys to be submitted on my forum. We are currently using Jive SBS 4.5.5.0 and having isues with the Russian, Korean and a few others languages and it would help if I could only allow ASCII keys on my forum.

       

      If there is a simpler way to do this that would be great. I have never made a plug-in and I am researching the how to go about this, however I am concerned that since 4.5.5.0 is old I might be fighting a up hill battle. Any advice would be greatly appreciated.

        • Re: Preventing spam in different languages.
          mcollinge

          Yes, I think you should be able to do this in a Jive 4.5 plugin. We do it in 6 using a plugin which we built for anti-spam and it acts as a content interceptor.. we then do a bunch of things, including checking for any Ideograph Characters (e.g. Chinese) which will trigger content moderation.

           

          However, since you've never done a plug-in, this is quite ambitious for your first one

            • Re: Preventing spam in different languages.
              cgum

              Matt Collinge, Just out of curiosity, does your interceptor just reject content (e.g. throw an exception), or does it call ModerationHelper.forceContentModeration(JiveObject obj)?  Or does it do something else?

               

              I found that in Jive 7 (and Jive 8), using the ModerationHelper to put content into moderation caused a lot of problems.  It would look like it was working properly in the UI, but under the covers, all was not well because it would create two different moderation workflow objects, and then there were a lot of ways to get content out of moderation by the spammer: 1) create an content object (which gets moderated) and then edit it, adding an image to it (gets it out of moderation). 2) create a document (which gets moderated), edit it (which makes a second version), revert to the original version (gets out of moderation).

               

              To refactor the interceptor that I was using to put content into moderation away from using the ModerationHelper, I instead had to implement a number of classes:

               

              com.jivesoftware.community.moderation.interceptors.InterceptorInfo:  This class is really only instantiated in the spring.xml of the plugin.  That is, I don't have my own class that derives from it.  Here's an example of what the Spring bean definition looks like:

              The InterceptorInfo requires these other classes:

              1) a JiveInterceptor (mine does nothing at all, but in the invokeInterceptor() method, you could flat out reject content here by throwing a "RejectedException".

              2) an InterceptorModerationConfig<T1> where T1 is the implementation class of your custom JiveInterceptor.  Mine does nothing.  This class is used so that you could have configuration options inside the "Interceptors" section of the admin console.  I chose to make a separate UI for managing our spam plugin's configuration.

              3) an InterceptorHelper<T2> where T2 is the implementation of your custom InterceptorModerationConfig.  This is where all of my logic resides to put things into moderation.  The "shouldModerate" method that takes the actual JiveObject instance is the one you should use.  The result type of that method is an enum called InterceptorModerationDecision.  The values are needs_moderation, no_moderation, or not_applicable.  If you know something should go into moderation, return "needs_moderation".  If you know it shouldn't go into moderation, return "no_moderation".  If you don't know, or it should be the responsibility of a different interceptor to answer that question, return "not_applicable".

              4) an InterceptorPropertyConverter<T3> where T3 is the implementation of your custom InterceptorModerationConfig.  It's kind of like the factory object that takes the key/value pairs (Map<String,String>) of the persisted config object and creates a new config instance.  Again, since I've got my own way of saving off configuration, I just return a new instance of my custom implementation of InterceptorModerationConfig.

               

              So, in a nutshell, I only have logic of consequence in my InterceptorHelper and everything else is just there to get my logic hooked up in the moderation workflow.

            • Re: Preventing spam in different languages.
              cgum

              Drew Jocham,

               

              Jive has changed things up a lot over the years with how moderation is handled.  If I were you, I would first download the Jive source code and look for other classes that implement JiveInterceptor and see how they are putting content into moderation and model your plugin's interceptor after one of those.

               

              Based on the version you are using, I would get the source from here: https://maven-secure.jivesoftware.com/archiva/repository/jive.internal/com/jivesoftware/jive-sbs-public/

               

              (If you are using a version of Jive 6 or higher, look here: https://maven-secure.jivesoftware.com/archiva/repository/jive.internal/com/jivesoftware/jive-core/ )

               

              Log in with your Jive maven repo credentials and find the Jive version that you are using and click on that folder.  Then, download the XXXX-sources.jar file to a Temp directory or something.  Rename the .jar to .zip and unzip it.  Then, search the source for JiveInterceptor.  An example to look at might be ./com/jivesoftware/community/interceptor/KeywordInterceptor.java.

               

              I agree with Matt Collinge that this might be an ambitious first plugin, but hopefully this will help point you in the right direction.