Closed michaelwechner closed 11 years ago
Cedric has implemented this inside the branch 'remotes/origin/contact-form-v2', whereas it seems to me that the functionality using UUIDs is not implemented yet, but the resource just got refactored by extending BasicXMLResource instead.
I have an example added to
src/realms/yanel-website/res-configs-repo/data/en/contact.html.yanel-rc http://127.0.0.1:8080/yanel/yanel-website/en/contact.html
whereas one needs to uncomment the version 2 and comment the version 1 config.
Version 2 seems to be working now fine, except i18n does not work yet. Before continuing with the implementation of the UUID functionality which should get the i18n working for version 2.
i18n is also working for ContactResourceV2 when setting
inside
src/realms/yanel-website/res-configs-repo/data/en/contact.html.yanel-rc
I have the changes now into master and deleted the branch 'remotes/origin/contact-form-v2' in order to implement the UUID functionality inside a separate branch.
See branch contact-issue37
This has now been implemented.
We currently include the cookie ID inside the email, e.g.
Company: Test Firstname: Test Lastname: Tes Address: Tes City: Test E-Mail: michael.wechner@wyona.com
Message: Test
Yanel-analytics-cookie: YA-d70360bf-98ba-4305-9469-4dbba973d9f7
which is supposed to be used to check inside Boost the behaviour of this particular user.
But from a usability (and security) point of view it's bad.
The email should rather contain a link back to Yanel (using some neutral UUID), whereas then one can get redirected to Boost by using the cookie ID associated with the neutral UUID, but which is stored on the Yanel server