Possible Bug in widget

LiveWhale
1

We have a unit that created a widget to embed on there website. It seems to work properly except that when you click on the register button within the widget, instead of taking you to Zoom, you get an error message that says “this content is blocked, contact the site owner to fix the issue.” You can try for yourself here: Learning in Retirement (LIR) | Retirement Center. The registration works fine from the event in the LiveWhale calendar page, so it’s something that’s occurring from the widget.

2

Hey Jamie, thanks for writing – I see what you mean!

Here’s what I see happening:

  • The widget is embedded using an <iframe> rather than the traditional LWC widget code which injects using HTML+JS. I think I recall this was a customization in the your original calendar rollout (i.e., your prior solution loaded widgets via iframe, so we helped make sure you could continue doing that.) Loading via iframe should work fine, I’m just noting it for important context.

  • When iframes are used on a web page, they have to follow the (parent) page’s Content Security Policy (CSP) – this has really grown in popularity over the last few years, from what I’ve seen. It’s basically a way for any website to tell browsers “here’s what URLs are safe to load in iframes on my pages”.

    • For the retirement.berkeley.edu page, I can see from the network inspector it’s currently allowing these embeds in their CSP header: child-src 'self' *.youtube-nocookie.com *.vimeo.com *.twitter.com calviz.berkeley.edu cdnapisec.kaltura.com *.google.com give.berkeley.edu events.berkeley.edu app.everviz.com export.highcharts.com blob: classes.berkeley.edu;

  • You can probably see the issue starting to take shape: retirement.berkeley.edu is allowing events.berkeley.edu embeds, but once someone clicks a link in that widget (say, to berkeley.zoom.us) that’s not on the allowed list, so the browser blocks it.

A few options for how you can get this fixed:

  1. Support berkeley.zoom.us embeds site-wide on retirement.berkeley.edu: Contact the owners of retirement.berkeley.edu and have them add berkeley.zoom.us to the Content Security Policy for their site.
  2. Edit the event to add target=“_blank” to the link in question: This is the easiest one-off fix for that single event, and is something a publisher or admin could do using your LiveWhale interface.
  3. Use a custom module to always add target=“_blank” to links added to an event description: This is a bit more work, but I think would be the most future-proof way to address this. Using onWidgetFormat to process the event description and add target="_blank" to any <a> tag should do the trick in a way that users wouldn’t need to think about going forward.

Hope this helps! Let us know if we can say more about this.

3

Thanks Karl, that makes sense and I will let the unit know solutions. The second solution is something they can do on their own calendar, correct? And the third solution is something we would have to do systemwide?

Thanks!
Jamie

4

That’s right, the second idea is something any publisher can do to their own event(s), and the third would be a site-wide approach.