the option ImageStorageLocation="Session" for RadCaptcha I used earlier was working OK, until now.
The problem with the Captcha came right after the latest update of my RadControls was applied (Q3 2013). Simply put, instead of the image with captcha numbers, we now get no image at all.
Looking deeply at the problem, I discovered that if we change the Captcha's ImageStorageLocation to "Cache" the captcha image is rendered as expected. However, I have to use the Session option, because other options was not appropriate (not working) in my hosting environement.
Can anyone help please, or is it a bug in the latest Q3 2013 update.
5 Answers, 1 is accepted
Anyone can help?
If you are using RadCaptcha utilizing Session for its storage location you need to change the WebResource handler as follows:
Before the latest Q3 2013 update ImageStorageLocation="Session" was working correctly with the following web.config specifications:
<add path="Telerik.Web.UI.WebResource.axd" verb="*" type="Telerik.Web.UI.WebResourceSession" validate="false" />
<add name="Telerik.Web.UI.WebResource.axd_*" path="Telerik.Web.UI.WebResource.axd" verb="*" type="Telerik.Web.UI.WebResourceSession" preCondition="integratedMode" />
With this extra option you suggested (you added ", Telerik.Web.UI" into above handlers) it looks like the captcha is working again as expected. I will apply the solution tomorrow on the live server and will let you know if anything unusual happen.
Thankyou very much for a quick response.
My final conlusions about the subject:
1. on the local machine (Visual Studio 2013 professional, integrated IIS) the Captcha's option ImageStorageLocation="Session" is working only if we specify type="Telerik.Web.UI.WebResourceSession, Telerik.Web.UI" in web.config (as you suggested)
2. on the production server (Windows Server 2008 R2 Datacenter, IIS 7.5) the option ImageStorageLocation="Session" is (also) working without this extended specification in web.config. In other words, it is enough to specify type="Telerik.Web.UI.WebResourceSession" (without ", Telerik.Web.UI").
The most important thing is that it is working as expected, but the question why we have such a difference between the local and server side remains.
I am not sure what could be causing the problem when the RadControls assembly is not specified in the first case. It is possible that the HTTP handler cannot be located in the DLL file.
Overall, when an HTTP handler is declared in a separate assembly, it is recommended to specify this assembly after setting the type of the handler. This is why I would suggest using the version that Dobromir suggested and that worked for you in both scenarios. The documentation of the control will be updated to include this setting.