Exciting News: A better-than-ever AppSheet and Google Sites integration is here!
We’re excited to announce that you can now embed authenticated AppSheet applications as iframes directly within Google Sites pages. While previously only public apps could be added to Sites, with this change, apps that require sign-in can now be embedded. This allows users tointeract with the appdirectlyon a Google Sites page - all while still ensuring the same enterprise-grade access control you’re used to.
Key Benefits
Streamlined user experience: Eliminate the need for users to navigate between multiple tabs. Users can now interact with authenticated AppSheet apps directly within Google Sites pages, boosting productivity and efficiency.
Centralized workflows: Build powerful, interactive business applications like intranet portals and wikis by embedding key tools and information directly into Google Sites.
Controlled by policy: Leverage AppSheet’s existing in-app authentication and policy rules, ensuring consistent behavior and secure access to your applications. Creators have the control to disable embedding functionality in their apps.
How to get started?
Open the app that you would like to embed
Choose Security in the navigation panel and turn on the toggleAllow app embedding
We’re hopeful that this integration will be a valuable addition to your toolkit and help expand the reach of your apps. We appreciate your patience while we worked to bring you this new feature. We’d love to hear your thoughts on it.
This is a fantastic feature and a real boost for Google Sites (even though it’s mainly down to AppSheet).
The reason I quoted the cookies section is because most of the internet (including Google) is under the impression that Chrome is getting rid of third-party cookies, so how will this feature work when third-party cookies are no more?
I’m not sure if or not my setting went wrong somewhere, but it looks like that the static image of the app is embedded to the Google site. After we managed to embed and the app view is rendered and click over the app somewhere, it always give us a prompt to open the app in full screen rather than allowing us to interact directly inside the embedded app. Is this behavior the core of this new feature?
Good question Stephen! You’re right that this feature depending on 3rd-party cookies (3PC). The history of 3PC is long and quite interesting. The latest update from the Privacy Sandbox is that 3PC are here to stay for the foreseeable future due to input from the UK’s Competition and Markets Authority. Privacy Sandbox, the organization that advises Chromium, has shifted its strategy in the last year from deprecating 3PC to giving more controls over 3PC usage, which is closer to what Safari/Firefox are already doing.
The major use-case that browsers are trying to crack down is using 3PC to track user activity across domains without user consent rather than the cross-site embedding for viewing & interacting with content which is widely considered a valid use-case for 3PC, which is what this feature does.
For some of the technical implementation, this particular feature also uses the Storage Access API which still uses 3PC but requires consent to send cookies across domain boundaries which is one of the recommended solutions to keep using 3PC in a privacy preserving manner which should allow this feature to work long into the future.
Make sure the app is completely visible (i.e. not covered by anything including the header, footer, or edit button). You may need to resizing the window to fit then you should be able to dismiss the dialog. This is a clickjacking protection.
However, as the following video shows, the only thing I can control from within the site is “sync”,
Add and Scroll do not work from within the site and prompt you to open a new tab.
This doesn’t seem to make much sense for the embed feature.
Am I doing something wrong with the procedure?
As the error message states, your entire app needs to be in view. Try scrolling up a bit. If that doesn’t work, you can zoom out by using your browser settings. Alternatively, you can edit the size of the block that corresponds to your app in the website.
Thanks for this announcement @vchitra@nico . I love Google Sites updates and this gives us a better means to develop functional intranets. Just starting to play with it now. Stay tuned.
In Google Sites, using a full page embed, I add the app share link and after insert nothing happens. It is enabled for embedding via Appsheet security settings. Page content embed works, just not the full page one which helps to avoid the sizing and viewport issues I think.
I noticed something strange.
For most of the operations in this case, “Open in New Tab” appears when the browser screen is maximized. By the way, you can’t scroll either.
However, when I make the browser screen smaller, I can operate the site normally from within the site.
@nico thanks for the reply: this allays our fears over Google Apps Script embedded apps tooo, as we have many.
Also as many have reported in this thread to @vchitra the clickjacking protection is stopping the embedded apps from being used. As you can see in this video I get told the app must be in view, and you can clearly see that it is in view, nothing is obstructing the view as there’s nothing else on the page and I don’t even need to scroll in the browser:
Please can this be looked into as there doesn’t appear to be any other way we can embed on a page, as there’s nothing that’s in the way or not in view.
@nico@vchitra I’ve also just spotted another issue: you cannot embed in a Google Sites Full-page embed page: I imagine this is down to the embed trying to add the “reauthorization” note below the embed, which isn’t possible of a Full-page Embed page in Google Sites, so you may want to add a note to your documentation:
Do you plan to let us use it under a custom domain? For example, I have a Google Sites website with my custom domain attached, and it only works with sites.google.com… link opened.
Do you also plan to make it available in a full-page embed?
It doesn’t overlap with the content but the IntersectionObserverV2 which we use to detect overlay is allowed to report false positives and I’ve seen it trigger when it’s 1 pixel off.
Additionally, the “edit” icon doesn’t appear for website viewers:
Thanks Stephen, appreciate the report and video. I played around with this and was able to reproduce the same issue. This appears to be a bug in Google Sites that crops up for a subset of websites in full-screen embeds (any website that triggers the “Reauthenticate” text), I’ve filed a bug on their team to take a look.
In the meantime, I have found the following workaround:
Note that even once Sites fixes this bug, having a full-screen app can only be used for read-only content, unfortunately because the “Information” icon in the bottom left will overlap with content and trigger the intersection check.
