So in IIS 7 if there is no specific MIME definition for a certain extension, it will refuse to serve it (404) even if you can see it in a directory listing. I'm sure this is a fairly known issue, but is there a way to wildcard or set a default action for unknown file types? I want everything to be offered for download by default like with every other webserver I've used.
Add a new MIME type for files of extension * with a type of application/octet-stream. This will provide a default MIME type for all files that don't have one and bypass the blocking.
The risk, however, is you end up sharing your confidential database, configuration files and whatnot, so make sure you know what you are doing before you open your server to all downloads.
+1 #H2Professor
But here's the code (in this case web.config for IIS 7+):
<configuration>
<system.webServer>
<staticContent>
<mimeMap fileExtension="*" mimeType="application/octet-stream" />
</staticContent>
</system.webServer>
</configuration>
I believe you just need to edit your website in Internet Information Services Manager and double click the Request Filtering icon and edit it however you like there.
The mime type configuration does not allow/disallow downloading files; it just tells IIS what to throw in the header when you do download it.
Related
We're trying to leverage Azures deployment slots for an Umbraco site we've built.
By default Umbraco uses a DSN defined in the connectionStrings sections of the web.config and we want it to use the connection string for the deployment slot it's sitting in.
What we've tried
Azure deployment slots put all defined app settings (and connection strings) into environment variables and to access them we can use Environment.GetEnvironmentVariable() which works but there doesn't seem to be a way to tell Umbraco to do this.
So in OnApplicationInitialized() (in /App_Code/Core/UmbracoAppStart.cs) we loaded the connectionstring section from the web.config, grabbed the connstr from env vars, added the DSN to the connectionstring section and saved.
The correct connection string is grabbed and stored but this seems to recycle the app (due to a web.config change) and thus we just get timeouts. (Or Umbraco XML cache errors, or it takes 20 mins to load the page).
I know you can store the appsettings and connectionstrings sections in separate files. But the file attribute (that doesn't cause a recycle if the referenced file is changed) doesn't work on the connectionStrings section - only the configSource attribute and that DOES recycle if changed.
(from: ASP.NET web.config: configSource vs. file attributes)
Help
Has anyone found a way around this?
We simply need to get Umbraco to use the deployment slot connection string - not the one in webconfig.
I'm even willing to copy and paste blindly at the moment without understanding how it works - and I hate doing that :). But that's what happens when people agree when the client wants to go live just before Christmas...
You don't need to do any code to use Azure connection string or the app settings. Just give them the same keys/names as you have on your web.config and they will be used instead.
So if you have this on your web config:
<add name="umbracoDbDSN" connectionString="Server={server};Initial Catalog={db};Persist Security Info=False;User ID={user};Password={password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=300;" providerName="System.Data.SqlClient" />
Your slot configuration should be this:
To replace an app setting just use the same key. So for this:
<add key="umbracoUseSSL" value="false" />
You'd use this:
If you want the setting to be slot specific you have to activate the Slot setting checkbox.
I integrated active directory with sitecore and it works perfect, now i am trying to write patches for the config changes. Sections <membership defaultProvider="sitecore" hashAlgorithmType="SHA1"> and <roleManager defaultProvider="sitecore" enabled="true"> are changed for connection setting to AD. When i try to write config patch for this section, this section is not built at run time. But the domains section works, i mean the patch i created for this section works and writes to web.config at runtime. I observed a difference here Domains section is under <Sitecore>, <membership> and <roleManager > are in <system.web> section. Is this the reason that these are not included in web.config? can we write patches for those sections only under <sitecore>?
Any ideas are appreciated.
Thanks.
You can only patch elements within the /configuration/sitecore element.
Refer this post:
http://www.sitecore.net/Learn/Blogs/Technical-Blogs/John-West-Sitecore-Blog/Posts/2011/05/All-About-Web-config-Include-Files-with-the-Sitecore-ASPNET-CMS.aspx
I think you have to use config transforms as mentioned by leandro.
I assumming you are using Visual Studio ¿? You must specify in what are you working.
If so, you need create a transform file for the build configuration that you need, for example, one config for every environment or publish type.
Try a look at this:
http://msdn.microsoft.com/en-us/library/vstudio/dd465318%28v=vs.100%29.aspx
I was building a little 3D-application using ThreeJS and WebGL. I purposely chose not to convert models into ThreeJS compatible .json files, instead started building an importer. It works, but I also planned to have the application decide what type of model has been loaded using both file extension and MIME type, the later if the first is unknown.
I've read somewhere that the MIME Type is supposed to be application/wavefront-obj, which would be kind of weird since there is also the model tree, but okay anyways. Though browsing the IANA website for this file type yields no results.
Am I missing something?
According to wikipedia, it's text/plain for .obj.
I'm guessing it's text/plain for .mtl files as well, since there's text in them and since it "is a standard defined by Wavefront Technologies for ASCII files".
You need to update your web.config and add the reference to the obj file type
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<staticContent>
<remove fileExtension=".obj" />
<mimeMap fileExtension=".obj" mimeType="text/plain" />
</staticContent>
</system.webServer>
</configuration>
Use MIME type application/object for .obj files. It works in Chrome, Safari, and FireFox.
I was surprised to see nothing in the IANA database for wavefront obj files, considering that they've been kicking around the internet for 20 years at least. I'd be happy to collaborate with others in establishing an official MIME type.
Until then, according to section 3.3 of RFC 6838, "Personal or Vanity Tree", you can use your own media type for this, something like text/prs.wavefront-obj, in addition to text/plain. That way you can use the HTTP Accept header to negotiate the appropriate MIME type in your response.
According to IANA, the association who defines and maintains media-types (this is not Wikipedia), the mime-type of "obj" is model/obj, and model/mtl for "mtl". See other media types for models: https://www.iana.org/assignments/media-types/media-types.xhtml#model
I use Ajaxplorer as explorater for file on the server I works very fine, but the thing is that I can not, or I do not know how to change default configuration.
In the documentation it s written:
Browse to conf and open the file conf.php. Use your favorite text editor to open and modify this document. We’ll customize settings in this file for your unique server configuration and security purposes. Make the mandatory changes listed in section 2.4 Required Settings.
2.4 Required Settings
$dft_langue="en": Set the default language to be used (modify bold portion).
define("ADMIN_PASSWORD", "admin"): Set the administrator password which is granted most permissions (access) on your file server (modify bold portion).
I've been looking for the conf.php file since 1 hours but I did not find it.
So I do not know when I do it directly on the interface everytime it says 'your peferences has been saved' but when I close and reopen the window, there is no mora savec configuration.
Of course I've clean the cache after each modification.
Thank you very much in advance for your help.
Kind regards.
SP.
It is referring to the bootstrap_context.php file that you can find under system_path/ajaxplorer/conf/ folder. If you run into trouble try looking here http://ajaxplorer.info/f/topic/bug-share-center-5-0/
I am fairly green at ASP.NET coding, even though I have done very basic tasks for a while.
Recently, I have been assigned our company's website, so I am learning more of the details.
I downloaded the project from Source Safe, and I am making changes in the code.
A co-worker and I were looking at the Web.config file, and noticed this under the <configuration> section:
<appSettings>
<add key="HR_EMAIL" value="myEmailAddress#work.com"/>
<add key="APP_MODE" value="TEST"/>
<!-- PROD is the production value for ssl pages -->
<add key="HR_EMAIL_SITE_A" value="myEmailAddress#work.com"/>
<add key="HR_EMAIL_SITE_B" value="myEmailAddress#work.com"/>
</appSettings>
where myEmailAddress#work.com used to list my actual email address.
My co-worker said, "Oh, you've changed it and removed my email address."
Uh, no I have not! I could care less if these people email me!
I'm guessing something configured on my local machine (maybe in machine.config) went in and updated these values whenever I rebuilt the project.
I have used a walkthrough recently published by Microsoft (Walkthrough: Creating a Web Site with Membership and User Login), but it was in a different project.
What changed these values? Surely I did not do this in my sleep!
Chances are that someone committed these values to source control.
You got the latest value - possibly your workmate has not updated this file in a while.
Take a look at the file history in Source Safe to see what happened with this value.
section, as the name suggests, is specific to application to store custom settings. Before ASP .NET 2, this section was used to store things like connection string used by the web application.
In you case, I am guessing that, you have an admin site/system that is writing out your email adress to app.config.
I have seen another scenario, where setting will be updated by the build/release script.
You'll likely find that due to differences in enviroments, in most cases you don't deploy a web.config from enviroment to enviroment. You wouldn't want test settings, like connection strings, emails, etc getting propigated to production.
When you're likely finiding is the config in VSS is a local testing copy and the production copy has different values.