You are viewing this forum as a guest. Login to an existing account, or create a new account, to reply to topics and to create new topics.
Pages: 1
I still cannot resolve this problem even after several months of rewriting sections of the code.
In theory all that is required is an addition in , eg:
: gbu0.contact.verify
: gbu0.contact
: gbu0
: 1
: CAPTCHA
...and this works for the usual login page, the contact page, the email a friend pages, and the backend login page, too (by creating a field for in addition to ) ...but not the login form in the checkout namespace (the display of which is controlled through , as opposed to ).
I cannot find any reason for why the CAPTCHA process refuses to display in that one namespace and, yes, I have tried using files from a clean install, too.
Further to the above, the debug process reports no issues in presenting the form but, then, it does not show any instance or attempt to present CAPTCHA in the form, either...
KHXC_Display::include_file: Started file: /apps/gbu0/GBU/includes/coacctlink.php KHXC_Display::load_object: Cached object returned: KHXC_App Class: KHXC_App KHXC_Display::load_object: Cached object returned: KHXC_Form Class: KHXC_Form KHXC_Form::quick_form: Created a quick form array for application 'gbu0' to post to namespace 'login_proc'. KHXC_Display::include_file: Started file: /apps/gbu0/GBU/includes/form_quickh.php KHXC_Display::include_file: Completed file: /apps/gbu0/GBU/includes/form_quickh.php KHXC_Display::xhtml_quickform_header: Generated quick form header for form id 'gbu0--login'. KHXC_Display::include_file: Completed file: /apps/gbu0/GBU/includes/coacctlink.php GBU_Checkout::coerrneeduser: Presented account forms.
I have also tried entering the following from , which looks promising but which also fails to generate the image:
if (($this->globals('khxc_form.reqnotcomp')) && ($required)) { $cssstyle .= '_rnc'; } list($hash, $crypted) = split('\-\-', $displayvalue, 2); $image = 'media/khxc/captcha/' . $this->xhtml_encode($hash) . '.png'; print '<fieldset>'; print '<legend class="strong"><label for="' . $id . '">'; print $name; if ($required) {print '*';}; print '</label></legend>'; if ($description) {print $description;}; print '<p><img src="' . $image . '" width="150" height="50" alt="Image Verification" /></p>'; print '<p style="text-align: justify; color: black;">Enter the text, which is case sensitive, from the image above into the box displayed below, or refresh the page if you cannot make out the text.</p>'; print '<p class="hidden"><input type="hidden" name="' . $id . '--info" id="<?php print $id; ?>--info" value="' . $this->xhtml_encode($crypted) . '" /></p>'; print '<input class="' . $cssstyle . '" type="text" name="' . $id . '" id="' . $id . '" value="" size="' . $size . '"'; if ($maxlength) {print 'maxlength="' . $maxlength . '" ';} print '/> </fieldset>';
Trying to force the issue with code straight from also fails:
// +-- // | Display the form. // +-- $def_form = $this->KHXC_Form->def_form(array('app' => $this->app, 'form' => $this->app . '.login')); if ($this->IsError($def_form)) {return $def_form;} $spec_form = $this->KHXC_Form->spec_form($def_form); if ($this->IsError($spec_form)) {return $spec_form;} $result = $this->KHXC_Form->print_form($spec_form); if ($this->IsError($result)) {return $result;} // +-- // | Display links. // +-- $this->KHXC_Display->include_file($this->app,'login.php'); // +-- // | Return true. // +-- return 1;
There is also a further problem with this, in that having the login.verify database field entry as required (which, obviously, is necessary) prevents the login process from working even if I don't have it coded out as I do at the moment in the checkout namespace. What happens is that if I don't have the username and password coded out, the form still expects there to be a correct CAPTCHA field entry present ...so the problem is almost certainly with login_disp not being processed as it would be in the normal login namespace.
Can anyone help with this, please?
Last edited by Design_Wholesale (01-01-2011 10:27:20)
Offline
The code in is definitely flawed. - I have now tried several other tests using code from elsewhere in the store, even copying the entire login process code into the file, and there is absolutely no way that CAPTCHA will work in the checkout namespace for returning customers and there is no way to simply allow returning customers to just enter their password and username, either, if you are using CAPTCHA elsewhere in the site unless you are prepared to turn off the required flag in the database (which would entirely defeat the purpose of using it in the first place).
Google's Re-Captcha in place of the buggy scripts is also not an option. - The problems that cripple the CAPTCHA functionality also very effectively kill the use of Re-Captcha, too. It would have been nice, though, if there was a warning in the wiki or somewhere on the forum that the form process in was screwed. - It could have saved me (and doubtless others) allot of wasted time and effort.
Offline
The following is a modified redirect that works:
<?php $app = $this->globals('khxc_display.app'); $eol = $this->globals('khxc.eol'); $link_guestco = $this->link_namespace($app,'guestco',array('coactive' => 1)); $link_createaccount = $this->link_namespace($app,'createaccount',array('coactive' => 1)); $link_sendpass = $this->link_namespace($app,'sendpass',array()); $formid = $app . '--login'; $email = $this->globals('khxc_cgi.' . $app . '--login--email'); $password = $this->globals('khxc_cgi.' . $app . '--login--password'); $allowguest = $this->globals('khxc_settings.' . $app . '.allowguestco'); $link_contact = $this->link_namespace($app,'contact',array()); $site_name = $this->xhtml_encode($this->globals('khxc_settings.' . $app . '.site_name')); if (empty($email)) {$email = $this->globals('khxc_session.email');} // print '<p style="text-align: justify; line-height: 150%; color: black;">Placing an order is a quick and easy process. Options for processing your // order and completing the checkout process are given below.</p>' . $eol . $eol; print '<p class="khxc_ultablesp"> </p>' . $eol . $eol; print '<p class="khxc_storehead">New Customers</p>' . $eol . $eol; if (empty($allowguest)) { print '<p style="text-align: justify; line-height: 150%; color: black;">If you are a new customer, click the <strong>Create New Account</strong> button below to continue. Once the account has been created, your customer details and order information will be stored securely to enable the online review and faster processing of any future orders placed through your account.</p>' . $eol . $eol; print '<p class="khxc_ultablesp"> </p>' . $eol . $eol; print '<form action="' . $link_createaccount . '" id="CREATEACCOUNT" method="post">'; print '<p class="khxc_quickform"><input class="khxc_quickbutton" type="submit" name="CREATEACCOUNT" '; print 'id="CREATEACCOUNT--SUBMIT" value="Create New Account" /></p></form>' . $eol; } else { print '<p style="text-align: justify; line-height: 150%; color: black;">If you are a new customer, you can either click the <strong>Create New Account</strong> button below to create an account, or the <strong>Guest Checkout</strong> button to checkout as a guest.</p>'; print '<p style="text-align: justify; line-height: 150%; color: black;">If you choose to create an account, your customer details and order information will be stored securely to enable the online review and faster processing of any future orders placed through your account. </p>' . $eol . $eol; print '<p class="khxc_ultablesp"> </p>' . $eol . $eol; print '<table><tr>' . $eol; print '<td><form action="' . $link_createaccount . '" id="CREATEACCOUNT" method="post">'; print '<p class="khxc_quickform"><input class="khxc_quickbutton" type="submit" name="CREATEACCOUNT" '; print 'id="CREATEACCOUNT--SUBMIT" value="Create New Account" /></p></form></td>' . $eol; print '<td><form action="' . $link_guestco . '" id="GUESTCO" method="post">'; print '<p class="khxc_quickform"><input class="khxc_quickbutton_guest" type="submit" name="GUESTCO" '; print 'id="GUESTCO--SUBMIT" value="Guest Checkout" /></p></form></td>' . $eol; print '<td><form action="' . $this->link_namespace($app,'login',array()) . '" id="RETURNING" method="post">'; print '<p class="khxc_quickform"><input class="khxc_quickbutton" type="submit" name="RETURNING" '; print 'id="RETURNING--SUBMIT" value="Sign Into Existing Account" /></p></form></td>' . $eol; print '</tr></table>' . $eol; } // End of if statement. ?>
It completely replaces the existing contents of (be careful: this is from a version of CCP) with a nice tidy 3 button display. - Anyone signing into an account still goes wherever they would normally be redirected to, so the only difference is that they have an extra step in order to sign into their account. - Not perfect, maybe, but at least it means that their login can be on the usual, CAPTCHA protected, login page as opposed to a page that cannot be CAPTCHA protected.
Last edited by Design_Wholesale (01-02-2011 10:09:03)
Offline
I'm curious, why would you want to enable Captcha for logging in to an existing account?
Offline
I have CAPTCHA enabled on all the login pages (the exception being the one in the checkout namespace) to make it awkward to brute force the login process (I also have this augmented with some additional protection on the server side of things).
Without CAPTCHA enabled on one of those login pages, eg: the one in checkout namespace area, I would be completely wasting my time using it at all because it would leave one page where the login process could be brute forced quickly and easily without any need whatsoever to work around a CAPTCHA process. It's that simple ...and has nothing to do with enabling CAPTCHA for an already logged-in user. - Obviously someone who is already logged-in is not going to need to log in again in order to do whatever it is they need to do on the site.
Last edited by Design_Wholesale (01-02-2011 15:50:35)
Offline
Thanks for the explanation. I must admit that I find it curious that you're using that much "protection" for something that nobody could really gain anything from if they were able to brute force a log in.
Offline
...and what if someone brute forced credentials for myself? - There is, after all, no way to prevent superuser log-in on the frontend of things ...and it would only take even a relatively inexperienced script kiddie a matter of minutes to work out where the backend script is. - I don't really see that as something that nobody could really gain anything from when they could obliterate your store or do any number of other horrible things to it after managing to gain access to the backend.
Offline
For a well protected site move admin.php into a separate directory protected with .htaccess and .htpasswd ... nothing says it has to be in the public directory and none of the installations I've done for my customers have it in a publicly accessible location.
Offline
Thanks, but that does seem a little daft when the cart software already has the potential to provide protection without the necessity of relying on password protected directories.
Would it not be simpler, therefore, for the software to have security fully coded into it (like many other proprietary solutions do from the box)? For example, a CAPTCHA with x number login failure within y amount of time for x duration of time would be more than sufficient to deal with most attempts to compromise the backend of a customer's webstore.
Last edited by Design_Wholesale (01-02-2011 17:37:00)
Offline
Design_Wholesale wrote:
Thanks, but that does seem a little daft when the cart software already has the potential to provide protection without the necessity of relying on password protected directories.
Not at all. The security provided by Apache far exceeds just about anything you're going to be able to implement in higher levels of software.
Design_Wholesale wrote:
Would it not be simpler, therefore, for the software to have security fully coded into it (like many other proprietary solutions do from the box)? For example, a CAPTCHA with x number login failure within y amount of time for x duration of time would be more than sufficient to deal with most attempts to compromise the backend of a customer's webstore.
I don't believe it would nor should be. If I may use my bank and credit card sites as examples, neither one of them require a Captcha for logging in and I have far more to lose if one of them is compromised. If someone gets my admin credentials for a CCP site the most they'll be able to do is disrupt the site but only until I detect the problem (which shouldn't be long at all if decent monitoring is in place). After that a restoration should fix things up.
We can agree to disagree on this and that's fine I was just trying to understand why you were investing so much to protect so little (in the grand scheme of things).
Offline
Okay, fair enough, - I agree to disagree , - but for anyone using Apache password protected directories, you will need to enable several Apache modules (a2enmod for Linux shell) and use the MD5 authentication method, as opposed to basic, if possible.
Last edited by Design_Wholesale (01-05-2011 16:08:04)
Offline
Pages: 1