Anti-hacker Account Mods, Secure your account pages

[Mort-lemur]

Hi Sam,

 

Finished the install and works great.

 

One possible suggestion from me for any future update.

 

On the Create Account Page, there is a title "returning Customer" with boxes where the customer can login.

 

Underneath this box, I think it needs a title "New Customer" or whatever just so there is no confusion whatever in the customers mind where he should be filling in boxes.

 

Thanks

[sarafina]

Does this have purchase without account? I'm sure its a silly question but I remember hearing one contrib had it and wonder if its this one.

[spooks]

Does this have purchase without account? I'm sure its a silly question but I remember hearing one contrib had it and wonder if its this one.

 

 

Yes, it has the form suggested by ClubOsc and provides a more secure form of PWA (Purchase Without Account), and makes the personal details input a seamless part of the checkout, removing any password input requirement in that mode.

[Mort-lemur]

Hi again Sam,

 

Been doing some testing and either I have made an error in the install or there may be a slight bug....

 

If a customer comes to the shop and buys an item using the PWA feature (ie does not save his data), then returns some weeks or months down the line and tries to buy again, his email is rejected as a duplicate and tells him to log in or use another email.

 

As he did not want to register in the first place he will probably have deleted the email he received with a password, so in effect can not buy from the store with that email address.

 

Thanks

[spooks]

Been doing some testing and either I have made an error in the install or there may be a slight bug....

 

If a customer comes to the shop and buys an item using the PWA feature (ie does not save his data), then returns some weeks or months down the line and tries to buy again, his email is rejected as a duplicate and tells him to log in or use another email.

 

As he did not want to register in the first place he will probably have deleted the email he received with a password, so in effect can not buy from the store with that email address.

 

Thanks

 

Hi, yes, I would say not so much a bug as a possible senario.

 

There are a number of solutions

 

1. You need the e-mail whilst the order is in progress but add a note for admin to change/delete the email following completion.

2. Add a note for the customer after email is rejected as a duplicate to say we still have details related to his e-mail & he can use the password forgotten feature to get a password to his profile/account. (I've seen a number of sites do that)

3. Add a new dbase field to store the 'non save' status of the account, which is checked in this situation & the old e-mail deleted to avoid the conflict.

 

 

Let me know your ideas.

[Mort-lemur]

Hi, yes, I would say not so much a bug as a possible senario.

 

There are a number of solutions

 

1. You need the e-mail whilst the order is in progress but add a note for admin to change/delete the email following completion.

2. Add a note for the customer after email is rejected as a duplicate to say we still have details related to his e-mail & he can use the password forgotten feature to get a password to his profile/account. (I've seen a number of sites do that)

3. Add a new dbase field to store the 'non save' status of the account, which is checked in this situation & the old e-mail deleted to avoid the conflict.

 

Ok Thanks,

 

Option 1 is out, because from admin I dont know if they created a "real" account or not.

Option 3 is a non-starter to me - I wouldnt have a clue where to start.

 

So I think that option 2 is the way for me to go - a nice simple edit of the error message.

 

........unless you know better of course ?

 

Thanks - love the contribution by the way. :D

[Mort-lemur]

Hmmmmm maybe not so simples...

 

Edited the error message fine, instructing the customer to use the "password Forgotton" link....but by the time the error message is displayed the page has changed and that link is not there....

 

I think as well as the edit to the error message it needs a link to show, if there is an error, offering password forgotton options.

 

Thanks

Edited April 10, 2010 by Mort-lemur

[spooks]

 

Edited the error message fine, instructing the customer to use the "password Forgotton" link....but by the time the error message is displayed the page has changed and that link is not there....

 

 

 

OK, easy fix, in modules/validate_name_fields.php

 

after:

if ($check_email['total'] > 0) {
 	   $error = true;

add:

 $mail_exist = true;

 

then in create_account.php

 

after:

 

$short_check = false;

add:

$mail_exist = false;

 

and relpace (251):

 

  <?php } elseif (!$process) { ?>

 

with:

 

  <?php } elseif (!$process || $mail_exist) { ?>

[Ken44]

Hi Sam

 

I was about to post the same concerns when Heather posted.

The code changes work great

Thanks

 

Regards

 

Ken

[Mort-lemur]

Hi Sam,

 

Thanks for the code - works great.

 

One (hopefully final) question from me, and apologies for this one:

 

When a customer visits and uses the PWA function, he is choosing not to register, and to not have his details saved for his next visit. However, his details are saved (against his wishes?) and he is remembered.

 

How do we stand on this legally with data protection etc? could it be seen that we are saving his data covertly ?

 

Sorry for the question.

 

Thanks

[spooks]

When a customer visits and uses the PWA function, he is choosing not to register, and to not have his details saved for his next visit. However, his details are saved (against his wishes?) and he is remembered.

 

How do we stand on this legally with data protection etc? could it be seen that we are saving his data covertly ?

 

 

 

I'm no lawyer, so take my advise accordingly, ie ask a lawyer if you need to be sure.

 

The data you are keeping is that contact information you require to process the order, including any required warantee information, therefore it is reasonable that you would retain such info.

 

Obviously you must keep the info secure in accordance with data protection.

 

 

 

I would advise adding a relevent entry to your sites T & C for this.

 

I will be adding a new field in the next version for an option of 'Must agree to T & C'

 

 

 

PS

I would also point out the Google checkout method: your visitor does not set up a account at your site, but gives GC his contact info, but then GC sets up a account for him at your site providing address details etc GC then sends the visitor login details for his account at your site.

Edited April 11, 2010 by spooks

[Mort-lemur]

Hi again,

 

Installed on my live site now and it is working lovely - sanitises all code etc.

 

Maybe I missed a line in the install, but when I use the Contact Us form and then go to the contact Us Success page - the heading at the top of the success page is the same as on the Contact Us Form. ie.

Contact Us on 000 - 111 - 000 or use the form below

 

Have I made an install error ?

 

thanks

[spooks]

when I use the Contact Us form and then go to the contact Us Success page - the heading at the top of the success page is the same as on the Contact Us Form. ie. Contact Us on 000 - 111 - 000 or use the form below

 

Have I made an install error ?

 

 

 

Its what's in your language file!!

 

The define used for both is: HEADING_TITLE which is set to 'Contact Us' by default, you have altered it to smthg else!!

 

 

I suggest you place your 'Contact Us on 000 - 111 - 000 or use the form below' in a more appropriate place, like within the $mytext section.

[Mort-lemur]

Thanks Sam,

 

I suppose I should have thought of that myself - getting there, all be it slowly .....

 

Thanks for your help and patience :D

[pilvinen]

I'm having trouble with the clean_post function in includes/functions/account_secure.php.

 

It removes all the "ö" but _only_ lower case "ö" is affected. "ÅÄääÖ" are all fine.

 

Any suggestions what I could do?

[spooks]

I'm having trouble with the clean_post function in includes/functions/account_secure.php.

 

It removes all the "ö" but _only_ lower case "ö" is affected. "ÅÄääÖ" are all fine.

 

Any suggestions what I could do?

 

 

The simplest solution is just to add the ö to the exclude list in the function.

 

I`ve tried to allow for most chars, but some can be made up differently (ie from multiple chars) Could you find what charset you are using & how your server supports unicode?

[pilvinen]

The simplest solution is just to add the ö to the exclude list in the function.

 

I`ve tried to allow for most chars, but some can be made up differently (ie from multiple chars) Could you find what charset you are using & how your server supports unicode?

 

My charset is ISO-8859-1. I suppose the server supports unicode...

 

I've been trying to add the letter to the exclude list, but it seems I don't know how to do it.

Should be simple in theory, but what ever I try I don't get the result I want.

 

// Clean post vars	

function clean_var ($vars) { 

	if (!is_array($vars)) {                              

	return preg_replace("/[^\p{L}\p{M}\w\r@ :{}ö_.-]/i", "", urldecode($vars));  

	} else {     

	return array_map('clean_var', $vars); 

	}

}	

 

This just won't do it and after some 3 hours of reading about reg expressions I'm just getting

very very tired about this whole matter ...

 

Some help would be appreciated :-)

[pilvinen]

// Clean post vars	

function clean_var ($vars) { 

	if (!is_array($vars)) {                              

	return preg_replace("/[^\w\r@ :{}öäåÖÄÅ_.-]/i", "", urldecode($vars));  

	} else {     

	return array_map('clean_var', $vars); 

	}

}	

 

By removing the \p{L} and \p{M} and adding öäåÅÖÄ it now seems to be working. The L seems to be any unicode letter, right?

But I have no idea what the M, Mark, stands for. The problem with unicode specs is that it's sooo confusing, there is just

too much to read.

 

Is there any reason why doing the above is stupid or is this fine? It does seem to work at least in contact us and reviews.

[spooks]

 

Is there any reason why doing the above is stupid or is this fine? It does seem to work at least in contact us and reviews.

 

 

If your not prepared to say precise details of your charset use & how your server supports unicode, I can't help you with your issue as my server setups show no issue with ö

 

Just replying with 'I suppose the server supports unicode' tells me nothing!!

 

 

Yes \p{L} means any letter, but some chars are made of multiple combinations typically a letter & mark combination, hence \p{L}\p{M} (thats how ö is usually constucted)

 

 

Your change will work, but means only those & standard a-z are covered, ie most 'foreign' chars are removed.

[AndreN]

Hi Sam

 

I have a strange issue with this contribution.

 

Once installed by copying over the files from your contribution, I could not add items to the cart. I noticed that I no longer had session IDs'

 

In html_output.php at Line 45

 

if ( ($add_session_id == true) && ($session_started == true) && (SESSION_FORCE_COOKIE_USE == 'false') ) {

I changed the last 'false' to 'False' and this restored my session IDs' and I was able to add contents to the cart again.

 

However with '$no_pword = true;' set in create_account.php and I follow the logic as explained in your account_mods.html i.e. PWA and complete the Create Account page and click the 'continue' button I get a cart empty message.

 

YET when I log in with the account credentials created by the above, I once again have contents in my cart.

 

With '$no_pword = false;' I get my cart with contents and functionality as it should be.

 

Any ideas why? What is killing/changing the Session ID ? I think this is something to do with the PWA logic.

 

Any suggestions or help would be appreciated.

Edited May 2, 2010 by AndreN

[AndreN]

I have removed this contribution from my store installation, pending an answer from the forum.

 

BTW, other than this issue, this is a great contribution Sam! :thumbsup:

[spooks]

In html_output.php at Line 45

 

if ( ($add_session_id == true) && ($session_started == true) && (SESSION_FORCE_COOKIE_USE == 'false') ) {

I changed the last 'false' to 'False' and this restored my session IDs' and I was able to add contents to the cart again.

 

 

This does not touch html_output.php, but your correction there is valid.

 

However with '$no_pword = true;' set in create_account.php and I follow the logic as explained in your account_mods.html i.e. PWA and complete the Create Account page and click the 'continue' button I get a cart empty message.

 

YET when I log in with the account credentials created by the above, I once again have contents in my cart.

 

With '$no_pword = false;' I get my cart with contents and functionality as it should be.

 

Any ideas why? What is killing/changing the Session ID ? I think this is something to do with the PWA logic.

 

With this the only real diference for PWA is password creation & the possible redirect to CHECKOUT_SHIPPING, does that occur? this uses tep_href_link for redirects, so there should be no session issues, its nothing I`ve seen b4!

Edited May 5, 2010 by spooks

[Denise Beck]

Hi there,

 

I have a strange thing happening as well. I installed Sam's anti-hacker account recently and tested it but only to realise that some orders were saved in the database and some weren't even though the payments went through to the paypal account, otherwise I wouldn't have known they existed. Would anyone know why.

 

Denise

[spooks]

some orders were saved in the database and some weren't even though the payments went through to the paypal account

 

 

Thats nothing to do with this, its a paypal issue, see the support threads for your paypal module for solutions.

[♥altoid]

Yes, it has the form suggested by ClubOsc and provides a more secure form of PWA (Purchase Without Account), and makes the personal details input a seamless part of the checkout, removing any password input requirement in that mode.

 

Sam, I have the Anti-Hack Mods Add On installed and all appears to be working as it's supposed to. Great and thank you.

 

My question is that I also have this other PWA add on installed. Do I deduce correctly from your comments posted here and the docs that the Anti Hacker PWA is independant of that other PWA; so I can therefore tidy things up in my shop by removing a couple database mods and file changes that were specific to my original PWA? Apparently they are not causing any conflicts that I see but if I don't need them I'd like to remove them for housekeeping sake.