I'm facing a problem with my WordPress website, it has a subdomain, blog.domain.com, when I access the blog I get the following error in my console:
Access to Font at www.domain.com/wp-content/themes/Divi/core/admin/fonts/modules.ttf from origin blog.domain.com has been blocked by CORS policy: No Access-Control-Allow-Origin header is present on the requested resource.
Currently, my website is hosted in Azure, I tried activating the option "Cross-Origin Resource Sharing - Cors" in my hosting options, it solved the issue, but it made the website a lot slower (16 sec), so I'm looking for an alternative to this issue.
If anyone has any idea how I can resolve this, I am opened to suggestions, I would appreciate it!
Thanks
If you use the windows azure web app, I suggest you could try to access below url:
https://yourwebappname.scm.azurewebsites.net/DebugConsole
Then you should go to the site\wwwroot and find the web.config file and add below config setting:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
</system.webServer>
Related
Does anyone know how to get Acumatica screens to be embedded in an iFrame in a wordpress site? When embedding an Acumatica screen in wordpress - I see the login screen however - after successful login I receive a refused to connect error.
I tried modifying the X-Frame in the web.config file - however still no difference after login. Does anyone know what changes need to be made on the Acumatica site to allow this? Or is it possibly a change that needs to happen in wordpress?
I realize that we should look at integrating the SSO but conceptually would think that the iFrames would work with or without SSO being setup yet or am I wrong in that assumption?
the answer provided by Hugues is very valid, but in the scope of Same Site Cookies.
With iFrame you would generally get following exception:
The loading of “https://yoursite.acumatica.com/Main?HideScript=On” in a frame is denied by “X-Frame-Options“ directive set to “SAMEORIGIN“.
For a while solution was to add an explicit header X-Frame-Options and in ALLOW-FROM specify an uri to the site you would like to allow to open Acumatica in iFrame, this however is now outdated: X-Frame-Options
Currently suggested way would be to use frame-ancestors directive of the Content-Security-Policy (frame-ancestors)
For applications that run on IIS, like Acumatica, it is done by finding in web.config
<httpProtocol>
<customHeaders>
...
And modify and add to this clause line like following example:
<add name="Content-Security-Policy" value="frame-ancestors 'self' https://my.site1.com *.site2.net http://localhost:82" />
This is just a syntax example that will allow the Acumatica to be open in iFrame on same domain, on my.site1.com, wildcard for all subdomains on site2.net and on even on the site deployed locally on the server that listens 82 port. Please use last one (http://localhost:82) only for testing purposes.
So the end result in your web.config should look similar to that block (based on SalesDemo deployment):
<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />
<add name="Content-Security-Policy" value="frame-ancestors 'self' https://yourWordPressUri" />
</customHeaders>
</httpProtocol>
Hope this is helping
I believe you are running into a same-site cookie policy error. If the issue was cross site scripting error you wouldn't see the login page.
Same site cookie policy can be disabled in the web config file:
https://learn.microsoft.com/en-us/aspnet/samesite/system-web-samesite#using-samesite-in-aspnet-472-and-48
Change the web.config file settings as follows:
Step 1: Open the web.config file, which is located in the application instance folder.
Step 2: Find the <system.web> section and add the following line to this section:
Note! The first occurrence of <system.web> located in the < location > tag is not the needed section.
Step 3: Add the text highlighted in bold to the following lines:
<formsAuth loginUrl="Frames/Login.aspx" timeout="60" requireSSL="true" />
<sessionState cookieSameSite="None" cookieless="UseCookies" mode="Custom" customProvider="PXSessionStateStore" timeout="60" sessionIDManagerType="PX.Owin.SessionIdManager, PX.Owin">
I have a MVC site that I want to load into Iframe. I have added the X-Frame-Options to AllowAll. When I try to load the site, I can see the html document in developer tools but the IFrame in the Page is blank.
I tried to create a web application on localohost with different port number and where I tried to load the MVC site in Iframe, it didnt work.
I tried to add a html in the same MVC site and loading itself in the html's Iframe (assuming port issue but still it will not load).
Any help will be appreciated.
I recently ran into a similar issue. The X-Frame-Options header did not work for me. I had to use the Content-Security-Policy header. In the web.config file, I set it to frame-src https://my-domain.com like this:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="frame-src {your domain here}" />
</customHeaders>
</httpProtocol>
</system.webServer>
I checked some other solutions on StackOverflow and did not find the answer I am needing so I am asking this.
I have a site 'subdomain.myexamplesite.com' and my main website 'myexamplesite.com'.
I am hosting my CSS on 'myexamplesite.com' for the 'subdomain.myexamplesite.com' because I wanted to have all the CSS files in one place.
I don't have any issues with cross domain issues doing the hosting of the CSS files this way. Everything renders great.
The issue I have now is, I am using an #font-face and trying to get that to my subdomain site. But I am getting a cross domain error:
Font from origin 'https://www.myexamplesite.com' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://subdomain.myexamplesite.com' is therefore not allowed access.
The main website is a .Net website (Umbraco CMS to be exact) hosting on an IIS server. The other site is a different .Net site but still is hosted on IIS.
Since it is IIS, I don't think .htaccess file applies in my case.
I have a crossdomain.xml on my main website to allow access from my subdomain just to be sure. But that does not work.
I am referencing the font file correctly in the CSS for my subdomain site otherwise I don't think I would be getting the Font cross domain error.
Does anyone have any suggestions if it is possible to host fonts on my main domain and allow the sub domain site to use those same fonts.
Any ideas?
For a font file you need to set Access-Control-Allow-Origin http header.
To set it on all files add this to the web.config
<httpProtocol>
<customHeaders>
<remove name="Cache-Control" />
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Headers" value="Content-Type" />
<add name="Access-Control-Allow-Methods" value="GET,PUT,POST,DELETE,OPTIONS" />
</customHeaders>
</httpProtocol>
Or more specific add something like this to the web.config below the <system.webServer> and set the location path to your font file.
<location path="static/fonts/source-sans-pro-regular.ttf" inheritInChildApplications="false">
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
</system.webServer>
</location>
See cross-domain-fonts
and 59378-Centralized-Umbraco-7-Dashboards-Access-Control-Allow-Origin
and access-control-allow-origin-multiple-origin-domains
and font-face-fonts-only-work-on-their-own-domain
I'm converting an old .NET WCF service to Web API 2
To maintain backwards compatibility I have applied a RoutePrefixAttribute to my controller as shown:
All has gone pretty smoothly until I try to publish my service and access it via IIS
When I run my service via localhost (debugged from Visual Studio) and make a request via Postman all is well and I get the expected response:
However, after I publish the site to IIS, set a host entry and try to access the same endpoint:
I receive a 404 not found:
I did some playing around, and decided to remove the ".svc" from my RoutePrefixAttribute for my Controller. And voila, I can now hit my endpoint via IIS:
So my question is: Does Web API 2 not support the ".svc" or even perhaps periods in their routes? Has anyone encountered something similar and found a reasonable workaround?
Thanks
My issue was as Kiran Challa indicated. I had to add the following line to my system.webServer handlers:
<system.webServer>
<handlers>
<add name="ApiURIs-ISAPI-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
More information here: Dots in URL causes 404 with ASP.NET mvc and IIS
We have a site running on MOSS 2007 which makes calls to custom web service asmx methods on the same domain from the client.
At first everything works fine, but after a bit of time has passed the service will start to fail with:
http://[domain]/_layouts/error.aspx?ErrorText=Request format is unrecognized for URL unexpectedly ending in %27%2FIsSuspectWaterLevel%27.
Interestingly enough
http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx?op=IsSuspectWaterLevel
is still available, but a call to
http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx/IsSuspectWaterLevel
will fail as described.
We've found that "touching" C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\ISAPI\ web.config will bring the webservice back to life.
The asmx file lives at
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\ECan\MyECan_ComplianceWaterUsage.asmx
Any ideas of what might be going on here and how to resolve them?
Some extra detail:
App pool settings in case they're useful: http://i51.tinypic.com/x51qw.png
The following web.config settings are present in the root and sub directory hosting the asmx:
<system.web>
<webServices>
<protocols>
<add name="HttpSoap" />
<add name="HttpGet" />
<add name="HttpPost" />
</protocols>
</webServices>
...
</system.web>
We are calling the web service from javascript (jQuery). I've checked all the settings mentioned in this link and all match. I think calling from javascript may not be the culprit though as going directly to
[domain]/_vti_bin/Custom/CustomFunctionality.asmx/IsSuspectWaterLevel
with parameters supplied also fails with the same error - no javascript involved. Failing after a short period of time has passed, but works fine when web.config has just been "touched" again.
Thanks in advance for any help! Cheers, Gavin
I'm currently working on the same problem, and I think you barked the wrong tree.
The problem is, that in the ISAPI folder of SharePoint is a web.config with the following lines:
<webServices>
<protocols>
<remove name="HttpGet"/>
<remove name="HttpPost"/>
<remove name="HttpPostLocalhost"/>
<add name="Documentation"/>
</protocols>
</webServices>
The problem is, that the desired protocols POST and GET will be removed for the entire ISAPI folder and its subfolders. I also tried to reactivate the protocols via
<location path="[Path to my Web Service].asmx" allowOverride="false">
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</loaction>
in different places (machine.config, web.config of root folder, web.config app.config, ...), but it didn't last.
The only thing that worked, was, to change the "remove" items in the web.config of the ISAPI folder to "add" items.
But this has the nasty side effect, that the built-in web services, like "Lists.asmx" throw errors if you try to request their documentation pages...
If you can live with that, this would be your solution. I can't, so I still try to figure out a way to make my
<add name="protocol">
items persistent.
By the way: Also adding lockItem="true" to the <add/> items didn't do the trick...
Chris
It has been awhile since I have touched Sharepoint so this is a shot in the dark. If I remember correctly modifying anything in the web.config will restart the website in IIS. So what you may be seeing is IIS restarting the website that hosts the webservice putting it back into a good state.
Do you have the following in the web.config for the web application?
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
This is a strange problem and hard to diagnose due to the number of occcurances of the 12 hives web.config protocols issue which would appear to resolve 99% of the cases of this issue.
There is another issue called URL rewriting that will cause this
problem.
Some reverse proxy devices can modify the path of a request (the
portion of the URL that comes after the hostname and port number) in
such a way that a request sent by the user to
http://www.contoso.com/sharepoint/default.aspx, for example, is
forwarded to the Web server as
http://sharepoint.perimeter.example.com/default.aspx.
This is referred to as an asymmetrical path. Windows SharePoint
Services 3.0 does not support asymmetrical paths. The path of the URL
must be symmetrical between the public URL and the internal URL. In
the preceding example, this means that the "/sharepoint/default.aspx"
portion of the URL must not be modified by the reverse proxy device.
Even more depressing is that microsoft knows about this and actively refuses to support it.
Ref: URL Rewrite + SharePoint = No Support
Also : SharePoint, url rewriter, WebServices
An inelegant workaround to this issue that works for us: We've swapped out the web service asmx end point for a web handler ashx endpoint. This doesn't suffer the same issue for some reason.
I'm guessing from this that there's some issue creeping in after a period of time which is causing urls to resolve incorrectly. I suspect that the / after the .asmx in the url is the curprit. The ashx endpoint implemented is working purely on url parameters and posted data.
Obviously this work around won't always be an option for others who might experience the same issue as we're loosing a lot of the rich web service functionality that's pre-baked in to an asmx endpoint.
Unfortunately I won't be able to test any other solutions that people might put forward from now on as we've moved away from the web service asmx approach. Sorry. Thanks for all the suggestions though - it's been very much appreciated!