Hello,
> Could you have a look at the code I attached to
> http://opensource.atlassian.com/projects/spring/browse/SEC-2 a little
> while
> ago.
I saw your code Georges, it is great, but it is very tied to JCaptcha and to
the specific use case you implemented (captcha-ize the login page).
> I really don't know too much about JCpatcha, other than the fact that I
> have
> it working with Acegi, but I'm wondering how "Spring friendly" it is - or
> could be. For example, can it be configured by setting JavaBean
> properties?
JCaptcha is fully designed according to IOC principle. We do not use
JavaBean properties injection but constructor injection (IOC type 3).
> If so, it could be plugged into a Spring context file. This would
> eliminate
> the need to create a JCaptcha singleton, since Spring could manage its
> 'singleton-ness".
You are so right!
As a consequence it is possible to use Spring to instanciate the service
singleton and much more : using spring configuration file allows simple
captcha test configuration.It is also possible to use the Spring JMX handler
to register the JCaptcha MBeans (for statistics collection and monitoring)
and we are working on a new CapthcaEngine that use the Spring/Quartz handler
to schedule asynchronous captcha generation.
Here is a sample spring config file for JCaptcha (contains reference to
unpublished code):
<beans>
<bean id="captchaService"
class="com.octo.captcha.service.image.BufferedManageableImageCaptchaService"
>
<constructor-arg index="0">
<ref bean="container"/>
</constructor-arg>
<constructor-arg
index="1"><value>testBuffered</value></constructor-arg>
</bean>
<bean id="JPEGImageServletWriter"
class="com.octo.captcha.servicewebapp.JPEGImageServletWriter">
<constructor-arg index="0">
<ref bean="captchaService"/>
</constructor-arg>
</bean>
<bean id="defaultQuestionAndValidationService"
class="com.octo.captcha.servicewebapp.DefaultQuestionAndValidationService">
<constructor-arg index="0">
<ref bean="captchaService"/>
</constructor-arg>
</bean>
<bean id="exporter"
class="org.springframework.jmx.export.MBeanExporter">
<property name="beans">
<map>
<entry key="bean:name=captchaService">
<ref local="captchaService"/>
</entry>
<entry key="bean:name=container">
<ref local="container"/>
</entry>
<entry key="bean:name=containerManager">
<ref local="manager"/>
</entry>
</map>
</property>
</bean>
<!--Construction of the ContainerEngine -->
<bean id="java.util.Locale.US"
class="org.springframework.beans.factory.config.FieldRetrievingFactoryBean"/
>
<bean id="ratioUS"
class="java.lang.Double">
<constructor-arg index="0"><value>0.9</value></constructor-arg>
</bean>
<bean id="java.util.Locale.FRANCE"
class="org.springframework.beans.factory.config.FieldRetrievingFactoryBean"/
>
<bean id="ratioFR"
class="java.lang.Double">
<constructor-arg index="0"><value>0.1</value></constructor-arg>
</bean>
<bean id="configuration"
class="com.octo.captcha.engine.bufferedengine.ContainerConfiguration">
<constructor-arg index="0">
<map>
<entry key-ref="java.util.Locale.US"
value-ref="ratioUS"/>
<entry key-ref="java.util.Locale.FRANCE"
value-ref="ratioFR"/>
</map>
</constructor-arg>
<constructor-arg index="1"><value>3000</value></constructor-arg>
<constructor-arg index="2"><value>10000</value></constructor-arg>
<constructor-arg index="3"><value>500</value></constructor-arg>
<constructor-arg index="4"><value>10000</value></constructor-arg>
</bean>
<bean
class="com.octo.captcha.engine.bufferedengine.QuartzBufferedEngineContainer"
id="container" singleton="true">
<constructor-arg
type="com.octo.captcha.engine.CaptchaEngine" index="0"><ref
bean="engine"/></constructor-arg>
<constructor-arg
type="com.octo.captcha.engine.bufferedengine.buffer.CaptchaBuffer"
index="1"><ref bean="memBuffer"/></constructor-arg>
<constructor-arg
type="com.octo.captcha.engine.bufferedengine.buffer.CaptchaBuffer"
index="2"><ref bean="diskBuffer"/></constructor-arg>
<constructor-arg
type="com.octo.captcha.engine.bufferedengine.ContainerConfiguration"
index="3"><ref bean="configuration"/></constructor-arg>
</bean>
<bean
class="com.octo.captcha.engine.bufferedengine.manager.QuartzBufferedEngineMa
nager" id="manager">
<constructor-arg
type="com.octo.captcha.engine.bufferedengine.QuartzBufferedEngineContainer"
index="0"><ref bean="container"/></constructor-arg>
<constructor-arg
type="org.quartz.Scheduler" index="1"><ref bean="quartz"/></constructor-arg>
<constructor-arg
type="org.quartz.CronTrigger" index="2"><ref
bean="cronTriggerFeeder"/></constructor-arg>
<constructor-arg
type="org.quartz.CronTrigger" index="3"><ref
bean="cronTriggerSwapper"/></constructor-arg>
<constructor-arg
type="org.quartz.JobDetail" index="4"><ref
bean="feederJobDetail"/></constructor-arg>
<constructor-arg
type="org.quartz.JobDetail" index="5"><ref
bean="swapperJobDetail"/></constructor-arg>
</bean>
<bean
class="com.octo.captcha.engine.image.gimpy.DefaultGimpyEngine" id="engine">
</bean>
<bean
class="com.octo.captcha.engine.bufferedengine.buffer.MemoryCaptchaBuffer"
id="memBuffer">
</bean>
<bean
class="com.octo.captcha.engine.bufferedengine.buffer.DiskCaptchaBuffer"
id="diskBuffer">
<constructor-arg
index="0"><value>captchas</value></constructor-arg>
<constructor-arg
index="1"><value>true</value></constructor-arg>
</bean>
<bean
class="org.springframework.scheduling.quartz.SchedulerFactoryBean"
id="quartz">
<property name="autoStartup">
<value>true</value>
</property>
<property name="waitForJobsToCompleteOnShutdown">
<value>true</value>
</property>
<property name="triggers">
<list>
<ref local="cronTriggerFeeder" />
<ref local="cronTriggerSwapper" />
</list>
</property>
</bean>
<bean id="feederJobDetail"
class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryB
ean">
<property name="targetObject"><ref
bean="container"/></property>
<property
name="targetMethod"><value>feedPersistentBuffer</value></property>
<property
name="concurrent"><value>false</value></property>
</bean>
<bean id="swapperJobDetail"
class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryB
ean">
<property name="targetObject"><ref
bean="container"/></property>
<property
name="targetMethod"><value>swapCaptchasFromPersistentToVolatileMemory</value
></property>
<property
name="concurrent"><value>false</value></property>
</bean>
<bean id="cronTriggerFeeder"
class="org.springframework.scheduling.quartz.CronTriggerBean">
<property name="jobDetail">
<ref bean="feederJobDetail" />
</property>
<property name="cronExpression">
<value>0 0 * * * ?</value>
</property>
</bean>
<bean id="cronTriggerSwapper"
class="org.springframework.scheduling.quartz.CronTriggerBean">
<property name="jobDetail">
<ref bean="swapperJobDetail" />
</property>
<property name="cronExpression">
<value>0/5 * * * * ?</value>
</property>
</bean>
</beans>
> All of this is not directly related to an Acegi adapter
> to
> JCaptcha, since Acegi can be used in non-spring applications. However, I
> expect that people who use Acegi would also be using Spring - so it would
> be
> nice if JCaptcha could be managed from a Spring context file. DWR took
> that
> approach with their AJAX framework (well, sort of) and I think it opens it
> up to a whole new set of people.
I agree.
Best regards.
MAG
>
>
>
> ----- Original Message -----
> From: "marc antoine garrigue" <[EMAIL PROTECTED]>
> To: <acegisecurity-developer@lists.sourceforge.net>
> Sent: Sunday, July 03, 2005 9:59 AM
> Subject: RE: [Acegisecurity-developer] Captcha
>
>
> > Hi guys,
> > It took me some time to answer, because I had to talk with my project
> team
> > in order to make a decision, and I also wanted to let people here
> comment
> on
> > this subject.
> >
> > We though the current discussion could be split into the two following
> > issues :
> > * The first one concerns the place of the integration point.
> > * The second one concerns the binary distribution of both packages
> > (jcaptcha in acegi or acegi in jcaptcha)
> >
> > * On the Place of the integration point matter:
> > We agree with you both :
> > - This integration point is not only about integration, but deals also
> with
> > specific security issues (when to ask the user to solve a captcha, how
> to
> > forward his request, ect...), and this is not in the scope of the
> jcaptcha
> > project.
> > - This integration point should be more tied to acegi than to jcaptcha,
> > using a lot of acegi objects and only one interface from jcaptcha.
> > - We also share Georges' vision concerning the idea of this adapter :
> lets
> > build an open and independant captcha adapter system.
> > As a consequence :
> > -We think that it would be nice to have a generic captcha adapter in
> acegi
> > -I would be very pleased to help you in designing and implementing such
> a
> > solution. Have you already put together a team to do it?
> > -I can commit my adapter code, under your license and copyright, as
> soon
> as
> > you give me the access to your VSC.
> >
> >
> >
> > * Concerning distribution
> > -Let me just say that the jcaptcha team 's goal is not to become the
> most
> > downloaded project of sourceforge. Our primary and still first
> objective
> > is to provide a reliable and extensible framework to build captchas. We
> > are not particulary looking forward to having all acegi users become
> > jcaptcha users. Our goal is to provide solutions for jcaptcha users to
> help
> > them to integrate captchas in theirs applications.
> > -We have a problem concerning our respective projects licenses : Acegi
> is
> > under Apache2, and JCaptcha is under LGPL. These licenses are not
> > compatible and thus acegi cannot bundle JCaptcha in its distribution.
> > As a consequence :
> > -We may work on a special aggreement on this point, i'm currently
> gathering
> > my team opinion.
> > -We may build a sample application under a compatible license.
> >
> > Finally, I just wanted to add that we are very excited here about
> the
> > acegi-captcha adaptor.
> >
> > What are your thoughs on this ?
> >
> > Best regards
> > MAG
> >
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf
> Of
> > George Franciscus
> > Sent: lundi 27 juin 2005 05:22
> > To: acegisecurity-developer@lists.sourceforge.net
> > Subject: Re: [Acegisecurity-developer] Captcha
> >
> > I think the most convincing argument to placing the integration point in
> > Acegi is that one day there could be other Captcha implementations.
> Acegi
> > based Captcha interfaces and adapters allows people to swap their
> > implementations in/out as the need arise ... in the spirit of Spring and
> > Acegi!
> >
> > I'll post my raw code in JIRA so you take a look.
> >
> >
> > ----- Original Message -----
> > From: "Ben Alex" <[EMAIL PROTECTED]>
> > To: <acegisecurity-developer@lists.sourceforge.net>
> > Sent: Sunday, June 26, 2005 12:37 AM
> > Subject: Re: [Acegisecurity-developer] Captcha
> >
> >
> > > Marc-Antoine Garrigue wrote:
> > >
> > > > Ben Alex told me recently that the API is now stabilized and thus we
> > > > planned to share our code before two weeks and release it this
> summer.
> > > > What is your opinion about the plan?
> > >
> > > Hi George and Marc-Antoine
> > >
> > > George, if you post your code against the JIRA task I would be pleased
> > > to take a look and explore integration.
> > >
> > > Marc-Antoine, I believe the Acegi Security-JCaptcha integration would
> be
> > > better maintained within the Acegi Security project, for a few
> reasons:
> > >
> > > * I would like to give Acegi Security users the benefits of JCaptcha
> > > without having to download it separately. People will like seeing
> > > JCaptcha demonstrated in the Contacts sample application included with
> > > Acegi Security. Many people cut 'n' copy the sample code into their
> own
> > > application, so many will keep the JCaptcha integration. In reverse, I
> > > cannot imagine JCaptcha having a sample application that demonstrates
> > > Acegi Security features.
> > > * The specific approach to JCaptcha integration with Acegi Security
> > > configuration attributes, filter security interceptor, the ThreadLocal
> > > and Authentication object is likely to develop over time. As decisions
> > > about when to invoke JCaptcha and record the outcome are more concerns
> > > of Acegi Security, it seems more desirable the integration be managed
> in
> > > the latter's source code.
> > > * Luke is well-progressed on a web.xml to Acegi Security migration
> tool
> > > (http://opensource.atlassian.com/projects/spring/browse/SEC-1). In a
> > > later version we will include as part of the wizard process a
> question,
> > > "would you like JCaptcha services?" or similar. This will allow people
> > > addressing their webapp security to adopt JCaptcha. We can only ask
> this
> > > question if JCaptcha is included with Acegi Security.
> > > * In terms of exposure by where to bundle, many Spring users who
> > > download Acegi Security would be unaware of JCaptcha. So bundling
> > > JCaptcha with Acegi Security will increase exposure of JCaptcha. On
> the
> > > other hand, Spring users who download JCaptcha will probably already
> be
> > > aware of Acegi Security (due to the forum, reference documentation,
> > > subproject status, several books on it etc). I cannot therefore see
> > > Acegi Security increasing its user base by being bundled with
> JCaptcha,
> > > whereas I can see an exposure benefit to JCaptcha by being bundled
> with
> > > Acegi Security.
> > > * Acegi Security already bundles the CAS client, so a precedent has
> been
> > > set of placing third party project integration within Acegi Security.
> > > The CAS integration demonstrates what I was referring to earlier about
> > > the integration being more tightly coupled with Acegi Security than
> CAS,
> > > with the latter offering well-defined protocol standards.
> > > * JCaptcha has currently had 4,498 downloads
> > >
> >
> (http://sourceforge.net/project/stats/index.php?group_id=97877&ugn=jcaptch
> a&
> > type=&mode=alltime)
> > > whilst Acegi Security has currently had 21,468
> > >
> >
> (http://sourceforge.net/project/stats/index.php?group_id=104215&ugn=acegis
> ec
> > urity&type=&mode=alltime).
> > > Both projects have been around for a similar length of time. Given
> this,
> > > it seems reasonable to have greater confidence in my earlier point
> that
> > > JCaptcha exposure would increase through being bundled with Acegi
> > > Security, as opposed to the other way around.
> > >
> > > It would be good to work with you on this. If you wanted to maintain
> the
> > > JCaptcha integration within Acegi Security, I would be pleased to give
> > > you CVS access to ensure ongoing integration compatibility.
> > >
> > > I welcome other people's comments on this. I am just trying to achieve
> > > maximum awareness and exposure for both projects, as JCaptcha is a
> good
> > > solution which I know people will use if it's easy for them to do so.
> > >
> > > Cheers
> > > Ben
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > > informative Webcasts and more! Get everything you need to get up to
> > > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > > _______________________________________________
> > > Home: http://acegisecurity.sourceforge.net
> > > Acegisecurity-developer mailing list
> > > Acegisecurity-developer@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > Home: http://acegisecurity.sourceforge.net
> > Acegisecurity-developer mailing list
> > Acegisecurity-developer@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > Home: http://acegisecurity.sourceforge.net
> > Acegisecurity-developer mailing list
> > Acegisecurity-developer@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
> >
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Home: http://acegisecurity.sourceforge.net
> Acegisecurity-developer mailing list
> Acegisecurity-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
