I'm working on a chatbot with Dialogflow and I'm really impressed of all its functionality. I set up an fully working agent and want to use it on my website. But the cross-origin iframe gets blocked.
Uncaught DOMException: Blocked a frame with origin "https://console.dialogflow.com" from accessing a cross-origin frame.
What do I miss, as this is the official method to publish my bot on my page?
I use the following example code
<iframe
allow="microphone;"
width="350"
height="430"
src="https://console.dialogflow.com/api-client/demo/embedded/c3f5abdb-c28d-4244-acc7-53abc91f0e8e">
</iframe>
It displays the agent but I cannot activate or use it...
Related
We are creating video reviews in the review tool using the code here and everything used to work before (months back).
Now the only problem we are facing is loading the video on the review tool.
From the console, On chrome, it says CORB blocked the response,
Cross-Origin Read Blocking (CORB) blocked cross-origin response https://REDACTED.streaming.media.azure.net/REDACTED/ignite_c_c.ism/manifest with MIME type application/vnd.ms-sstr+xml. See https://www.chromestatus.com/feature/5629709824032768 for more details.
And I can see 0B responses,
And on Firefox,
But if you paste the same video manifest URL in the Azure Media Test Tool, it works fine there.
Any help to fix the video loading issue would be greatly appreciated.
If you say you were able to use tha same without any changes over months ago, maybe a browser update(unless you have updated endpoints or header to Cross site access policies). Refer Configure CDN profile
However, "CORB" referred above seems similar to CORS (Cross Origin Resource Sharing).
It is an HTTP feature that enables a web application running under one
domain to access resources in another domain. In order to reduce the
possibility of cross-site scripting attacks, all modern web browsers
implement a security restriction known as same-origin policy. This
prevents a web page from calling APIs in a different domain. CORS
provides a secure way to allow one origin (the origin domain) to call
APIs in another origin.
CORS on Azure CDN will work automatically with no additional configuration. When you create a new account, default Streaming Endpoint Azure CDN integration is enabled by default. If you later want to disable/enable the CDN, your streaming endpoint must be in the stopped state. It could take up to two hours for the Azure CDN integration to get enabled and for the changes to be active across all the CDN POPs.
you might want to start using a wildcard (*) to setup the HTTP header, which disables CORS and allows any URL to access the CDN Endpoint.
Refer: Using Azure CDN with CORS
Caution: The Content Moderator Review tool is now deprecated and will be retired on 12/31/2021.
Video moderation enables detection of potential adult content in videos. The review tool internally calls the automated moderation APIs and presents the items for review right within your web browser
There are multiple indications:
SameSite cookie flag error
No decoders for requested formats
CORB error
You can give this a try though:
Set the SameSite by default cookies flag value to Disabled in Chrome 80 and later versions.
In your Chrome browser session, address chrome://flags/ and Search for or find the flag, SameSite by default cookies.
Select Disabled
.
How to set up cross-domain tracking in GA4 right?
I followed official instructions: [GA4] Set up cross-domain measurement
I've added all the domains I need to the Date Stream Details - More Tagging Settings - Configure your Domains.
Added 'Google Analytics: GA4 Configuration' tag on the website using Google Tag Manager.
But now, when switching between domains, a lengthy parameter
(smth like "?_gl=11lop9ld*_gaNDcxNTp2McYzKjE2LTcxMjQwKLv._ga_3JP1WO1NB3MTYxNzEyNDA4Ny8xLjEuKOPxNzEyNLI5Ny40Nw..")
is added to the page address and the page does not open, a 404 error appears.
What could be the problem?
As #Tony McCreath said, It might be a problem on the website's end on handling unexpected query parameters. I already faced this problem while working on a client website, and there was nothing that could be done on the Analytics side to fix the issue. You can test if that's the case by adding any random parameters at the end of the URL to see if the website still works.
The lengthy parameter that is added to the URL is the way Google uses to identify that a user is coming from another domain. It's basically an ID that will link the user from the previous domain to the current one.
I try to find a internet place where I could find support about the Skype Web Control (dedicated support web site, forum, chat, documentation). A place where I can report problem and find help.
Here are my issues, maybe someone has a solution:
I use the Skype Web Control with a Microsoft Chatbot (Azure, LUIS) and it works pretty well.
But the smileys are not displayed in the conversion when the user send one. Space are taken to display the smiley but no smiley in there. If the user is connected, the conversation in the Skype application displays well the smileys.
And when the bot answer with a smiley, it is displayed as text :) not replaced by an image. Is there a way to do it?
I also have the following error:
Cross-Origin Request Blocked:
The Same Origin Policy disallows reading the remote resource at
https://browser.pipe.aria.microsoft.com/Collector/3.0/?qsp=true&content-type=application%2Fbond-compact-binary&client-id=NO_AUTH&sdk-version=ACT-Web-JS-2.9.0&x-apikey=xxx.
(Reason: CORS request did not succeed).
Does anyone know how to fix it?
There are multiple questions. To enable emojis you can customize webchat control. We did it and enabled emojies and other features too. Below is the link of source of webchat:
https://github.com/Microsoft/BotFramework-WebChat
For CORS issue (cross domain security issue) have you tried placing the code on ms azure app. We faced the issue, with our own server, but not on azure app. CORS can be configured using web.config too.
We load Google Analytics (Universal) via Google Tag Manager and I can't find any way to force it to load the analytics.js script itself over SSL; we set forceSSL via the fields to set options, but by the time it applies that it has already loaded the initial script over plain HTTP.
It looks like GTM checks whether it's on an HTTPS URL and then loads GA over HTTP if so, but I'd prefer to force it over HTTPS instead. Is there any way to do this?
Unfortunately, looking at the documentation available at the very bottom paragraph of Google Tag Manager - Dev Guide - Security, it reads:
While most of the tag templates in Google Tag Manager are also
protocol relative, it's important to make sure that, when setting up
custom tags to fire on secure pages, those tags are also either
protocol relative or secure.
I flipped through a GTM profile to see if there were any configuration options exposed, but I didn't see any either. To your statement about using forceSSL, that wouldn't do anything (as you found) because it's setting a configuration in the already-loaded GA script to use for sending the future requests (e.g. pageview and events).
So, I loaded up a page with GTM installed on it with GA and took a look through the logic until I found where Google Analytics is loaded up from. If you'll take a look, we've got a function that's essentially determining whether to load GA up from either HTTP or HTTPS depending on the value of location.protocol as in the below screenshot:
That means that unless you load up the GA tag via a Custom HTML tag, you're not going to be able to change it to explicitly only load from HTTPS. You mention you're considering just hosting GA directly on the page - you're going to be pasting the exact same snippet there as you would in this Custom HTML tag (ensure that it's surrounded by tags or it won't do anything), and if you're already using GTM for something else, there's little reason to leave your vendor logic in multiple places.
So, in a long answer, no, you can't specify that you want to only load Google Analytics via SSL without resorting to using a Custom HTML tag (and then you unfortunately lose a lot of the mapping simplicity of using the GA tag itself).
I'm just getting started looking at the Google Analytics API which should allow me to embed some Analytics data into a page. I have found two pages containing almost identical demo code, both created by Google themselves:
https://ga-dev-tools.appspot.com/embed-api/basic-dashboard/
https://developers.google.com/analytics/devguides/reporting/embed/v1/devguide
and neither of them works. Nothing loads, and the error message in the Console is:
Refused to display 'https://accounts.google.com/o/oauth2/auth?client_id=MY_CLIENT_ID&origin=MY_URL&state=1729197785%7C0.713338618&authuser=0' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.
Can anyone explain why this would be? The Client ID isn't the problem, I've double-checked, and there are no restrictions on referrers. This happens when the code is place in a live public web page, not locally on an intranet or localhost page.