An async recaptcha control - looking for testers

Feb 20, 2010 at 10:15 AM
Edited Mar 4, 2010 at 4:24 AM

Hi all,

UPDATE: The latest installation instructions: http://www.bloodforge.com/post/BlogengineNET-reCaptcha-093-Installation-Instructions.aspx (Version 0.95 - Install procedure did not change from v0.93, just the files )

I attempted to integrate the Recaptcha control into BlogEngine.NET ( 1.6 ). The control should be fairly straightforward to integrate into your blogs - shouldn't take more than 5 minutes and it does not requrie a recompile.  The calls are made asynchonously, so the page will not reload when the user attempts to submit a comment.

I've outlined the steps required to implement it at http://www.bloodforge.com/post/Async-Recaptcha-for-BlogEngineNET-16.aspx . If anyone doesn't mind trying it out to see if it works for you, it'd be fantastic.

Pay attention to a bug that I may or may not have introduced w/ this, however - I noticed it after deploying the control, and it is documented in the post.  I'll be doing some investigating tomorrow, so hopefully I'll know more about it.  It does seem completely unrelated, but I can't be certain...

Thanks!

P.S. Oh, and I am currently using the Recaptcha on my site if you're interested in seeing how it works or looks.

Coordinator
Feb 20, 2010 at 7:03 PM

I took a look at the code.  It looks very good.

One area for improvement is to combine the recaptcha check and the actual Comment Saving process into one async callback.  The main reason why is because a person can bypass the recaptcha check by filling out the normal comment fields (except recaptcha) and manually running BlogEngine.validateAndSubmitCommentForm().  I actually just did that on your site, and was able to leave a test comment without filling out the Recaptcha field.

When I put Michael's captcha solution on my site a couple of days ago, I made the same type of change to his solution, since his solution was doing the same thing.  I'm not sure if the whole process can be done in one shot in Recaptcha.cs without modifying CommentView.ascx.cs in the User Controls folder.

Incidentally, what I did on my site was modified the addComment() JS function in blog.js.  It passes about 9 values back to the server (name, email, website, comment body, etc).  I added a 10th value which is the response to the captcha.  Then in the normal RaiseCallbackEvent() handler in CommentView.ascx.cs, I check and validate the captcha response there.  If it doesn't validate, I don't save the comment and pass back a value that the appendComment() function in blog.js handles and displays a message.  Just thought I'd share this possible approach.

At any rate, this looks like a great implementation of recaptcha for BE.

Feb 20, 2010 at 8:41 PM

Thanks for the feedback Ben. Initially, I actually had modified Blog.js to do exactly what you describe, but then I went off on a tangent on how I can implement the control without modifying as much of BE as possible. However, I do see the problem you're describining, so perhaps it is unavoidable. I'll look into this tonight and see what I can come up with.

Coordinator
Feb 21, 2010 at 12:55 AM

Yeah, there's a tradeoff between how easy it is to add the Recaptcha control, and how effective it can be.  I was impressed with how easy this current version of your Recaptcha control is to add.  It may also never be a problem where a spammer is capable of or aware of manually calling the JS function to directly submit a comment.

One thing you might be able to do is to add a cookie via JS that contains the response to the Recaptcha challenge.  This could be done instead of tacking the Recaptcha response onto the list of parameters passed into BE in addComment() in blog.js.  The server side code can then check the Recaptcha response in the cookie.  It may still be necessary to intercept the normal Comment adding process to ensure the Recaptcha response is valid -- either in CommentView.ascx or possibly from within the Recaptcha App_Code control, or in a HTTP module, or somewhere.  Just some thoughts ...

Feb 21, 2010 at 4:36 AM

I've updated the Recaptcha control so that everything happens on a single postback - pretty much as described in your first post.

Unfortunately, it is not as simple to implement as the previous version, but it should no longer be possible to bypass the Recaptcha by manually executing javascript on the page. I've had to make changes to blog.js and CommentView.ascx.cs.

The latest installation instructions are available at: http://www.bloodforge.com/post/BlogengineNET-Recaptcha-091-Installation-Instructions.aspx

Coordinator
Feb 21, 2010 at 4:54 AM

It looks very impenetrable now!  I couldn't bypass the Recaptcha check.

Yes, installation is a bit more involved, but you outlined the steps as good as possible.

Your efforts will help people suffering from bot spam.  And maybe we can get this solution or something close to it into BE.

Feb 21, 2010 at 5:00 AM

Thanks!

So far I'm pretty happy with the solution.  Hopefully some people will want to try it out. I'm keeping it as version 0.91 for now, since I don't really want to promote it to 1.0 until I see that it is working for more than a day :)

Feb 21, 2010 at 10:08 AM

Hi Filip, I've just added the control to my blog (http://davewhite.net) and it looks good so far.  I'm using 1.6.0.0, but will upgrade to 1.6.0.x in the next few days. 

I'll let you know in a few days if it fails.  Ben, would it be possible to include this in the base package?

Feb 21, 2010 at 9:47 PM

Dave,

I'm glad you got it working!

Also, another user reported a bug with the 0.91 version of the Recaptcha - it was incorrectly getting focus each time it was loaded on the page, which caused the page to focus on the recaptcha every time the page was loaded.  I've put in a fix and updated the installation instructions w/ the latest files.  If you did not make any changes to the Recaptcha.cs file, it should be sufficient to download the latest ZIP and simply replace your Recaptcha.cs with the one from the zip.  If you did make changes to Recaptcha.cs, there are instructions in the comments on what needs to be changed in Recaptcha.cs to fix the issue.

Feb 22, 2010 at 3:12 PM

Nice work...I've added it to three blogs receiving heavy comment attacks, and thus far it seems to be working well!

Feb 24, 2010 at 2:16 PM
dotnetnoob wrote:

Nice work...I've added it to three blogs receiving heavy comment attacks, and thus far it seems to be working well!

Hmmm...it seems that one auto-generated spam got through early this morning (1.6.0.1 and recaptcha 0.91) ...I wonder if there's any way to force-bypass this solution?

Feb 24, 2010 at 6:01 PM

There's companies out there where they sell services such as solving Captchas.  It is a service that they charge for, and that in itself is probably enough to get rid of 99% of the spam (although it is probably only a matter of time before someone creates a free service).

I'm not sure if that is what happened in your case or not, though.  Do you know for sure that the message was auto-generated?

Feb 24, 2010 at 6:13 PM
fstanek wrote:

There's companies out there where they sell services such as solving Captchas.  It is a service that they charge for, and that in itself is probably enough to get rid of 99% of the spam (although it is probably only a matter of time before someone creates a free service).

I'm not sure if that is what happened in your case or not, though.  Do you know for sure that the message was auto-generated?

Pretty sure...the comment was just a screen-scrape of the post title. If it was a human, they would have probably entered something more descriptive.

Feb 24, 2010 at 7:07 PM

I'm keeping an eye out for spam on my blog too ( ever since I installed the recaptcha, I have not received a spam comment ). With that said, I wouldn't be surprised if there was a way to bypass the Recaptcha somehow. 

I'll try working on an update so that at least it will add some logging to the recaptcha.  I'll need to think a bit more about it, but hopefully it will have enough information to let us have a good guess as to exactly how the comment was posted.  Hopefully I'll have something ready in a day or two.

Feb 24, 2010 at 7:25 PM
fstanek wrote:

I'm keeping an eye out for spam on my blog too ( ever since I installed the recaptcha, I have not received a spam comment ). With that said, I wouldn't be surprised if there was a way to bypass the Recaptcha somehow. 

I'll try working on an update so that at least it will add some logging to the recaptcha.  I'll need to think a bit more about it, but hopefully it will have enough information to let us have a good guess as to exactly how the comment was posted.  Hopefully I'll have something ready in a day or two.

I have a couple of sites that have been hammered with dozens of comment spam/day. I updated one of them two days ago, and since then only one has sneaked through. The other website hasn't been updated yet, as a control, and it's still getting hammered. I'm going to add the recaptcha code to that site as well and see how it goes over the next few days.

Thus far, however, it seems to be working quite well, and I for one really appreciate your efforts fstanek! 

Feb 24, 2010 at 7:28 PM

If one would find a method to bypass recaptcha woudn't apply that on your blog, much bigger targets out there. recaptcha is used by twitter, facebook, etc. It would be a big boom. :) 
It could bypass it if it is a flaw in the way recaptcha was implemented in Blogengine, right now that does not sound like the case(say like was here http://websecurity.com.ua/1505/ some time ago).

Heh, one comment generated by a tool...
And why would one need a tool for this in the first place...
If you have a popular blog, you can get a lot of human generated spam, even if you add a captcha, registration or whatever would be out there.
Remember some spammers do not know english very well, so they will post anything.

Feb 24, 2010 at 8:17 PM

Adrian,

I'm more worried that there is a fault with the way I integrated the Recaptcha into the blog.  It is possible that I left some way for a spammer to get in. Hopefully once the logging update is in it will be more clear.

Feb 24, 2010 at 8:27 PM
adrianf wrote:

If one would find a method to bypass recaptcha woudn't apply that on your blog, much bigger targets out there. recaptcha is used by twitter, facebook, etc. It would be a big boom. :) 
It could bypass it if it is a flaw in the way recaptcha was implemented in Blogengine, right now that does not sound like the case(say like was here http://websecurity.com.ua/1505/ some time ago).

Heh, one comment generated by a tool...
And why would one need a tool for this in the first place...
If you have a popular blog, you can get a lot of human generated spam, even if you add a captcha, registration or whatever would be out there.
Remember some spammers do not know english very well, so they will post anything.

Hi Adrian: Believe me I'm not complaining about spam dropping to a single comment! But, I'm pretty sure that 99% of the comment spam was coming from 'bots, as it was usually a hodgepodge of text munged from the title or first sentence in the post. Also, the fact that it dropped nearly to "zero" after adding the reCaptcha indicates it was 'bots and not humans, or it would have kept right on going.

Some of the spam was some "boilerplate" comments that were repeated multiple times across multiple websites that I had running BE...I thought that it could have been humans just cutting and pasting, but again, the fact that it dropped off with reCaptcha indicates it was 'bots. More often than not, the boilerplate had no relationship to the actual post, and I would think a human would at least try to tailor the spam a little to seem legitimate...but that was rarely the case.

Lastly, your point about a popular blog drawing lots of human spam is true, but in this case, these blogs (alas) are not that popular (yet), and the only comments they were drawing were spam.

Feb 24, 2010 at 9:50 PM
Edited Feb 24, 2010 at 9:56 PM

Hey guys, the way I see it:
 - the invisible captcha used by Blogengine was broken and there is a tool or tools out there actively used. However, the tool is limited regarding distribution.
 - on my blog, I got tons of spam. Some were generated with that tool and some manually.
 - so some spammers use that tool and some manually post comments.
 - usually human spammers are from poor countries, cheap to hire, and not quite skilful. I saw weird comments on my blog over the time, some actually read what I wrote and try to look interesting, some drop quotations, some just take the title or some lines from the blog entry.
 - once you get on the spam list, you get enroll in some sort of a spam database, so occasionally, someone will come and drop you a few friendly comments. Usually they search after google page rankings and after various blogging platforms.

I put too the recaptcha. Spam levels dropped immediatelly, the tool being defeated. Actually is been quite a while since I did not have a single spam comment in 24/48 hours. Eventually some spam comments appeared, but they are old "friends" of mine, I already know their style by now. So the recaptcha seems to do its job from what I see on my blog.

So:
First, Ben took a look at Filip's solution, found something and gave some directions, and in the end said the result looks OK. Usually Ben is pretty stellar around here, so if Ben says is OK. :)
Second, Filip's solution is fresh out there, there are not many people using it. So it does not even worth bother messing with it.
Third, it only worths coming up with a tool (if this solution can be broken *and*) there is *value* in that. Just think that there are out there many many Blogengine blogs butt naked with the invisible captcha, compared with a few ones using the recaptcha. It even took quite a while till they come up with a tool to defeat the invisble captcha, -> to come with a tool they need the blogging platform to become popular in order to be an attractive/valueble target.
Fourth, there are other Blogengine blogs using weak captchas that can be broken(like described here: http://www.carbonwind.net/blog/post/Fun-with-weak-CAPTCHAs.aspx).

What I'm saying is that in such a short notice is very unlikely there is a tool targeting Filip's solution and that momentarily there is little value in creating such a tool.
Excluding the point if you pissed off someone, who now wants to get you aggravated. Or some over zealous spammer.

Ideally, Blogengine should come with an out-of-the-box captcha solution that can defeat bots/tools, till then everybody will muck around with what they can.

Feb 25, 2010 at 7:16 AM
fstanek wrote:

I'm keeping an eye out for spam on my blog too ( ever since I installed the recaptcha, I have not received a spam comment ). With that said, I wouldn't be surprised if there was a way to bypass the Recaptcha somehow. 

I'll try working on an update so that at least it will add some logging to the recaptcha.  I'll need to think a bit more about it, but hopefully it will have enough information to let us have a good guess as to exactly how the comment was posted.  Hopefully I'll have something ready in a day or two.

 Looks like I spoke too soon. I just got 2 spam comments today. Now I'm really motivated to put some logging in place to figure out if they're actually passing the reCaptcha :)

Feb 26, 2010 at 6:35 AM
Edited Feb 26, 2010 at 6:48 AM

Ok, I think I have the logging put in correctly. The latest install instructions are available at: http://www.bloodforge.com/post/BlogengineNET-reCaptcha-093-Installation-Instructions.aspx

Changes from the previous version are the Recaptcha.cs file, and there are now two new files that go in the '/admin/Pages/' directory which handle the display of the log. The log is also available via the Extension Manager.

It should be possible to disable the logging via the Extension Manager. Also, with logging enabled, it will keep track of successful recaptcha attempts (up to a maximum that you can specify in the Extension Manager). For each successful Recaptcha, it will track how many attempts it took the user to finally succeed, as well as the time it took from the original page load, and the time it took from the last unsuccessful reCaptcha attempt on the current page.

The idea behind this log is to verify that spam comments actually passed the reCaptcha check. If you receive a spam comment and it is not listed in the log (but logging is enabled), then there is clearly a hole somewhere that would require much more investigation.

Feb 26, 2010 at 11:20 AM

Filip, with the latest update I'm seeing an error on my blog.  The error is shown below.  This occurs on BE build 1.6.0.0 

Compilation Error

Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.

Compiler Error Message: CS0535: 'Controls.RecaptchaControl' does not implement interface member 'System.Web.UI.IValidator.IsValid.set'

Source Error:

 
Line 130:    }
Line 131:
Line 132:    public class RecaptchaControl : WebControl, IValidator
Line 133:    {
Line 134:


Source File: g:\inetpub\wwwroot\blog\App_Code\Controls\Recaptcha.cs    Line: 132

Feb 26, 2010 at 4:22 PM

Dave:

Thanks for letting me know. I updated the ZIP with the fixed file.

Feb 26, 2010 at 7:58 PM

I did get my first spam message w/ the logging enabled.  The spammer correctly solved the Captcha in 1 attempt, although it took them 131 seconds to do so.

Feb 26, 2010 at 8:31 PM

Wow Filip...WTF? Do you think this was a 'bot or a real person? 131 secs is a long time for a person to solve a captcha, unless they're cycling through 30 browser windows or something like that.

Coordinator
Feb 26, 2010 at 8:51 PM

I think 131 seconds means how much time it took from when the page/captcha was served to the visitor.  So this includes the time the person read the post, composed a comment, filled in the captcha and submitted it to the server.

Feb 26, 2010 at 9:30 PM

Ben is correct, in that it was the time from the initial page load to comment submission.  I have no way of actually knowing how long the captcha solving took, other than it being between 0 and 131 seconds.

The spam message was: "Argentina touristic and travel information. Your travel guide to discover Buenos Aires, Patagonia & other touristic places."

Given the content of the comment and the post it was submitted on ( it was submitted on the installation instructions for the reCaptcha ), I do not think any of the 131 seconds was used to read the post.

One thing to consider as well: The spammer solved the reCaptcha on their first attempt.  That means that the spammer did not attempt to submit a comment w/o the reCaptcha filled in, as each comment submission counts as an attempt. If it was a bot, it was smart enough to know not to submit a comment b/c of the reCaptcha (basically, if it was a bot, it was waiting for the person running it to fill in the solution, or it was waiting for a solution from somewhere else, possibly one of the captcha-solving services available on the web).  

Anyways, 131 seconds is a lot of time to spend to spam my site (my site is not very popular, so I don't really understand why they would waste their resources). I would be much more concerned if I saw something like 1 or 2 seconds from page load to comment submission. The absolute worst would be not seeing anything in the log.

Feb 26, 2010 at 9:39 PM
BenAmada wrote:

I think 131 seconds means how much time it took from when the page/captcha was served to the visitor.  So this includes the time the person read the post, composed a comment, filled in the captcha and submitted it to the server.

Oh, um, yeah...sorry!

@Filip: It sounds like what I mentioned earlier...a combination of a luser cycling through multiple windows and entering comments/captchas manually. It will be interesting to see the average duration...it wouldn't surprise me if captcha-breakers wait a certain number of seconds before submitting to foil a rapid-submission check like you just mentioned worried you.

I've read elsewhere that some people have employed comment blocking based on time delay, to prevent automated 'bots from submitting 10 comments/sec or something like that...the delay here could be an attempt to get around that type of filtering as well.

Well-played, Mr. Spammer...well played! <g>

Feb 26, 2010 at 9:47 PM
Edited Feb 26, 2010 at 9:48 PM

Yeah, I believe the most likely scenario is spammers having multiple windows open an going through them one by one, filling in captchas if necessary. 

At this point, I have nothing on my list to add to the reCaptcha control. I will keep this running for probably a few weeks, and if I don't see anything strange happening, I will most likely promote it to version 1 and say it is ready for users who do not wish to evaluate the test version. 

Also, if you guys have any ideas on what features to add to the reCaptcha control to make it better, let me know.

Feb 27, 2010 at 5:16 AM

Your zip file has this line in the commentView.ascx.cs file:

BlogEngine.Core.CommentHandlers.IsBlacklisted

 

That function does not exist in the current code...

Feb 27, 2010 at 7:23 AM
Edited Feb 27, 2010 at 7:24 AM

Right, sorry! That had to do w/ another update I was doing.  It has been removed from the ZIP.  Thanks!

P.S. Crappy weather we're having in Cincinnati tonight :(

Coordinator
Feb 27, 2010 at 8:35 AM

I downloaded 0.93.  It's really evolved since 0.91 !  :)

There's a couple of issues related to logging.

#1.  When leaving a comment, the Post_CommentAdded event handler is firing multiple times.  This is because the Post.CommentAdded event handler is being subscribed to every time the Recaptcha control is rendered.  Each time the line of code below runs, Post.CommentAdded is being subscribed to again and again.

Post.CommentAdded += new EventHandler<EventArgs>(Post_CommentAdded);

So after the page has been displayed 5 times (the Recaptcha control has also rendered 5 times), when someone leaves a comment, the Post_CommentAdded event handler is being called 5 times -- resulting in 5 entries into the log for a single comment.  After the recaptcha control has rendered 100 times, when someone leaves a comment, 100 log entries will be created!  :)

Instead, that line of code above should only be executed once.  You could store in HttpRuntime.Cache whether that line of code above has been executed.  If it has been executed, then don't execute it again.  Something like this (with an extra 'unsubscribe' to make sure two concurrent users hitting the site at the first time don't both enter the IF block at the same exact time resulting in two 'subscriptions' -- alternatively a SyncLock could be used).

if (HttpRuntime.Cache["recaptcha-subscribed-to-post-commentadded"] == null)
{
    Post.CommentAdded -= new EventHandler<EventArgs>(Post_CommentAdded);
    HttpRuntime.Cache["recaptcha-subscribed-to-post-commentadded"] = true;
    Post.CommentAdded += new EventHandler<EventArgs>(Post_CommentAdded);
}

I'm not sure if this matters, but usually something like Post_CommentAdded is a static method that is not tied to a particular instance of a control (in this case Recaptcha).  Based on how the other events are subscribed to in BE, I think my first inclination would be to have Post_CommentAdded in the Recaptcha extension as a static method (instead of in the Recaptcha control as an instance method).  But then the Recaptcha control properties (RecaptchaAttempts, RecaptchaChallengeValue, etc) wouldn't be available from the static handler.  I *think* you can use Session state, however, from within the static handler to store/retrieve user-specific values.  I mention Session state again below .....

# 2.  For logging, this code is often being used:

HttpContext.Current.Cache[....] = .......

HttpContext.Current.Cache is not a per-user cache.  It's an application wide cache.  It's equivalent to HttpRuntime.Cache.  It may appear to be tied to a particular user because of the "Current" part, but it's not ... the same Cache is shared for the entire application.  Some minimal documentation is here.  So if you have multiple people on the site at the same time, the values for the latest person is going to overwrite previous users.

The easiest solution would be to use Session state to store these per-user values.  Session state can also be used in the Post.CommentAdded event handler (to address the #1 issue) -- should you move Post.CommentAdded into the Recaptcha extension.

..... these two issues are just related to the logging part.  Kind of a messy situation.  The main functionality of the Recaptcha control, however, seems to be working great.  Maybe the logging isn't worth it ... not sure.

Feb 27, 2010 at 10:29 AM
Edited Feb 27, 2010 at 11:37 AM

Awesome feedback!

#1. Great point about it being a static event. I thought I resolved the issue of subscribing to the event by first checking if it is a callback, but I didn't think about multiple page loads. The more I think about this, the more I'm starting to believe that using that event is not the right solution. When the event fires, there is no reference to the reCaptcha in the event.  I think the best method for logging is simply telling the reCaptcha to write to the log in the RaiseCallbackEvent of CommentView.

#2. I was initially going to use the session state to store the data, but then I realized that the session may not be available for bots and anyone who does not accept cookies. When I decided to switch the app cache, I certainly didn't think it through.  I'm actually thinking I may still use the app cache, but I'd need a unique identifier for the user/post... the GUID from the hfCaptcha maybe? At least this way it won't just be taking up space :)

I think I actually spent more time on implementing the logging functionality for the reCaptcha than on all of the other code combined for the control. I believe the log is pretty neat, and it just feels like it is so close to working - I don't want to give up on it just yet :)

EDIT: There is now a 0.94 version on my site, which should address both issues you've brought up Ben. It is still using the version 0.93 link that is at the top of this thread. Thank you for your feedback!

Feb 27, 2010 at 3:41 PM

Hah!  I didn't catch that you are from Cincinnati as well!!  We'll have to do lunch one day.

Feb 27, 2010 at 3:50 PM

After one night of this, the comment spam has stopped for now.  So this is a win.

 

On that lunch thing... took a look at  your employers website, and I work off of Lake Forest Drive, so lunch would be easy.

Coordinator
Feb 27, 2010 at 7:31 PM

Those are good solutions to address the 0.93 issues.  I put 0.94 on my blog.  Thanks  !

Feb 28, 2010 at 8:37 PM

uh-oh...first problem with reCaptcha...I added it to a custom theme in 1.6.0.1 and something's amiss...the captcha's are being "squeezed" down to 10-20px wide and are unreadable...see screencap:

http://207.158.46.202/recaptcha.jpg

I've heavily edited the "style.css" associated with the theme, so I expect that has something to do with it...but where would I look to fix this? I've tried different reCaptcha themes (e.g. "red" and "white") and it's the same for all of them...refreshing the captcha doesn't help!

Feb 28, 2010 at 9:08 PM

Open your post in IE8, go to 'Tools->Developer Tools'.

Use the "select element by click" method to select the reCaptcha image.  On the right panel, make sure the "Style" button is pressed.  You should now see all of the styles that are currently applied to the reCaptcha image.  Look through there and see what might be affecting it (check/uncheck different styles to see if that makes a difference)

Feb 28, 2010 at 9:20 PM
fstanek wrote:

Open your post in IE8, go to 'Tools->Developer Tools'.

Use the "select element by click" method to select the reCaptcha image.  On the right panel, make sure the "Style" button is pressed.  You should now see all of the styles that are currently applied to the reCaptcha image.  Look through there and see what might be affecting it (check/uncheck different styles to see if that makes a difference)

 Thanks filip...it was careless editing of the styles.css...I had accidentally set the global img width property to 14 px...yeesh...<g>

Feb 28, 2010 at 11:04 PM

I'm getting "The captcha text was not valid. Please try again." errors every time I try to make a comment.  I have set up my own private keys for my domain and I'm using those.

At the moment, my site is not online (I'm viewing it via http://localhost/) - could this be why?  Are my keys being rejected?

Mar 1, 2010 at 12:37 AM
Edited Mar 1, 2010 at 12:41 AM

CreepinJesus: I'm not 100% sure how the reCaptcha keys work.  But I would assume that if you did not make your key global, then it would work only from your domain that you registered.  You could alter your hosts file on your PC for that domain and point it to localhost.  I haven't tried that, but I would guess that it probably works.

EDIT: You can also use the keys that came w/ it on localhost, but when you upload it to your server, use your own private keys. That probably isn't the ideal way to test a site, but it should work.

Mar 1, 2010 at 8:11 AM

I've tried the hosts file 'trick', and I've even opened up my laptop to the web under my domain name to test it that way - neither worked.  Not even with a global key.

Could it firewall related perhaps?

Mar 1, 2010 at 8:39 AM

CreepinJesus: Did it work with the default keys provided? I haven't tested this with any other keys, so I'm wondering if that may be the issue...

Mar 1, 2010 at 8:46 AM

Nope :(

I'm going to back and triple-check the code I've put in from your instructions...

Coordinator
Mar 1, 2010 at 8:48 AM

It could be firewall related.  I would try and see if there's any error occurring within the actual web request to Recaptcha's service.

In Recaptcha.cs, towards the bottom is the Try-Catch block.  You can make use of the new logging in BE 1.6 to log the response.  To do this, on the Extensions tab, 'Enable' the Logger extension, if it's not already already enabled.  You can then make use of Utils.Log().  I added a couple of these calls in the revised Try-Catch block below.  The logging messages will appear in a file named "logger.txt" in App_Data.  You could sprinkle in some more Utils.Log() in other places to get a better idea of what might be going on.

try
{
	using (WebResponse httpResponse = request.GetResponse())
	{
		using (TextReader readStream = new StreamReader(httpResponse.GetResponseStream(), Encoding.UTF8))
		{
			string result = readStream.ReadToEnd();
			results = result.Split();
			Utils.Log("Recaptcha response: " + result);
		}
	}
}
catch (WebException ex)
{
	Utils.Log("Recaptcha exception: " + ex.Message);
	return RecaptchaResponse.RecaptchaNotReachable;
}

Mar 1, 2010 at 8:52 AM

I've done it again... I think I might need glasses!  It was the recaptchaResponse = args[10] line - I had it as args[0]...

I remember at the time thinking "args[0]? ...seems a bit odd...?" so if it was a mis-read, then I was pretty sure whatever I saw said args[0] at the time! haha...clearly not.

Tis working now :)  Thanks for putting up with my mistyping again :p

Mar 1, 2010 at 3:17 PM

Great!

Also, Adrian mentioned on my blog that it is possible to use the private keys on http://localhost or http://127.0.0.1 .

Mar 2, 2010 at 6:09 AM

Would it be possible to implement this on the Contact page as well?  I don't know about you, but most of my spam came from the contact page on my old site...

Mar 2, 2010 at 8:39 AM

CJ: I'll take a look at this tomorrow.  I tried to do this really quickly right now, but things got messed up b/c the page does a postback right after the callback and ends up hiding controls.  It shouldn't be too difficult to alter the way the page works, but its almost 4AM here and I got to sleep :)

Mar 2, 2010 at 6:01 PM

I found a problem with the control, and unfortunately, I don't have a solution for it right now (I'm not even sure what causes it atm).

To reproduce the error, you must use IE (I've tested with IE8 and IE6, I assume it also happens with IE7).  Go to a page with the reCaptcha, and manually refresh the page by hitting F5. Click on the "preview" button for the comment, or any other code that relies on the "BlogEngine" JavaScript object.  There will be an error that "BlogEngine" is undefined.

I'll look into this more tonight. At this point, I'm not sure of the cause. I have only been able to reproduce this in IE.  Firefox and Chrome seem to be unaffected.

I know that in the past there have been issues with IE and script compression, but I thought all those were resolved (also, disabling WebResource.axd compression and HTTP compression doesn't seem to fix this problem, so that's probably not it).  If anyone has any insight on what may be happening here, I'd love to hear it :) 

Mar 2, 2010 at 6:33 PM
fstanek wrote:

I found a problem with the control, and unfortunately, I don't have a solution for it right now (I'm not even sure what causes it atm).

To reproduce the error, you must use IE (I've tested with IE8 and IE6, I assume it also happens with IE7).  Go to a page with the reCaptcha, and manually refresh the page by hitting F5. Click on the "preview" button for the comment, or any other code that relies on the "BlogEngine" JavaScript object.  There will be an error that "BlogEngine" is undefined.

I'll look into this more tonight. At this point, I'm not sure of the cause. I have only been able to reproduce this in IE.  Firefox and Chrome seem to be unaffected.

I know that in the past there have been issues with IE and script compression, but I thought all those were resolved (also, disabling WebResource.axd compression and HTTP compression doesn't seem to fix this problem, so that's probably not it).  If anyone has any insight on what may be happening here, I'd love to hear it :) 

Hi Filip: I'm not able to reproduce this behavior on IE8. Dumb question, but have you tried deleting cookies?

I've discovered with BE.NET that occasionally I'll get 403 errors when loading pages, which seem to be triggered by something in the BE.NET cookie. It freaked me out a few times until I looked at the URLscan log on the server (server2003, URLScan 3.1) and saw that the cookie was triggering a SQL-injection rule hit on URLscan. Deleting all my cookies removed the behavior.

FWIW, it happens on Chrome and IE8...I'm not sure what's in the cookie that's triggering the URLscan rule though.

Mar 2, 2010 at 7:11 PM
dotnetnoob wrote:

Hi Filip: I'm not able to reproduce this behavior on IE8. Dumb question, but have you tried deleting cookies?

I've reproduced this error on a few systems (on different networks), and on a VM that's never been to the site before

Mar 2, 2010 at 9:54 PM

Filip,

Please confirm the following.

On a fresh browser, not logged in, I cannot reproduce the error.

HOWEVER on the same browser, after logging in (and changing the recaptcha setting to visible for logged in users) I get the error.  So the easy fix appears to not have the reCaptcha when logged in.

Mar 2, 2010 at 10:39 PM
Edited Mar 2, 2010 at 10:51 PM

Clarence: That seems accurate.  I can't believe I didn't notice the authentication requirement before.  Nice find :)

EDIT: It would still be very nice to know why this is happening and why it only affects IE... What would be really nice to know is if this is a bug in the code, or a bug in IE. 

Coordinator
Mar 3, 2010 at 12:03 AM

I've logged into my blog in IE8, and have tried to reproduce this, but cannot.  I don't get any error.

While logged into the site in IE8, I go to a post, hit F5, then type content into the comment multiline box, and click 'Preview'.  I get a normal preview without any errors.

Did I miss a step, or am I just lucky?

Mar 3, 2010 at 12:13 AM

I know I've had this error a couple of times... It's very rare, though.  I would try to see what the conditions are to cause it, but at the moment I'm getting another error:

Unable to cast object of type 'System.String' to type 'System.IO.Stream'.

I've narrowed it down to it being caused by the recaptcha.UpdateLog(comment); line, where it is apparently causing issues in the BindGrid() method of the log viewer.  On opening the log viewer page from the extensions page, I get a full-blown error stack trace - important bit:

Message : Unable to cast object of type 'System.String' to type 'System.IO.Stream'.

Source : App_Web_l3lqh7q1

StackTrace : at admin_Pages_RecaptchaLogViewer.BindGrid()

etc...  probably something I've done as it was working fine for the last few days... although I haven't modified either of the log viewer files :s

Mar 3, 2010 at 12:20 AM
BenAmada wrote:

I've logged into my blog in IE8, and have tried to reproduce this, but cannot.  I don't get any error.

While logged into the site in IE8, I go to a post, hit F5, then type content into the comment multiline box, and click 'Preview'.  I get a normal preview without any errors.

Did I miss a step, or am I just lucky?

 Ben,

You need to make sure that the reCaptcha is visible to authenticated users for this error to come up.

Coordinator
Mar 3, 2010 at 12:21 AM

"You need to make sure that the reCaptcha is visible to authenticated users for this error to come up."

It is visible.

Mar 3, 2010 at 12:24 AM
Edited Mar 3, 2010 at 12:24 AM
CreepinJesus wrote:

I know I've had this error a couple of times... It's very rare, though.  I would try to see what the conditions are to cause it, but at the moment I'm getting another error:

Unable to cast object of type 'System.String' to type 'System.IO.Stream'.

I've narrowed it down to it being caused by the recaptcha.UpdateLog(comment); line, where it is apparently causing issues in the BindGrid() method of the log viewer.  On opening the log viewer page from the extensions page, I get a full-blown error stack trace - important bit:

Message : Unable to cast object of type 'System.String' to type 'System.IO.Stream'.

Source : App_Web_l3lqh7q1

StackTrace : at admin_Pages_RecaptchaLogViewer.BindGrid()

etc...  probably something I've done as it was working fine for the last few days... although I haven't modified either of the log viewer files :s

 CJ: The most likely cause is the following line:

Stream

s = (Stream)BlogService.LoadFromDataStore(BlogEngine.Core.DataStore.ExtensionType.Extension, "RecaptchaLog");

Did you modify the LoadFromDataStore to return a System.String instead of a System.IO.Stream?

 

Mar 3, 2010 at 12:32 AM
BenAmada wrote:

"You need to make sure that the reCaptcha is visible to authenticated users for this error to come up."

It is visible.

That's pretty much what I need to do to experience the error, so I'm not sure.  It could also be related to a lot of other factors like software installed on the server/client, ISP caching, etc. I'll try to spend some time on this tonight - hopefully I get somewhere.

Coordinator
Mar 3, 2010 at 12:46 AM

I finally saw the error!  It happened a couple of times, but then after that it stopped happening.  When I turn on Fiddler, it seems to almost never happen.

BE is returning a 304 Not Modified for js.axd?path=/blog.js.  This is a correct response since the content hasn't changed.  But then IE is I guess not loading the JS content it has cached.  It's interesting that this doesn't occur (according to you all) when not logged in.  When logged in widget.js is also loaded (js.axd?path=/admin/widget.js) -- not sure if this is a factor.  BE is also using the DEFER attribute on these <script> tags.  That could also be a factor.  So, not yet sure the reason for this....

Mar 3, 2010 at 12:55 AM
fstanek wrote:

 CJ: The most likely cause is the following line:

s = (Stream)BlogService.LoadFromDataStore(BlogEngine.Core.DataStore.ExtensionType.Extension, "RecaptchaLog");

 

Did you modify the LoadFromDataStore to return a System.String instead of a System.IO.Stream?

Stream

 Nope - I haven't modified that file at all since downloading it.

I deleted the 2 rows of the be_DataStoreSettings table that stored the reCAPTCHA settings, then reconfigured the reCAPTCHA extension - that fixed the problem... once.  Every time I try to comment again now it doesn't work - and nor does the LogViewer... ?

As I said I'm pretty sure it's something I've changed... somewhere... as it was working fine.  I just need a hand trying to figure out what it could be :p

(If I comment out the line of CommentView.aspx.cs that saves the reCAPTCHA log, it works fine - I can just turn off the log)

Mar 3, 2010 at 1:05 AM
BenAmada wrote:

I finally saw the error!  It happened a couple of times, but then after that it stopped happening.  When I turn on Fiddler, it seems to almost never happen.

BE is returning a 304 Not Modified for js.axd?path=/blog.js.  This is a correct response since the content hasn't changed.  But then IE is I guess not loading the JS content it has cached.  It's interesting that this doesn't occur (according to you all) when not logged in.  When logged in widget.js is also loaded (js.axd?path=/admin/widget.js) -- not sure if this is a factor.  BE is also using the DEFER attribute on these <script> tags.  That could also be a factor.  So, not yet sure the reason for this....

Ben,

On a few occasions, I have seen an error thrown with the widget.js mentioned as the cause as well (same error 'BlogEngine is undefined'). Again, that only happened after hitting F5 on the comment page w/ the reCaptcha. What is rather strange about that is it seems it correctly loaded the widget.js file, but not the blog.js file.

Mar 3, 2010 at 1:32 AM
Edited Mar 3, 2010 at 1:37 AM

The "defer" attribute on the script seems to be the culprit (which I guess fits the symptoms, since only IE supports defer).

Changing the way that "blog.js" loads in BlogBasePage.cs to

AddJavaScriptInclude(Utils.RelativeWebRoot + "blog.js", true, false);

has fixed the problem.

EDIT: Unfortunately, I still don't understand why this only happens when logged in and not in all cases. I guess there must be some extra script that is being called somewhere else that in turn causes this problem? Also, the bad thing about this "fix" is that it requires a recompile of the BlogEngine.Core dll, which means it is not a very good fix for users who simply want the reCaptcha on their log with little hassle.  For now, I'll just recommend that people do not show the reCaptcha to authenticated users.

Mar 3, 2010 at 1:56 AM

Filip,

I believe that is a more than acceptable solution.

Mar 3, 2010 at 8:30 AM

Has anyone been successful at installing the Recaptcha on a site that users the DbBlogProvider instead of the XmlProvider?

Mar 3, 2010 at 9:21 AM
fstanek wrote:

don't understand why this only happens when logged in and not in all cases. I guess there must be some extra script that is being called somewhere else that in turn causes this problem? Also, the bad thing about this "fix" is that it requires a recompile of the BlogEngine.Core dll, which means it is not a very good fix for users who simply want the reCaptcha on their log with little hassle.  For now, I'll just recommend that people do not show the reCaptcha to authenticated users.

On my side, IE8 on Win7, this seems to happen consistently, including on Ben's blog, I just go to a blog entry with comments opened, hit F5, and when hit preview, I get that error. Chrome/Opera seem fine. I did not try the fix yet on my blog, but On Filip's blog I do not get that error anymore.

Mar 3, 2010 at 10:07 AM
fstanek wrote:

Has anyone been successful at installing the Recaptcha on a site that users the DbBlogProvider instead of the XmlProvider?

 Me :) ...apart from that casting problem from earlier :p

Mar 3, 2010 at 11:34 AM
fstanek wrote:

Has anyone been successful at installing the Recaptcha on a site that users the DbBlogProvider instead of the XmlProvider?

Yes, I've been using it with SQL 2005 for the past week.

Mar 3, 2010 at 11:43 AM
adrianf wrote:
fstanek wrote:

don't understand why this only happens when logged in and not in all cases. I guess there must be some extra script that is being called somewhere else that in turn causes this problem? Also, the bad thing about this "fix" is that it requires a recompile of the BlogEngine.Core dll, which means it is not a very good fix for users who simply want the reCaptcha on their log with little hassle.  For now, I'll just recommend that people do not show the reCaptcha to authenticated users.

On my side, IE8 on Win7, this seems to happen consistently, including on Ben's blog, I just go to a blog entry with comments opened, hit F5, and when hit preview, I get that error. Chrome/Opera seem fine. I did not try the fix yet on my blog, but On Filip's blog I do not get that error anymore.

Something Ben said about testing on a post with comments triggered a thought that I've only tried it on a fresh post without any comments. Not logged in, on IE8, when I went to a post with comments and tried to add/preview, I immediately got the "BlogEngine is undefined" error. I disabled reCaptcha, logged out, and on the same page, didn't get an error, then re-enabled reCaptcha, logged out, went back to the same page, and didn't get an error...very hard to reproduce the problem!

Mar 3, 2010 at 3:47 PM

I just went on Ben's blog to the most recent post, did a refresh, and got the error. So it appears it doesn't require the user to be logged in.

I was able to reproduce this error while debugging in VS yesterday. When I received the error, I was able to inspect all of the javascript files that were currently loaded on the page.  All of the files were correctly loaded except for the blog.js file, which was empty.

I've uploaded a recompiled BlogEngine.Core project that removes the "defer" attribute on the script tag on my blog - that's probably why you're not seeing the issue on my blog anymore.

BTW, thanks for the replies on the DbBlogProvider... there was a comment on my blog asking about that, and I just wanted to verify that other people have successfully installed it when not using the XmlProvider.

 

Coordinator
Mar 3, 2010 at 7:08 PM
Edited Mar 3, 2010 at 7:11 PM

Great, ckincincy sent us on a wild goose chase, thinking the JS error only occurred while logged in.  Just kidding :)

Is it still the case that the blog.js file is not loading when hitting F5 in IE, only when the Recaptcha control is on the page?  If so, one possible solution that doesn't involve modifying the BE core would be to have the recaptcha control inject its own <script> tag into the page for js.axd?path=/blog.js (or whatever the path is) ... but without the DEFER attribute.

EDIT:  And if this problem is only in IE, the <script> tag injected by the recaptcha control could be wrapped in IE conditional comments, so it doesn't have any impact on other browsers.

Mar 3, 2010 at 7:52 PM
Edited Mar 3, 2010 at 7:57 PM
BenAmada wrote:

Great, ckincincy sent us on a wild goose chase, thinking the JS error only occurred while logged in.  Just kidding :)

Is it still the case that the blog.js file is not loading when hitting F5 in IE, only when the Recaptcha control is on the page?  If so, one possible solution that doesn't involve modifying the BE core would be to have the recaptcha control inject its own <script> tag into the page for js.axd?path=/blog.js (or whatever the path is) ... but without the DEFER attribute.

EDIT:  And if this problem is only in IE, the <script> tag injected by the recaptcha control could be wrapped in IE conditional comments, so it doesn't have any impact on other browsers.

Ben - since we don't really know the reason why this is happening, it could just be that the reCaptcha simply makes the problem manifest itself more often than it would otherwise. The reCaptcha does make calls to the recaptcha.net server for files, which probably delays the execution of the blog.js script. There are many places on the page where the BlogEngine object is accessed, and none of those scripts have a "defer" flag set. 

With that said, I will try your idea of including the script tag in the reCaptcha control (hopefully that doesn't cause other issues - it shouldn't matter for methods, but we may be re-initializing variables which have already been set by the script on the page).

I really think that the "bug" in this case is the "defer" attribute though. I can see areas where the usage of a "defer" would be beneficial, but using it on a script that defines global objects that are used throughout the page (and in other script files) doesn't really seem appropriate. I think it actually makes more sense to place the <script> tag for 'blog.js' in the <head> section (and remove the 'defer' flag), so that the page is guaranteed to have that script loaded before any of the javascript on the page is executed.

EDIT: Another thing I'll try is putting the "defer" flag on the reCaptcha script. So that way, instead of making the blog.js run faster, we can try to make the reCaptcha scripts run later... that might work...

Coordinator
Mar 3, 2010 at 10:17 PM

It was in BE 1.5 that the blog.js <script> tag was moved down to the bottom of the page, and the DEFER attribute was added.  This was done in response to a test with YSlow and to generally maximize the load speed of the page.  The JS code in BE was changed so functions that are dependent on blog.js (and the BlogEngine namespace) are wrapped in JS functions, and then those functions are called at the end of blog.js file.

You can see at the bottom of blog.js, there are calls made for "registerCommentBox", "registerVariables", "setupBlogEngineCalendar", etc.  This works out pretty well since it ensures these other pieces of JS code don't run until after blog.js has ran (or gets loaded).  Although one part that looks like it could be a problem is how at the bottom of blog.js, when it checks to see if these JS functions exist (registerCommentBox, registerVariables, etc), if they do exist, it calls them via BlogEngine.addLoadEvent().  But if the blog.js script is loading *after* the page has loaded, then these functions won't be called since the page will have already been loaded.  I'm not sure if it's possible for blog.js with the DEFER attribute to run *after* the page has loaded.  Actually,  if you look at this,  scroll down to the place where they show the order of events.  According to that, IE8 is "erratic" and may run DEFER scripts *after* the "Body onLoad".  So this could definitely be a culprit.  If it could be determined whether the body "onload" event has already fired, then the code at the bottom of blog.js could check the body "onload" status, and directly call these JS functions (if the "onload" function had already fired), instead of passing them into BlogEngine.addLoadEvent(), which is meaningless if the page has already loaded.

I don't remember which scripts Recaptcha is using, but since you're modifying blog.js already, you could also consider calling any JS load code you have at the bottom of blog.js -- like how the other JS functions are called.  That is, if you have any JS code that is dependent on BlogEngine.

Mar 3, 2010 at 10:34 PM

Ben - thanks for the explanation of what is supposed to happen.

The reCaptcha isn't really dependent on anything in 'blog.js' when the page loads (of course, code in the BlogEngine.addComment is needed later on).

I'll run a test w/ the 'onLoad' event tonight. Perhaps the loading of the reCaptcha is causing this not to load in time for the onLoad event to be registered (or maybe the reCaptcha changes the onLoad event? I've never checked)

Coordinator
Mar 3, 2010 at 10:52 PM

Yeah, you might want to consider injecting the recaptcha script (recaptchaAjaxScript) into the page at the bottom of blog.js -- instead of injecting the script tag up in the <head> section.  This can be done via document.createElement("script"), like shown in that page I referenced before.  It would be interesting to see if this made a difference.

Mar 4, 2010 at 4:23 AM
Edited Mar 4, 2010 at 4:25 AM

Well, I think I fixed the issue. I've refreshed like 100+ times now and I can't get the error to come up again (and I made sure to put the "defer" attribute back in BlogBasePage.cs).

There were really 2 changes that were put in. The first was to defer the recaptcha ajax script. The second was to show the reCaptcha on page load. I incremented the version to 0.95 and put up a new file.  If you already have the 0.94 version, you'll only need the Recaptcha.cs file from the 0.95 zip.

Hopefully the issue really is fixed and I wasn't just unlucky in refreshing. I still don't understand exactly what was happening, and that's kind of frustrating. All I know is that when the error did come up, the 'blog.js' file never loaded. I put an alert in that file at the bottom, and it never got called when the error happened.

link: http://www.bloodforge.com/post/BlogengineNET-reCaptcha-093-Installation-Instructions.aspx

P.S. I also received a record high 6 spam comments today since the reCaptcha was implemented... they did solve the reCaptcha though

 

Mar 5, 2010 at 10:56 AM

Hi fstanek - just wondering, have you made any progress on reCAPTCHA for the contact page? :)

Mar 5, 2010 at 2:51 PM
fstanek wrote:

Well, I think I fixed the issue. I've refreshed like 100+ times now and I can't get the error to come up again (and I made sure to put the "defer" attribute back in BlogBasePage.cs).

There were really 2 changes that were put in. The first was to defer the recaptcha ajax script. The second was to show the reCaptcha on page load. I incremented the version to 0.95 and put up a new file.  If you already have the 0.94 version, you'll only need the Recaptcha.cs file from the 0.95 zip.

Hopefully the issue really is fixed and I wasn't just unlucky in refreshing. I still don't understand exactly what was happening, and that's kind of frustrating. All I know is that when the error did come up, the 'blog.js' file never loaded. I put an alert in that file at the bottom, and it never got called when the error happened.

link: http://www.bloodforge.com/post/BlogengineNET-reCaptcha-093-Installation-Instructions.aspx

P.S. I also received a record high 6 spam comments today since the reCaptcha was implemented... they did solve the reCaptcha though

 

Hi Filip: If I want to move from 0.91 to 0.95, can I just replace all the existing files on currently active blogs, or do I need to recompile the BE1.6 source? Also, is the BlogEngine.js modified since 0.91?

Mar 6, 2010 at 8:12 PM

CreepinJesus: I haven't gotten to the contact page yet.

dotnetnoob: You don't have to recompile the BlogEngine.Core project. The current solution seems to work with the "DEFER" attribute still in place, so hopefully there will not be need for a recompilation. Also, I don't think the "blog.js" file has changed since 0.91.  The biggest changes were in Recaptcha.cs, and there were a couple of new files added into the admin/Comments directory.

Mar 7, 2010 at 6:22 AM

CreepinJesus: I've updated the contact page files to use the reCaptcha. A zip of what I did is available here.

Keep in mind that these are just the contact.aspx and contact.aspx.cs files that came with BE.NET 1.6, except with the reCaptcha implemented in them.  If you have done any customizations to these files, you'll need to merge the changes. 

Also, the zip above does not contain the reCaptcha control - it assumes you have the reCaptcha control already installed for your posts. As always, let me know if you notice any issues.

Mar 7, 2010 at 9:17 AM

fstanek - Thanks very much!  Hopefully you've saved my inbox from spam for... however long recaptcha lasts against the spammers :p

It's working fine :)

Mar 7, 2010 at 6:25 PM

fstanek - Installed your reCAPTCHA solution yesterday.  Thank you for all your hard work.  The installation was simple, your instructions were complete and easy to follow; and, it seems to be working very well.  Thanks again.  Your work is greatly appreciated.

Mar 8, 2010 at 8:04 AM

I would really like to add this to my site - the instructions seem fairly clear, but I'm not a developer and I'm afraid I'd spend way too much time trying to get all the details worked out.  If someone is willing to help me with this, I could pay you for your time via PayPal ...

You can reach me at TheLunatic(at)HalfBakedLunatic.com

 

Apr 27, 2010 at 5:41 PM

Unable to cast object of type 'System.String' to type 'System.IO.Stream'.   

 

So is there a solution to this issue? I installed this update and seem to consistantly get this error using Firefox

 

Thanks in advance

May 19, 2010 at 4:22 PM

@dumbguy5689
You can find the solution in my post on this thread:
http://blogengine.codeplex.com/Thread/View.aspx?ThreadId=208271

Jun 9, 2010 at 4:45 AM
DaveWhiteNet wrote:

Filip, with the latest update I'm seeing an error on my blog.  The error is shown below.  This occurs on BE build 1.6.0.0 

Compilation Error

Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.

Compiler Error Message: CS0535: 'Controls.RecaptchaControl' does not implement interface member 'System.Web.UI.IValidator.IsValid.set'

Source Error:

 
Line 130:    }
Line 131:
Line 132:    public class RecaptchaControl : WebControl, IValidator
Line 133:    {
Line 134:


Source File: g:\inetpub\wwwroot\blog\App_Code\Controls\Recaptcha.cs    Line: 132

I have been pulling my hair out. I have developed a site and built it on localhost. blog engine 1.6.1.0 running sql server 2005. I move to production and get an oops error saying its a 404. Turn off custom errors and turn on debugging and then get this error:

Object reference not set to an instance of an object.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.

Source Error: 

Line 99:             {
Line 100:                ExtensionSettings Settings = ExtensionManager.GetSettings("Recaptcha");
Line 101:                return Convert.ToInt32(Settings.GetSingleValue("MaxLogEntries"));
Line 102:            }
Line 103:        }


Source File: c:\inetpub\wwwroot\MoodyMinds.com\MoodyBlog\App_Code\Extensions\Recaptcha\RecaptchaControl.cs    Line: 101 

So I follow the instructions at http://www.bloodforge.com/post/BlogengineNET-reCaptcha-093-Installation-Instructions.aspx and start getting this error

Server Error in '/amoodymind' Application.

Compilation Error

Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately. 

Compiler Error Message: CS0101: The namespace 'Controls' already contains a definition for 'RecaptchaControl'

Source Error:

 
Line 34: namespace Controls
Line 35: {
Line 36:     public class RecaptchaControl : WebControl, IValidator
Line 37:     {
Line 38: 


Source File: c:\inetpub\wwwroot\MoodyMinds.com\MoodyBlog\App_Code\Extensions\Recaptcha\RecaptchaControl.cs    Line: 36 

So then I removed the recode from the storesettings table. No change. VERY frustrated. please someone have the answer.

 

Thanks

Matt

Coordinator
Jun 9, 2010 at 5:07 AM

If you're working with BE 1.6.1, the same exact Recaptcha control that Filip created here is already integrated into BE 1.6.1.

You're getting this error because BE already has a "RecatpchaControl" (Filip's control).  When you add the one from Filip's site, you now have two.

Recaptcha can be turned on and configured by going to the Extensions tab in the control panel, and make sure Recaptcha is enabled.  If you click the 'Edit' button for Recaptcha (same row, right side), then you can configure some additional options -- such as whether to "show captcha for authenticated users".

Jun 9, 2010 at 5:13 AM
Edited Jun 9, 2010 at 5:16 AM

The middle error that I showed actually happened before I did any additional install. This started as a plane jane install with a new theme. It worked fine on my localhost. The only difference is that I run ii7 locally and ii6 on the production server. (i know its complicated) I even tried to apply the original sql version of the web.config. changed my connection string and I get the same thing. If I leave custom errors on the blog shows home page, category lists month lists, but when you click on a specific entry that when the error happens.

Coordinator
Jun 9, 2010 at 9:16 AM

Trying to follow, but which of the errors are you actually getting now?

If you at one time tried installing the Recaptcha control on top of 1.6.1, it's possible there are some lingering/conflicting settings.  If possible, I would try a new installation.  Also when you move files to productions, are you just FTP'ing or Copying the files ... or are you using the Publish feature in VS?  The Publish feature has been known to cause issues.

Sorry, general answers here, but those errors don't look like anything directly related to differences in IIS6 / IIS7, and it looks like something may have gone wrong with the install -- or deployment of files to production.

Jun 9, 2010 at 3:53 PM
Edited Jun 9, 2010 at 3:54 PM

Sorry about the confusion. It was a long day yesterday. Here is a clear list of what I have done.

  1. Installed BE on localhost on iis7
  2. Made additions to web config to make it work on ii7
  3. Blog ran great
  4. moved to production site
  5. BE displayed home page, month list, category list with no issue
  6. Click on an entry and I got a friendly error page
  7. changed web config to error details and got  Line 101: return Convert.ToInt32(Settings.GetSingleValue("MaxLogEntries")); error
  8. Backed up the site
  9. installed the Recaptcha according to Filip's site
  10. Then I got Compiler Error Message: CS0101: The namespace 'Controls' already contains a definition for 'RecaptchaControl' error
  11. Restored my original copy
  12. Got the error described in #7
  13. Went through the code and commented out the recaptcha code and removed the files and the site worked great except for an error when I tried to view admin configuration for comments
  14. Tried Filip's install from here
  15. Right back to error described in #7

Hope that clears things up.  Thank you for your help with this. My marketing plans are frozen until this is resolved.

 

Jun 9, 2010 at 6:02 PM
Problem resolved. I went back and downloaded a fresh BE 1.6 then applied my theme and pointed to db and it works fine.