Closed AlbertoMalavasi closed 11 months ago
Hi Alberto! Are you able to add a zip file to this issue with an example project that exhibits the problem described? Also, to help us investigate the best solution, what web browsers and devices have you used to recreate the issue?
Thanks!
Hello Kirstin, attached you will find the test client html file where we try to receive the fod.complete event. As you can see, we have tried both to include it with the script tag and to make an ajax call, in both cases without any success. In the server.zip you will find instead the two files used by the server that we started using your example. We also tried to add access control rules like the one below but without success: header("Access-Control-Allow-Origin: {$_SERVER['HTTP_ORIGIN']}"); header('Access-Control-Allow-Methods: GET, POST, OPTIONS'); header('Access-Control-Allow-Headers: Origin,Content-Type,Authorization,X-Requested-With, Set-Cookie, Cookie'); header('Access-Control-Allow-Credentials: true'); header('Access-Control-Max-Age: 86400'); The same client.html file loaded on the server where the get_script.php resides (and in the same path) works correctly instead. Have a good day, Luca Zip.zip
Move to on-premise as the issue specifically relates to the on-premise deployment.
I have created a branch of the main branch called issue/9.
Please can you fork this repo and branch and then add the information necessary under the examples/onpremise
folder to recreate the issue? Then make a pull request with your changes so that we can clearly see what is needed to recreate the problem.
So far our engineer has copied the files provided across and can't recreate the problem experienced in a development environment. The command used to run the PHP server after the instructions to build the on-premise solution have been followed is.
php -c php.ini -S localhost:3000
The fod.complete method is resolving for the promise within the web browser.
Adding development SSL certificates and test domains would be helpful.
Thanks for your help. It seems there might be some miscommunication. The branch, issue/9, replicates exactly the state of our main branch. Currently, there is no additional code to add or change to reproduce the problem as it is already present in this state. Have you tried altering the path, for instance, changing the folder?
Please note that the following link is the one responding to the webpages: https://51.change2.io/
1) The webpage functions correctly when located at https://51.change2.io/.
2) The webpage does not function when located at https://51.change2.io/demonew/. The cookie is created on https://51.change2.io/ with the path 'demonew'. However, if we remove the path using the inspector and refresh the page, the page works correctly.
3) (This point is crucial as this is the one we will utilize) If the webpage is hosted on a different domain, for instance, https://www.change2.it/demonew/, the cookie is created with this URL. Yet, even if we modify the domain by removing '/demonew' as we did earlier, it still does not function.
Please be advised that we have updated to the most recent version available.
Thank you @AlbertoMalavasi. We are looking into this issue and one more piece of information that we need from you is an understanding of how you have setup the service, including the Cross Origin Resource Sharing configuration. If you could please add the configuration of your server to the project, we can then recreate this in a controlled environment and progress further on resolving this issue.
Dear Sara, what configuration did you have that worked when you tested our issue? Our current configuration is: Ubuntu 18.04.6 LTS, Apache2 php 7.2.24.
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerAdmin info@change2.it
DocumentRoot /var/www/html/device-detection-php-onpremise/examples/onpremise/
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
ServerName 51.change2.io
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/51.change2.io/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/51.change2.io/privkey.pem
</VirtualHost>
</IfModule>
CORS: we tested a range of different configurations, no one worked.
Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS"
We have set up an on-premise server in a test domain: 51.change2.io. Its purpose is to provide the JavaScript (js) that needs to be included in a second domain, for instance, test.change2.io. On the on-premise server, we have included the call to the function $flowdata->javascriptbuilder->javascript.
In the second domain, we included the JavaScript using the HTML tag . When we load the page test.change2.io, the fod.complete() function is never invoked.
However, if we place the HTML page present in the test.change2.io domain in the same path as the file that generates the JavaScript, and therefore inside 51.change2.io, the fod.complete() function is executed correctly.
The same issue occurs if we put the HTML page in a path in a subdirectory; the fod.complete() doesn't work, for example: 51.change2.io/test.
Analyzing the cookies using Chrome's inspector, we notice that the cookie that is created has the path of the domain that contains the HTML file, so for example: test.change2.io. If we change the cookie by setting the domain to 51.change2.io, the fod.complete() function still doesn't work correctly.
In the case of the subdirectory of the same domain, for instance: 51.change2.io/test where we find the cookie created as domain 51.change2.io and with path set as /test. If we proceed to delete the path and set / as the path of the file that generates the js, everything starts working correctly.