IIS has a default blacklist of filetypes that won't be served to the users of its sites, some of those types are: .asax, .cs, .vb, .config.
You can find the setting in the Features View under Request Filtering.
I did a powershell query to find all of the filetypes in my website, and whitelisted only the filetypes I want IIS to serve:
Get-Childitem . | WHERE { -NOT $_.PSIsContainer } | Group Extension -NoElement | Sort Count -Desc > FileExtensions.txt
Now the sites works perfect and secure, until I enable ASP.Net bundling. 404's will occur on the bundled styles and scripts, as those are not whitelisted.
Now the question: can I whitelist bundled files and what extension should be added to the Allowed Extensions list in IIS?
Yes you can ;-).
Just add the correct extention to the bundle name.
e.g.: ~/Bundles/Styles => ~/Bundles/Styles.css
Change in RegisterBundles() method and in Styles.Render() and you are done
Related
I just published my web app which has the following structure:
Project Name
StylesFolder
filename.css
anotherfile.css
JavaScriptFolder
bootstrap.js
Index.html
What I did was:
Adding a new WebSite in the server IIS with the path were I publish my WebApp (ex. C:\WebProjects\PublishedApp\Project Portal)
Selecting my published app and converting into an application (The alias name was Project Name and the physical path was C:\WebProjects\PublishedApp\Project Portal\Project Name)
The problem is when I try to see the website. I'm able to enter to 192.169.100.20:80/Project%Name/ and my index page is loaded (I can see the text, inputs, etc.) but I cannot see any stlye and javascript input and when I check the console logs all the files are getting a 404 error response.
When I check which URL is used by the files I can see that they are trying to get accessed by 192.169.100.20:80/Project Name/StylesFolder/filename.css etc...
So my question is what can I do to remove the /Project%Name/ string from the URL?
PD. I'm using IIS 7
When you add your website in IIS, select the application folder you published. For example, when you publish your application to D:\Program Files\Publish Folder, select the Publish Folder folder directly when adding the website and choose the physical path.
This is the reference:Deploy Website on IIS
When I try to open a form published from InfoPath I now get this error:
"The following location is not accessible, because it is in a different site collection:
https//portal/sites/forms/Daily%20Activity/Forms/template.xsn?SaveLocation=https//portal.alamedacountyfire.org/sites/forms/Daily%20Activity/&Source=https//portal.alamedacountyfire.org/sites/forms/Daily%2520Activity/Forms/AllItems.aspx&ClientInstalled=false&OpenIn=Browser&NoRedirect=true&XsnLocation=https//PORTAL/sites/forms/Daily%20Activity/Forms/template.xsn."
Correlation ID:12c0ab9c-caff-80a8-f1b4-64d81dcfa6ea
Following are some options that you can try:
1) Save the form template (.xsn) as the source files in the publish options. Look at the manifest file in notepad and see if you can find a reference to the incorrect location. If so, correct it and Republish the form.
2) Clear the InfoPath cache on that machine. Start->Run "infopath /cache clearall"
3) See if the site collection has a managed path, if so, give the proper url while publishing. The XSN might be getting deployed on the root site and throws error since the intended list does'nt exist.
I found this worked for me. Got the answer from another post.
"I had a similar problem and found it was due to the request management service routing from my web application host header to the server name.
There was a routing rule in my request management settings. I just disabled routing and the problem went away. I used the following powershell to disable it. "
$w = Get-SPWebApplication "http://webapphostname"
$r = $w | Get-SPRequestManagementSettings
$r.RoutingEnabled = $false
$r.Update()
You may want to configure it rather than disable it. Here’s a good resource to get you started:
http://www.harbar.net/articles/sp2013rm1.aspx
I am setting up Azure CDN, and having trouble setting the Cache-Control header.
I used Cloudberry Explorer to setup a sync between my server folders and the CDN. This is working well. All my files were copied to the CDN with no problem.
Under Tools > Http Headers > Edit Http Header I set the value for Cache-Control to be: public,max-age=604800
However, this does not appear to be having any effect (according to both Fiddler and Page Speed).
Any tips on setting the Cache-Control header for the Azure CDN would be GREATLY appreciated.
I had this issue myself and needed to update the Cache-Control header on thousands of files. To prevent caching issues in sites, I re-deploy these files with every release to a new path.
I was able to patch together some different suggestions online and ultimately landed on the following solution, which I currently use for deploying one of my production apps.
You need two files, and the script assumes they're in the same directory on your computer:
A text file with a listing of the files in the container (see example below)
The PowerShell script
The Text File (file-list.txt)
The file should be in the example format below with the full file path as deployed to the CDN container. Note this uses forward slashes, and should not include the container name since it will be included in the script. The name of this text file will be included in the PowerShell script below.
v12/app/app.js
v12/app/app.min.js
v12/app/app.min.js.map
v12/app/account/signup.js
v12/app/account/signup.min.js
... (and so on)
The Script (cdn-cache-control.ps1)
The full script is below. You'll need to replace the constants like STORAGE_ACCOUNT_NAME, STORAGE_KEY, and you may need to update the path to the Azure SDK DLL if you have a different version. There are also 2 possible implementations of $blobClient; I repurposed some of this code from a source online, and the un-commented one works for me.
The key difference between what I have here and what you'll find online is the inclusion of $blob.FetchAttributes(). Without explicitly calling this method, a majority of the blob properties like Content-Type, Last Modified Date, and others will be loaded into memory as empty/default values, then when $blob.SetProperties() is called these empty values will blow away the existing ones in the CDN, causing files to load without a Content-Type among other things.
Add-Type -Path "C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.9\bin\Microsoft.WindowsAzure.StorageClient.dll"
$accountName = "STORAGE_ACCOUNT_NAME"
$accountKey = "STORAGE_KEY"
$blobContainerName = "STORAGE_CONTAINER_NAME"
$storageCredentials = New-Object Microsoft.WindowsAzure.StorageCredentialsAccountAndKey -ArgumentList $accountName,$accountKey
$storageAccount = New-Object Microsoft.WindowsAzure.CloudStorageAccount -ArgumentList $storageCredentials,$true
#$blobClient = $storageAccount.CreateCloudBlobClient()
$blobClient = [Microsoft.WindowsAzure.StorageClient.CloudStorageAccountStorageClientExtensions]::CreateCloudBlobClient($storageAccount)
$cacheControlValue = "max-age=31556926"
echo "Setting cache control: $cacheControlValue"
Get-Content "file-list.txt" | foreach {
$blobName = "$blobContainerName/$_".Trim()
$blob = $blobClient.GetBlobReference($blobName)
$blob.FetchAttributes()
$blob.Properties.CacheControl = $cacheControlValue
$blob.SetProperties()
echo $blobName
}
It was tricky to find information about mass-setting the Cache-Control header but I've run this script for multiple production releases with great success. I've verified the configuration of the header as well, and routinely run Google's PageSpeed Insights against my site to verify.
I have simple route map like:
routes.MapRoute("Test", "test/{action}/{id}", new {controller = "Test", action = "Index", id = ""});
My route paths are like:
"/test/do-something/1.0.1"
Which works completely fine in local testing and self hosted .NET 4.5 on IIS7+
However, when I host it in Azure, it seems to have issues with the ID containing two ".", telling me that "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.".
When I change the path to "/test/do-something/1" it works on Azure as well.
Why does Azure seem to prohibit ID's with "." and what can I do about it?
I would recommend using '-' in your id as opposed to '.' (periods), it's more friendly in terms of SEO.
If you really want to get it working with periods, you could use a tool called URLScan.
What is URLScan?
There is an option to configure:
AllowDotInPath=0
By default, this option is set to 0. If this option is set to 0,
URLScan rejects any request that contains multiple periods (.). This
prevents attempts to disguise requests for dangerous file name
extensions by putting a safe file name extension in the path
information or query string portion of the URL. For example, if this
option...
Here is a link to the configuration.
We have a legacy (classic asp) CRM that I maintain in my organization. Users may upload files through the web front, they are stored on a network share and the filename, uploader, etc is saved to a database. Everything is well and good with the exception of .config files.
For some reason certain people can download these just fine, but other people recieve this error:
The type of page you have requested is not served because it has been explicitly forbidden. The extension '.config' may be incorrect.
it would seem that on some users computers the link for the file is "file://networkshare/filename" (which works) and on other machines it is "http://networkshare/filename". (which doesn't work)
I have the mime type for .config set to text/plain in iss6. All users are running IE8.
The code on the page creates a href links based on records returned from the database.
Why then is there there the difference in the way the link is rendered differently in the same browser on different pc's? How do I allow .config files allowing people to view the sites web.config?
The code that builds the link is:
function getlink(file_nm,path)
{
thisPage.navigate.CheckDocumentAttachedToRequest(file_nm, path)
var sDocLink = path.replace(/\//g,"\\") + "\\" + file_nm;
return "<A class=\"parislink2\" TARGET=\"_BLANK\" HREF=\"\\\\" + thisPage.get_sServerName() + "\\" + sDocLink + "\">" + file_nm + "</A>";
}
Weird.
I know that IIS 6 will return error 404.3 if a client request refers to a file name extension that is not defined in the MIME types.
However you do have it defined. You can try as a test using the wildcard () in your mime types. ( for the file extension and text/plain for the mime type.) The wildcard can be a security risk but if you are serving up configs..perhaps this application and server are internal to your network and it would be ok to use the wildcard.
I would also check your ISAPI extensions (not filters, but extensions) and make sure .config
is still in there. It should be by default.
Defining a mime type at the global level in IIS should filter down through and override any mime types set at the folder level.
An IIS reset is needed everytime you change mime types.
Perhaps it is a browser issue?
(an issue on the client side for the links that do not work..an issue like "browser control".)
It is almost as if some of the browsers are interpreting your function correctly when the link is built..and others are substituting "http" instead of "file" as the protocol when they render the HTML from the function call. Perhaps you could hardcode your function to us "file:" as a string that is placed at the begining of your link code. (trying to overide any "http" string that gets place in there by the HTML sent back by the server or rendered by IE8.)
The wildcard was filtered out for security purposes in the above post. (wildcard = "an asterisk")