[FIX] website: don't show @ symbol when in backend iframe

==== Purpose ====

There is an issue with the `/@/` symbol website is using to display a
page in the backend: if someone copy paste a link with `/@/` in it and
send it in an email, some mail client will block those mails.
It was reported by our internal team, after feedback from some sales
persons.
Office 365 was incriminated (not the outlook.com web platform). While we
couldn't reproduce the issue, it was decided by the hierarchy to get rid
of it as it was judged impossible to educate our sales to not send such
links.
It's probably a good decision as:
- `@` in URL are usually used for HTTP Authorization:
  `http://username:password@example.com`
  Link [1] seems to mention that some mail client will not implement
  correctly the URL check to see if the `@` is problematic and will
  simply block mails having links containing `@`.
- The tradeoff of removing it is impacting dev/tech people, not the end
  user (except for F5, see below).

==== Technical ====

Before this commit and since commit [2] the following behaviors were
introduced:
1. a `/@/` prefix was added visually in the URL bar of the browser when
   accessing the website app (previewing your website in the backend) to
   differentiate it from the regular website/frontend URL
2. the possibility to type yourself `/@/` in the URL to access a website
   page in the backend app

It was improving the following pain point:
A. On page refresh (F5 or browser button), the user would land on the
   frontend version of the website instead of remaining in the backend.
B. When the user edited the URL (Like removing `/shop` and typing
   `/jobs` instead, he would land on the frontend version too.
C. Impossible to directly go to the backend version of the website.

This commit is now reverting point 1. while keeping the possibility of
point 2.
It means that while you can still reach directly your page in the
backend, the backend URL part `/@/` won't be kept.
About the mentioned point above:
A. This pain point will be back
B. This one too but workaround possible: need to edit the URL but also
   need to now add the `/@/`
C. This one will still be "fixed" as `/@/` still reachable.

While it seems to be decreasing the UX, it actually is an acceptable
tradeoff as:
- It mostly impacts dev/tech people, lambda end user don't play with
  URLs (low risk)
- It will prevent their mail to be blocked (high value)

--------------

Finally, note that in the meantime commit [3] was introduced which
relied on this `/@/` presence. This had to be adapted.

[1]: https://www.malwarebytes.com/blog/news/2022/05/long-lost-symbol-gets-new-life-obscuring-malicious-urls
[2]: https://github.com/odoo/odoo/commit/030d3cb10ee79aa1f010134578f4bcf65a1cfcde
[3]: https://github.com/odoo/odoo/commit/a0b3499d348d252c3abd48154e1fd8dd545c7504

closes odoo/odoo#116100

X-original-commit: b01337710b5fde995a184e442f48b687cd17967a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit is contained in:
Romain Derie
2023-03-22 00:53:59 +01:00
committed by qsm-odoo
parent eeac14d5b4
commit a7d6de80f3
2 changed files with 5 additions and 7 deletions
@@ -140,7 +140,7 @@ export class WebsitePreview extends Component {
// content of the previous URL before reaching the client action,
// which was lost after being replaced for the frontend's URL.
const handleBackNavigation = () => {
if (!window.location.pathname.startsWith('/@')) {
if (window.location.pathname === '/web') {
window.dispatchEvent(new HashChangeEvent('hashchange', {
newURL: window.location.href.toString()
}));
@@ -296,11 +296,9 @@ export class WebsitePreview extends Component {
if (!this.backendUrl) {
this.backendUrl = routeToUrl(this.router.current);
}
const currentUrl = new URL(this.iframe.el.contentDocument.location.href);
currentUrl.pathname = `/@${currentUrl.pathname}`;
this.currentTitle = this.iframe.el.contentDocument.title;
history.replaceState({}, this.currentTitle, currentUrl.href);
this.title.setParts({ action: this.currentTitle });
const currentTitle = this.iframe.el.contentDocument.title;
history.replaceState({}, currentTitle, this.iframe.el.contentDocument.location.href);
this.title.setParts({ action: currentTitle });
}
_onPageLoaded() {
@@ -44,7 +44,7 @@ wTourUtils.registerWebsitePreviewTour('add_to_cart_snippet_tour', {
...wTourUtils.selectElementInWeSelectWidget('action_picker_opt', 'Buy Now'),
...wTourUtils.clickOnSave(),
wTourUtils.clickOnElement('add to cart button', 'iframe .s_add_to_cart_btn'),
wTourUtils.assertPathName('/@/shop/payment', 'iframe button[name=o_payment_submit_button]'),
wTourUtils.assertPathName('/shop/payment', 'iframe button[name=o_payment_submit_button]'),
wsTourUtils.goToCart({quantity: 4, backend: true}),
wsTourUtils.assertCartContains({productName: 'Acoustic Bloc Screens', backend: true}),