[SOLVED] Windows IIS server : Customers Registration and Authentication problem (v 1.2.5)

[wwwilliam]

Hi everybody !

I need your help, thanks in advance for your attention and for any remark, advice, or direction you could give me on this problem.
I read hundred of posts in this multilanguage forum and could not find a solution yet.

Let me give you the details of my problem :

Customer's identification does not work on the distant server but it works here on my PC.

On the distant server :
The customer who wishes to register types his email address, then the registration form shows up and he fullfills it normally.... He receives his welcome/thankyou mail from the shop BUT IN THE FRONT OFFICE : my-account.php does not open, the my-account block does not appear neither the name, nor the deconnexion possibility. INSTEAD : the authentication.php page reloads !!!

BUT if the customer decides to order, he is asked AGAIN to register !!!
Then when he acts as a new customer, an error message tells his his email already exists !
Then, when he acts as a registered customer, he gets blocked on the authentication.php page which reloads again and again.
His account never shows-up ! He cannot get into the next purchasing step !

I do not find a solution to this !

Everything works well on local PC.
I have moved the files and the database on the distant server to make real-life testing.
Both front and back office open on the distant server. I can also open the database with no problem :
The only "minor" error here is the (Path is not the same between your browser and you server).
I have put : @ini_set(‘display_errors’, ‘on’); in config.inc.php,
I have : if ($back = Tools::getValue(‘back’)) Tools::redirect($back); Tools::redirect(‘my-account.php’); } in authentication.php,
I have emptied the smarty compile files (except index) which regenerated themselves.
The on-line database shows the customer who tried to register in xxx_customer ok,
The customer received his welcome email ok,
The customer who tried to register appears in the BackOffice on line ok,
If the customer did put articles in his cart, this cart is shown in the BackOffice on line ok,
The shop is located in a sub-directory (/plinthes/), not at the root.
The prestashop version is 1.2.5
The distant server is a windows server with php v5.2.6.
The hosting company confirms the server is a 32bits server thus the "PHP 5.2.6 (authentification is impossible on 64bits servers)" should not be the problem.
The info.php files shows x86 processors.
The permissions seem to be ok as no error is reported through config.inc.php,
System, Administrator and different Plesk users are set to "total control" (which include modify, read & execute, list the directory contents, read, write.)
What else could I do or check to solve this ?

Thank you for the help you could bring me to solve this issue.

The shop is here : http://www.plinthes-chauffantes.fr/plinthes/
A few producs are currently loaded in the "plinthes électriques" category or in the "services" category.

[wwwilliam]

Hi !

As I said in the previous post, during this shop elaboration process, I had to face the issue (limitation) regarding the customer authentication problem with Prestashop v1.2.5 under php v5.2.6 on a windows IIS server.
Although my distant server is a 32bit server as per the answer received from the hosting company, that problem occured and I had to solve it or move everything on a linux server.

:roll: The solution to move everything on a distant Linux server is, of course, the easy solution to this problem.
But this is a solution which .... is not the solution !!!


Hereafter is the solution I successfully implemented to run prestashop v1.2.5 under php v5.2.6 on a distant server running 32bit Windows (IIS): :coolsmile:

My distant hosting server offers as an option, to run php v5.2.6 as a CGI application and I first thought that this option could match the Prestashop requirements.

The authentication script (authentication.php) calls for server information using $_SERVER.
$_SERVER returns a table full of variables : the names and contents of the variables returned by the server is decided by the server and this is not a unique standard universal format.
It appeared that the authentication script did not find in this table returned by the server, the required variables and values which were needed to run.

So : when running PHP v5.2.6 on its standard default option (as a CGI application) $_SERVER receives a table of variables and values which do not match authentification.php expected variables names or values.

My idea was to run PHP v5.2.6 on another option (as a FastCGI application).

In this case the table which is returned by the server is different. The variable names and values given to authentication.php meet the requirements and the authentication process runs OK !

As an additional benefit, fastCGI run faster and needs less server ressources than CGI !

Hope this can help some other members of this community !

wwwilliam