Cakephp 2.0 ReCaptcha plugin always wrong - cakephp

I've taken a reCaptcha plugin from this guy
(github link of the plugin)
I've entered the following code form in my view:
[form creation]
[table]
[inputs]
[/table]
echo $this->Recaptcha->show(array('theme' => 'white'));
echo $this->Recaptcha->error();
[/form]
I've followed the steps suggested, and the reCaptcha window appears properly, but no matter what I enter in the captcha, it never gets verified and I always receive the 'message' field of beforeValidate (I've set it to "You've entered a wrong message" etc).
I'm not even sure how to debug it to see at which point it fails. Even if I just replace all the code in checkRecaptcha function with "return true" to try and skip the validation with the keys and just see if the rule itself is correct, it still remains the same, and I'm generally not getting any of the specific incorrect-captcha-sol messages that I read around.
Am I correct to assume that the only code I need inside my controller function (assuming I've already included the component and helper in the controller) is Configure::load('Recaptcha.key'); and no further manual validation checks?
(unfortunately I can't link you my whole project due to rights)

I had a similar issue. Try removing the 2 response and challenge field lines in the component and overwrite them with these:
$controller->$modelClass->set('recaptcha_response_field',
$controller->request->data['recaptcha_response_field']);
$controller->$modelClass->set('recaptcha_challenge_field',
$controller->request->data['recaptcha_challenge_field']);

Related

Umbraco cms AngularJS Regular Expression Keep appearing

Umbraco uses angularJS as based library and backoffice totally developed on it. The reason telling first is to tell that I have a field on which URL regular expression applied. If someone entered invalid url like below image
it shows error as need.
But if a user try to remove whole text by selecting it and removing at once. It still keep appearing the error like this
However, if a user erase text one by one like this
then the validation error removed and user need to click on button to see error again.
I would to know how screen 3 state can be achievable when user remove all text together? Its really annoying behavior for a user to remove text character one by one to refresh the state of the field. Screen 3 state should be applied on screen 2.
Can anybody tell me how it can fix or achievable? Right now, it seems like a default behavior.
Looking forward to hear from you guys. Suggestions will be much appreciatable.
Regards o
I've looked into this issue. This seems to be a product bug.
When you remove whole text at once, newValue is an empty string and the code responsible for resetting error messages doesn't run. If you have access to the umbraco code, you can easily fix it by removing highlighted check:

DNN - Custom Registration Form Field Does Not Validate for Required After Upgrade

I am upgrading a DNN site from version 5.06.00 to version 7.03.02. I followed the recommended upgrade path, and worked out all of the kinks with the custom modules. The registration form has a custom boolean field, which is required to be set to TRUE. This used to validate correctly pre-upgrade, but now it is not post-upgrade. The user can submit the form without selecting the "TRUE" radio button.
The custom field is displaying properly. The required asterisk is also displaying. The DOM even has an error message element with the correct custom required message:
<span class='dnnFormMessage dnnFormError'>[required message]</span>
However, this field is set to "display:none" by default and never displays as inline like the other error message elements.
I am not a DNN expert and I did not create this site. I am upgrading it for a client and don't know a ton about how these custom fields all work. I see the custom field enabled in Admin > Site Settings > User Account Settings > Profile Settings. I also see a file called "Profile.ascx.Portal-0.resx" that contains the custom field's main text, help text, and required text. It lives in DesktopModules\Admin\Security\App_LocalResources. I don't know what else I would need to configure or check that would be different from version 5.6 to 7.3.
Thanks for your help!
It seems like you've checked all of the requirements, but you didn't mention wheter or not the checkbox to require a valid profile for registration is checked. Is it?
Can you verify that the custom field is marked as Required?
It may be worth your while to upgrade to the current version of DNN 7, which is 7.04.02.
I'd recommend making a full site backup before doing the upgrade as that is always the right way to proceed.
The .resx file aren't going to affect the functionality, just the texts that are displayed.
I assume that you are doing much of this work on a test copy of the production site. That being the case, you might want to add another custom boolean field, make it required and see if that one works.
This isn't the ideal answer, but since I can't figure out what's wrong DNN-wise, I'm just writing some custom jQuery to find the checked radio button span element, then show/hide that error message based on that. If there is more than one thing wrong with the form, it will only show this message. Then if you corrected that boolean, it would show all other messages. It's not great, but at this point it's better than nothing.
$(".dnnPrimaryAction").click(function (e) {
var $checkedRadioSpan = $(".dnnRadiobutton-checked");
var $checkedRadioInput = $checkedRadioSpan.prev();
var $errorMessage = $checkedRadioInput.siblings(".dnnFormError");
if($checkedRadioInput.val() === "False") {
e.preventDefault();
$errorMessage.show();
}
else {
$errorMessage.hide();
// continue on with other validation
}
});
I had quite the same problem. It seems that the error message is not displayed for the first form item, as there is not enough place for it.
After adding a header (h2) above the form, it worked fine.
See Validator errormessage is not displayed in the DNN Community forums for more information.

Usually the form is POST, but in a single instance it is GET

I do a standard pattern in my application - a link to /controller/delete/object_id, then a post form to "confirm", a check if $this->request->is('post') and if true - the controller deletes the object from database.
What is weird is that for a single, particular object_id, my browser (Firefox) forces the form to be a GET one. With any other object_id everything is ok, but with this particular one, despite all declarations within form tag and etc. brower generates a GET request.
Do you have any clue what this might be?! I even tried to use brower's private mode, because I thought it can be some garbage in browser cache, but the bug is still here.
I managed to bypass this problem:
define a specific action in form->create, pointing to your controller' method
add a hidden field with object_id
add some additional code in the controller method to get object_id from $this->request->data, because a hidden post field is not passed as an argument to method, as it is with GET method.
This way, to some unknown reason, it just works. Anyway, I still feel I'm doing something wrong. It's not as "clean" as I would expect.

CakePHP Routing Alias, no prefix

I have a dashboard with a series of widgets. Per specification, the widgets need to be buried under a /widgets/ directory.
So I have added the following to my routes.php
Router::connect('/widget/:controller/:action/*', array());
But I seem to be running into trouble on widget/links/ and widget/links/view/1
I am new to CakePHP, but this doesn't seem all that impressive. I have yet to find anything in the Book or by search. So any help is appreciated.
Thanks.
Well...at the risk of stating the obvious...your route starts with /widget/, but you indicate that you're trying to access it via a plural URI (/widgets/). That's a problem. If that's just a typo, it would help to know what error you're seeing when you "run into trouble".
UPDATE:
Yes that was a typo. I corrected it. The error that appears for widget/links/ is: Error: WidgetController could not be found. It appears my index/default route is the main problem.
Given that information, it appears that CakePHP thinks that widget is your controller. Cake processes routes top down and finds the first one that matches. Ensure that you don't have a route above this one that looks something like /:controller/... or any other route above this one that starts with a variable.

CakePHP IBM Tutorial: Incorrect API doc for Model::validate()?

Okay, this is driving me nuts. I’m working through the IBM CakePHP Tutorial, and in the first part, I’m at the section where the author is introducing validation rules for form input:
www.ibm.com/developerworks/opensource/tutorials/os-php-cake1/section5.html#N107E3
For the life of me, I can’t figure out what’s happening in this line of code:
$this->invalidate('username_unique');
According to the CakePHP documentation, the Model::invalidate() method takes as its first parameter a string that specifiies “The name of the field to invalidate”. How is “username_unique” the name of the field to validate? Looks to me like it should be just plain old “username”. But incredibly enough, the author’s code works, and mine doesn’t when I change “username_unique” to “username” (or even “User.username”), so I’m thinking there might be a serious flaw in the documentation (or very possibly, with me).
[FWIW, I can see that the CakePHP 1.25 provides a better means of doing validation, but I still find it troubling that what seems to be a well-documented method doesn't seem to be doing what it advertises, and I want to understand why the tutorial code works.]
Can anyone shed any light on this?
The "magic" is actually in the $form in this case.
When calling $this->invalidate('username_unique'), Cake takes a note that the field username_unique is invalid. The fact that this field does not actually exist is irrelevant.
Now, take another look at the actual $form field (slightly reformatted):
echo $form->input('username', array(
'after' => $form->error('username_unique', 'The username is taken. Please try again.')
));
It's outputting a normal form field, but "manually" places an error() output after the form field. $form->error('username_unique', $message) means "if there's an error for the field username_unique, output the message $message". So you're actually marking an imaginary field as invalid and are manually outputting an error message for this imaginary field.
And actually, that's a load of outdated cr*p you should forget right away. There's a built-in syntax for multiple validation rules per field, so you can test for character length and uniqueness at the same time and even get different error messages for each error type. There's even a built-in isUnique rule, so you won't even have to code a manual uniqueness test.

Resources