51Degrees / device-detection-php-onpremise

On-premise implementation of the 51Degrees Device Detection engines for the Pipeline API
Other
1 stars 3 forks source link

Cookie Generation - Path #9

Closed AlbertoMalavasi closed 11 months ago

AlbertoMalavasi commented 1 year ago

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.

kirstin51D commented 1 year 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!

lucasimonichange2 commented 1 year ago

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

jwrosewell commented 1 year ago

Move to on-premise as the issue specifically relates to the on-premise deployment.

jwrosewell commented 1 year ago

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.

AlbertoMalavasi commented 1 year ago

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.

Sara51D commented 1 year ago

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.

AlbertoMalavasi commented 1 year ago

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"