I am having an issue with Spotify Iframes displaying tracks in preview mode. According to Spotify for Full Track Playback in Iframes,
We have introduced full playback directly inside of the Spotify Play Button. It works on most major browsers, including Chrome, Firefox, Opera and Microsoft Edge. The user must also be logged into spotify.com in their web browser and your HTML must contain the allow="encrypted-media" attribute.
Using the iframe script below (provided in each spotify track) or simply accessing the embed URL, I get access to the full track in my browser when I am logged into my web-based Spotify account. However, when deployed to a server (such as an EC2 instance), I am stuck in preview mode while still being logged into my web-based spotify account. Similarly, I'm stuck in preview mode when deploying the same script in StackOverflow (see below to run code snippet)
Any idea what is going on? My understanding is the Iframes are Client-side generated, so if my browser is logged in to the web-based platform, I should have access right?
Any resources to help me further understand would be appreciated. Thank you!
<iframe style="border-radius:12px" src="https://open.spotify.com/embed/track/2vWE6Btt6Kwc8yRkr6g4Qg?utm_source=generator" width="100%" height="352" frameBorder="0" allowfullscreen="" allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>
Related
I am building a custom ms teams application with tab capability. And I am embedding a work website inside the tab. The website loads fine in the web app. However it doesn't show in the desktop app. There is one hack to it though. If I switch to developer mode on the desktop app, it is loading the website. My website is SSO enabled for login, so it is redirecting to Idp site. One thing I have understood is, the Idp site doesn't allow their content to be loaded in an iframe, and ms teams uses iframe to load webcontent. But then I am wondering what is different for a developer mode. Why does it work there? Also since it works fine in the browser app, shouldn't it work in desktop app too. I mean the behaviour should be consistent. Any pointers?
could you please follow this document and you need to use microsoftTeams.authentication.authenticate() to show the popup.
I've developed an website in Asp.net using VB. One of the requirements was for a qlikview to be displayed.
It's under a type of report hub, where I've got a list on the side of the page where the user can select a report and the rest of the page is an iframe. When the user selects a report, a javascript function is fired which sets the address of one of the reports into the iframe. The reports are all on their own page so I'm basically calling the page from the same domain and showing it in the iframe, no issue here. The problem comes when I've got to display the Qlikview which is hosted on another server.
This throws an error in the inspector but it still displays fine, it works like this on Chrome, Edge, Explorer and Firefox.
The issue comes with Safari, it blocks the authentication request because it is a cross-origin request.
I've tried the answer from this question. I've tried changing the domain name as listed here.
I've tried allowing cross origin access as listed here, but it didn't help.
I'm still very new to this, so i apologize if this is a simple solution.
Take a look here - Maybe this can help you
Using cors with all modern browsers
If it is working ok on Chrome and Firefox it is set ok on server. Qlikview officially support IE and Chrome. Safari have some issue with headers.
If you host your add-on (what is in iframe for Qlikview) on S3 for example for Safari you need to allow origin header, probably on different hostings something similar:
<AllowedHeader>origin</AllowedHeader>
Workaround is also that on Qlikview server it can use IIS for displaying Qlikview access point. If you want you can just go to IIS settings on Qlikview server and just set folder where you deploy your add-on pages so this way it can be configured that both will be served from the same domain (your add-on and qlikview access point). There is also Qlikview server configuration without IIS with Qlikview Web Server which will not allow to deploy another site.
I've created an embedded signing experience for DocuSign users using a VisualForce page.
The page renders well for users in Chrome or FF, but not in Safari. If I enable or accept cookies from any website, it works. However, I can't expect that all the clients have cookies enabled. Also, the iOS Safari doesn't work at all.
Any suggestions? Is there any workaround for using a iFrame for embedded signing?
For iOS and any other mobile interfaces that you build, DocuSign highly recommends using a Webview as opposed to an iFrame. For instance, see the note near the top of the Post Recipient View API call (aka Embedded Signing).
I am implementing a bookmarking service (think Instapaper) using Firebase as a back end. Mostly it's working great, however I'm running into one major problem.
A core part of the service will be a bookmarklet that allows users to bookmark pages they are currently viewing in their browser (again, like Instapaper's: https://www.instapaper.com/save).
The first problem I encountered when implementing this was that even when a user is logged in on my firebaseapp.com page, that user was not showing up as authenticated when the javascript from the bookmarklet was fired. I figured out this was most likely due to cross-domain issues, so I next implemented an iframe-based solution. The idea being that the url of the iframe is hosted on my firebaseapp.com site, allowing the currently-logged-in user to show up as authenticated.
This works great in Chrome and Firefox but fails in Safari when the security setting for cookies and website data is set to "Allow from websites I visit" rather than "Always allow" (asking users to switch that setting to "Always allow" is not practical).
Is there any solution to this problem? Forcing users to log in every time the bookmarklet is clicked on a new domain would be highly inconvenient. I'm basically out of ideas at this point (and starting to get out of my depth on the web dev side of things).
Thank you so much for any help!
I have researched quite a bit and found no answer so I decided to make a post on this.
I have a fully working SharePoint 2010 Site Collection with some CSS and JavaScript resources to customize the look and feel of the site.
Everything is checked in and published and the site was working fine until we load balanced the two Frontend Servers.*
The problem is that, if - and only if - the site is opened through the load balancer, everyone gets some disrupted design issues AFTER clicking Internet Explorer (8) refresh button.
Moreover, SharePoint Designer does not work while using the LB as well:
"An error occurred accessing your Microsoft SharePoint Foundation site files. Authors - if you are authoring against a Web server, please contact the Webmaster for this server's Web site. WebMasters - please see the server's application event log for more details."
So this situation is not a problem on the following situations:
Open the site inside any of the servers or using a direct hosts entry to one of the servers (not using the Load Balancer)
IE10+ or another browser is used
Ctrl+F5 on IE8 using the LB
Similar (unanswered questions):
http://www.networksteve.com/enterprise/topic.php/Styles_&_JSs_loading_errors_in_load_balancing_sharepoint_farm_wh/?TopicId=49098&Posts=3
http://social.msdn.microsoft.com/Forums/sharepoint/en-US/279b72ba-ede4-44b1-8429-1f2ff4d80c32/401-unauthorized-error-while-connecting-to-web-service-sharepoint-ipfs?forum=sharepointcustomizationlegacy
Note:
Fiddler does not show any relevant output, apart for some suspicious 401s that also appear when the site works
ULS Logs do not show any relevant authentication, permissions or other entries when the issue happens
As any medium/large company with intranet restrictions, we really need to support IE8. Also, SharePoint Designer does not work even if IE10 is installed.
the frontend servers were behind an F5 load balancer.
for some reason, sites rendered through the LB were displaying with IE7 rendering.
the solution was to add IE7 support to the branding solution, although it could work with a local browser tweak (unchecking "show intranet sites in compatibility mode").
I now tend to ask that LB caches are cleared whenever I have FE specific design problems