I would like to use window.external.notify from a webview loading content from the web in a uwp application.
According to documentation
To enable an external web page to fire the ScriptNotify event when calling window.external.notify, you must include the page's Uniform Resource Identifier (URI) in the ApplicationContentUriRules section of the app manifest. (You can do this in Microsoft Visual Studio on the Content URIs tab of the Package.appxmanifest designer.) The URIs in this list must use HTTPS, and may contain subdomain wildcards (for example, https://.microsoft.com) but they cannot contain domain wildcards (for example, https://.com and https://.). The manifest requirement does not apply to content that originates from the app package, uses an ms-local-stream:// URI, or is loaded using NavigateToString.
My question is the following. If I declare the following uri in the manifest
https://www.foo.bar
Does this map to only https://foo.bar or to other uris originating from it like
https://www.foo.bar/foobar
By testing on my side, when adding the domain root Uniform Resource Identifier (URI) to ApplicationContentUriRules, other pages under this folder in the server side could also work well, include the pages on subfolder.
So that to answer your question, ApplicationContentUriRules should be not only work for https://foo.bar, but also other uris originating from it.
If you need also to access pages from sub domains, you need to add subdomain wildcards as the document mentioned.
Related
I'm creating a Kentico media library file using Kentico API 11.0.26. The CMS and MVC app are on a web farm. Both are in healthy state.
The file gets created fine, but is only accessible on the CMS application, not on the MVC website. This is true for both Direct Path link as well we Permanent link.
Copying/pasting the Permanent link in browser preceded with MVC domain gives this message: "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable."
Can someone explain what "same UNC root defined " means in this section:
If you are running the system on a web farm and have the same
UNC root defined on all servers, it is necessary to add the
following key into your web.config file. The files stored in the
libraries are then not transferred when synchronizing the web farm
content:
<add key="CMSWebFarmSynchronizeMediaFiles" value="false"/>
https://docs.kentico.com/k12/configuring-kentico/configuring-the-environment-for-content-editors/configuring-media-libraries
The UNC (Universal naming convention) is the standard for identifying a server/machine on a network, used like so: \\server-name\rest of path
In Kentico, you would be using UNC to tell Kentico where you're storing media library files if it's on a different server in the network.
The first thing that came to mind why you're getting a 404 is it's probably that the media URL has a tilde (~) preceding it. If that's the case, remove that tilde and see if the problem is resolved. Personally, I do a replace like so:
MediaLibraryHelper.GetPermanentUrl(mediaLibraryFile).Replace("~/", "/")
I'm not aware if there's a helper function to give you a URL without string replacing the tilde.
Is there a way to link to a resource in a domain-relative but protocol-specific way?
For instance, consider a link on the site http://example.com
...
This links to:
http://example.com/home/ if the page you are on is on the HTTP protocol.
https://example.com/home/ if the page you are on is on the HTTPS protocol.
...
This links to:
http://example.com/home/ always
Is there a way to link to the HTTP version of the site without explicitly stating the full domain?
I found the answer in RFC3986, and the answer supports some of my blind attempts. There is a backwards compatability feature with a previous spec which allows you to specify the scheme if and only if it matches your current scheme. In these cases, if you are linking from http://example.com, the URL http:home will link to http://example.com/home, however https:home will link to https://home/.
Some parsers allow the scheme name to be present in a relative
reference if it is the same as the base URI scheme. This is
considered to be a loophole in prior specifications of partial URI
[RFC1630]. Its use should be avoided but is allowed for backward
compatibility.
"http:g" = "http:g" ; for strict parsers
/ "http://a/b/c/g" ; for backward compatibility
We can see many HTML page using src="//example.com/myjavascript.js" to include a .js and let the browser use http:// / https:// depending on the current scheme of the page URL.
Is this a valid URI ?
Yes, it is definitely valid. It is a "scheme relative" or "protocol relative" URI. In the spec since the beginning. Quite helpful to deal with http/https issues.
Read a much better description and caveats:
Is it valid to replace http:// with // in a <script src="http://...">?
A few points to keep in mind:
There are some minor issues on IE 7 & 8 with double downloads
If you are viewing an HTML page from a file the browser will replace the scheme with file://, and not load your JS file from the server like it would with a full URL starting with http:// or https://.
Edit for modern webdev practices:
While the URL is still valid, it is now recommended to use https for third party resources (and, serve those resources from secure pages). The performance or compatibility issues from years ago are largely resolved with updated protocols and browsers.
As a warning... we encountered issues with this methodology NOT being supported in Internet Explorer when used inside the HTML BASE tag (IE8 and 9 confirmed, didn't test any others before patching the issue).
After newly implementing SSL on a website, we had initially updated the BASE tags across the application to simply reference "//www.mydomain.com" : but the page templates broke (in IE only) on all scripts which did NOT live at the root of the site. Makes sense, since the BASE tag was not picking up the stylesheet or other relatively-linked resources which assumed they were being referenced from root, not from a nested location.
Since the BASE URI was our own domain anyway, we fixed the issue by setting the BASE tag's value to "https://www.mydomain.com". No matter if the client is browsing the site in SSL mode or out, at least it will work cross-browser now and can ALWAYS find its content - and by forcing https at all times, we ensure we don't get any content-mismatch warnings in the process by setting the BASE path to an http location while browsing a page using https.
It is valid indeed and I have just learned this in the hard way!! We broke a customization feature so you should always validate an URL like this (in .NET):
Pay attention to:
White spaces (Trim)
"scheme relative" URI (UriKind.RelativeOrAbsolute)
public bool IsValidUrl(string resourceUrl)
{
Uri uri;
if (Uri.TryCreate(resourceUrl.Trim(), UriKind.RelativeOrAbsolute, out uri))
{
return uri.IsWellFormedOriginalString();
}
return false;
}
If I have a request for a resource in my ASP.NET MVC1 (or 2) web app for a static resource, say ... an image or a javascript file or a css file ... does the .NET framework try and see if the request matches the route list ... and eventually can't find a controller for it?
eg.
Resource: /Content/Images/Foo.png
Does this request go through my route list .. fails to match any controllers / actions to this request and then attempt that path directly?
You can choose whether to map an existing file or not setting the RouteCollection.RouteExistingFiles Property
Gets or sets a value that indicates
whether ASP.NET routing should handle
URLs that match an existing file.
Here is what I read from here:
However, the routing system still does check the file system to see if an
incoming URL happens to match a file or disk, and if so, routing ignores the request (bypassing
any route entries that the URL might also match) so that the file will be served directly.
This is very convenient for static files, such as images, CSS, and JavaScript files. You can
keep them in your project (e.g., in your /Content or /Script folders), and then reference and
serve them directly, just as if you were not using routing at all. Since the file genuinely exists
on disk, that takes priority over your routing configuration.
If, instead, you want your routing configuration to take priority over files on disk, you can set
the RouteCollection’s RouteExistingFiles property to true. (It’s false by default.)
By default the routing engine will ignore route maps for all files that exist physically on the server. In short, you need to do nothing for a MVC app to link to static files.
You can also do a little trick in IIS. I store my js, images, css etc in the Content folder underneath the virtual directory.
If you then view properties (in IIS manager) of the Content folder, create it as a virtual directory, then remove the Wildcard mapping. Then set the Content folder back to a normal directory. This should then stop requests to these files being handled by the aspnet_isapi handler.
I have a custom page (isv) used in a crm 4.0 solution (through IFrames) and I want it to support multiple languages. I have localized it using resx files, but the UICulture defaults to english event though I have changed it to danish (according to System.Threading.Thread.CurrentUICulture).
How do I get the culture of the current user?
If you are using a custom page under the ISV folder, they are loaded by the CRM application and compiled on demand. So every resources are not loaded by CRM and the pages under this directory are not considered applications by IIS (except if an application is created on the directory, in IIS).
So I think there is two solutions. Create an application in IIS, and in this case the application will be handled by IIS like a standard ASP.Net application. Or you can create standard ASP.NET pages, and let CRM handle them.
In both case the culture is provided by the IFrame. When you configure it in CRM, you have the option of passing parameters (Pass record object-type code and unique identifier as parameters). The parameter that you want is the UserLCID.
See http://msdn.microsoft.com/en-us/library/cc150848.aspx for more information.