9 Replies Latest reply on May 2, 2007 12:18 PM by homerj.

    Mathematical captcha & Email obfuscator

      Hello,

      I would like to donate some stuff to seam:

      1. A component that converts strings into (hexa)decimal html entities.
      2. A tag to use this obfuscator (mainly a shortcut for h:outputText escape="false" ...).
      3. A mathematical captcha that asks for the solutions of simple equations (like they use at jroller). The equation can be obuscated with the tag described at 2..
      4. A tag to obfuscate email addresses (see http://www.seowebsitepromotion.com/obfuscate_email.asp for more details).

      Would be great if you include it in 1.3 ;)

      Please see JIRA for more details.

      Regards
      Stephan

        • 1. Re: Mathematical captcha & Email obfuscator
          • 2. Re: Mathematical captcha & Email obfuscator

            @Pete Muir:

            At first let me thank you for your response but some part I don't get so let us fiddle this out ;).

            You said:

            * the source for your changes need to be submitted in diff format, ideally fairly fine grained (obfuscator seam component, mathematical captcha component, email address JSF component, obfuscator JSF component)
            * MathCaptchaResponseValidator appears to be unused
            * Patch should be against seam source tree (not com.example, another faces-config etc)

            Further, we are currently trying to work out what the role of JSF components is in Seam. I think we need to hold on commiting the JSF components for now.


            1. I purposefully didn't use the patch format because I thought it's easier for you to integrate this way and my code doesn't rely on existing seam code. Further my code is "fine grained" - like you demanded. So all you / the seam developers have to do is to rename the classes & merge faces-config.xml, jsf-ui.taglib.xml, taglib.tld into JBossSeam/src/ui.

            2. I might be wrong but AFAIK MathCaptchaResponseValidator does the same job as org.jboss.seam.captcha.CaptchaResponseValidator - that means it gets called by the hibernate validator and relays validation to the MathCaptcha component.

            3. please see 1.

            4. This part I don't understand: "Further, we are currently trying to work out what the role of JSF components is in Seam. I think we need to hold on commiting the JSF components for now." My hopes just were that you include it in jboss-seam-ui.jar so it can be used like s:link, s:cache, ...

            However: My intention was to give you a working example as proof of concept but if you insist on using the patch format I can give it a try (I haven't used it before but I have trust in my eclipse so this will probably work ;)).

            I'm looking forward to your response.

            Regards
            Stephan

            • 3. Re: Mathematical captcha & Email obfuscator
              pmuir

              Sorry, I might have sounded a bit negative on the bug tracker - don't get me wrong - I and everyone else (being presumptuous) is really grateful for your contribution :)

              "Homer J." wrote:
              1. I purposefully didn't use the patch format because I thought it's easier for you to integrate this way and my code doesn't rely on existing seam code. Further my code is "fine grained" - like you demanded. So all you / the seam developers have to do is to rename the classes & merge faces-config.xml, jsf-ui.taglib.xml, taglib.tld into JBossSeam/src/ui.


              I find it much easier to read a patch than a set of files - and it also means that you can submit a patch for each area of functionality (even if some patches depend upon others) - such we can see how you've built up the component. It also means that we can more easily choose to apply part of your functionality and know that it works as you intended...

              At the end of the day, Gavin will need to review all this anyway, and this will make it faster for him.

              2. I might be wrong but AFAIK MathCaptchaResponseValidator does the same job as org.jboss.seam.captcha.CaptchaResponseValidator - that means it gets called by the hibernate validator and relays validation to the MathCaptcha component.


              Sorry, my bad, yes you are completely correct.

              3. please see 1.


              Just far less source of errors - someone forgets to rename something somewhere and it all goes wrong :( If you say - I've developed and tested this patch against Seam head and it works great - then we can apply it with much less work!

              4. This part I don't understand: "Further, we are currently trying to work out what the role of JSF components is in Seam. I think we need to hold on commiting the JSF components for now." My hopes just were that you include it in jboss-seam-ui.jar so it can be used like s:link, s:cache, ...


              So, with the addition of the Ajax4jsf, RichFaces etc. projects to jboss.org, we are considering what role JSF components have in Seam, and whether some of the controls should be moved to other jboss.org projects. We haven't finished discussing this yet afaik :) So I was just suggesting that we hold of committing this until we have a roadmap for JSF components in Seam. We are still quite a way off 1.3.0.GA so this should be resolved by then!

              However: My intention was to give you a working example as proof of concept but if you insist on using the patch format I can give it a try (I haven't used it before but I have trust in my eclipse so this will probably work ;)).


              I always had problems with Eclipse and CVS patch on the anoncvs connection (it mangles whitespace and newines) and had much more success with command line cvs (looks like you are on a unix machine so this shouldn't be a problem :) ).

              • 4. Re: Mathematical captcha & Email obfuscator

                No need to excuse, I don't think that you sounded negative.

                I just thought this way you have more control over how to integrate it without worries cause it's only a handful of files.

                Anyway: I converted the whole stuff into 3 patches. It's tested (& working) with todays CVS head and JBoss AS 4.2.0CR2. Please have a look at it if you have some time.

                PS: To create cvs patches on the command line I had to manually fiddle with CVS/Entries because the N parameter was ignored which is plain retarded. Is there any other option I haven't found or is this normal?

                • 5. Re: Mathematical captcha & Email obfuscator

                  Thanks for your review once again Peter but - again - there are some parts I don't understand ;)

                  So here it goes, you said:

                  JSF components need explicit rather than implicit attributes and to support EL

                  What do you mean with explicit & implicit attributes? Is it bad that the email tags are derived from the obfuscator tags?
                  Regarding the EL: if you do something like:
                  <s:email value="#{user.email}" />
                  it will work so I'm not sure what you mean.

                  Regarding nested tag support: while I theoretically agree with you there is not much point in it because now both tags are derived from HtmlOutputText and therefore behave in a similar way. E.g.:
                  <p>
                   <h:outputText styleClass="foo" value="bar" />
                  </p>
                  <p>
                   <h:outputText styleClass="foo">bar</h:outputText>
                  </p>

                  results in
                  <p>
                   <span class="foo">bar</span>
                  </p>
                  <p>
                   bar<span class="foo"></span>
                  </p>

                  So everything in the body is rendered before the tags - which can be done by simply writing it before the tag too.

                  Last but not least you said that the default behavior of the email tag should be to do no obfuscation. I don't see why because the whole point of this tag is to obfuscate email addresses so this would only result in more writing for the normal user while other people still could manually write unobfuscated addresses down.
                  Therefore my suggestion would be to add obfuscation="none" so people can use the tag without obfuscation - although I don't see a reason why anyone should do that.

                  The rest is changed like you suggested!

                  I'm looking forward to your response.

                  • 6. Re: Mathematical captcha & Email obfuscator
                    pmuir

                     

                    "Homer J." wrote:
                    What do you mean with explicit & implicit attributes? Is it bad that the email tags are derived from the obfuscator tags?


                    The spec suggests

                    The render-independent characteristics of a user interface component are represented as JavaBean component properties, following JavaBeans naming conventions . Specifically, the method names of the getter and/or setter methods are determined using standard JavaBeans component introspection rules,


                    - i.e. attributes should have getters and setters (this is a convention we follow with other JSF components in Seam). It's fine to back the getters and setters with the attributes map if you like.

                    Regarding the EL: if you do something like:
                    <s:email value="#{user.email}" />
                    it will work so I'm not sure what you mean.


                    Sorry, you are right, I'm not familiar with the attribute map - it's cleverer than I thought!

                    Regarding nested tag support: while I theoretically agree with you there is not much point in it because now both tags are derived from HtmlOutputText


                    I think the email one needs to be based conceptually on h:outputLink, which does allow nested text

                    and therefore behave in a similar way. E.g.:

                    So everything in the body is rendered before the tags - which can be done by simply writing it before the tag too.


                    Yes, you are right. This is broken imo ;) - might be worth "fixing" it...

                    Last but not least you said that the default behavior of the email tag should be to do no obfuscation.


                    Up to you :) - that was my initial reaction, but I really don't have strong feelings!

                    • 7. Re: Mathematical captcha & Email obfuscator

                      Thanks for your response!

                      I added attributes & getters / setters to the UI* classes.

                      Regarding h:outputLink as parent for s:email I agree with you that it would be conceptually correct / better, but I don't like it because the user would be forced to write more. Further the text (not only the value) get´s obfuscated because, normally, one not only uses a mailto link but also shows the email address in the body of the tag. Therefore further distinction would be required to distinguish normal text and - e.g. - a picture. Last but not least the email tag relies on some stuff in the obfuscator tag to keep the code dry.

                      However: I stumbled upon a pretty strange behavior when using value binding and ui:repeat - e.g:

                      <ui:repeat value="#{newMembers}" var="newMember">
                       <s:obfuscator value="#{newMember.memberName}" /><br />
                      </ui:repeat>

                      results in:
                      Mona<br />
                      obfuscationOf(Mona)<br />
                      obfuscationOf(obfuscationOf(Mona))<br />
                      ...

                      This happens because the value is not renewed for 2nd+ iterations which seems to happen because the name of the value binding is the same. I worked around that by manually setting value=null in encodeEnd but this seems to be quite an ugly hack. Further it works fine for h:outputText.

                      Is this a bug in JSF or am I missing the obvious? How is this normally solved?

                      • 8. Re: Mathematical captcha & Email obfuscator
                        pmuir

                         

                        "Homer J." wrote:
                        as parent for s:email I agree with you that it would be conceptually correct / better, but I don't like it because the user would be forced to write more. Further the text (not only the value) get´s obfuscated because, normally, one not only uses a mailto link but also shows the email address in the body of the <a> tag. Therefore further distinction would be required to distinguish normal text and - e.g. - a picture. Last but not least the email tag relies on some stuff in the obfuscator tag to keep the code dry.


                        Hmm, I see what you mean - I'll think about it :) I can just see this being a cause of confusion down the line to users...

                        However: I stumbled upon a pretty strange behavior when using value binding and ui:repeat - e.g:
                        <ui:repeat value="#{newMembers}" var="newMember">
                         <s:obfuscator value="#{newMember.memberName}" /><br />
                        </ui:repeat>

                        results in:
                        Mona<br />
                        obfuscationOf(Mona)<br />
                        obfuscationOf(obfuscationOf(Mona))<br />
                        ...

                        This happens because the value is not renewed for 2nd+ iterations which seems to happen because the name of the value binding is the same. I worked around that by manually setting value=null in encodeEnd but this seems to be quite an ugly hack. Further it works fine for h:outputText.

                        Is this a bug in JSF or am I missing the obvious? How is this normally solved?


                        Post an updated patch and I'll look - this *normally* works with no tricks!

                        • 9. Re: Mathematical captcha & Email obfuscator

                           

                          "petemuir" wrote:
                          ...Post an updated patch and I'll look - this *normally* works with no tricks!


                          Thanks, I posted Patch2.tar.gz.