I'm having issues serving out static (image) files from an Azure + MVC 3 project when running in the dev web server. I have forms authentication running on the site, and any requests for images are met with a login redirect.
I have been able to make access possible by making my images folder an application (via iis) and explicitly setting my windows user to have access to the images folder, though this only works for a debugging session, and clearly isn't a real solution.
There are a couple of problems it isn't:
Static file requests being picked up by mapped routes
Folder permissions not allowing access to the NETWORK SERVICE account
Rules in web.config requiring authorization for the folder
Currently the images reside in ~/Images/... though I have also had them in ~/Content/... which is where the main css resides. Said css always serves out without any issues.
Notably the images are not served even if you do log in.
I realise that it may be better to store these images in a blob, particularly in the development phase, and for source control, it seems easier to carry these few static resources in a project folder.
EDIT - Question was incorrect. Actually just an issue with some files being encrypted on my hd and others not, causing odd results.
It turns out windows was encrypting all of the files in these directories (not standard behaviour for my configuration, but was happening here for one reason or another). I had a couple of images that weren't encrypted (including the styles.css) but most of the images were. That meant that images wouldn't serve without my credentials against them...
So nothing to do with mvc / azure / cassini!
My guess is that this is some config issue and is not related to Azure itself.
It is probably worth trying similar questions/answers like:
My ASP.NET MVC2 application with Forms Authentication is blocking access even to Images, Styles and Scripts
Also, if you create a new project then do you see the same effect?
If no, then compare the web.config type settings one by one - the difference will be there.
If yes, then it seems like the problem is somehow at the web server/machine level (maybe something to do with anon or windows authentication in web.config and/or app.config)
Related
I created a new .NET based web application named shabang using the web client and it displays the default woohoo-page when I browse to shabang.azurewebsites.net. Then, I discovered that there's a console in the web client and when I use it, I can see a directory structure including my login name, home directory etc. However, I can't find the files being served and, since I can see a web page being rendered when browsing, I'm certain they are there, somewhere.
Where is the (or equivalent of) wwwroot?
I've googled it but it's a bit hard to word what I'm asking in a way that Google will understand. Just a bunch of guides that are way too advanced to distill the information from.
By default, it is d:\home\site\wwwroot. It can also be modified using the Azure Portal.
Note that you should use the Kudu Console to see it. e.g. https://shabang.scm.azurewebsites.net
We have a unique situation, and I can't find an answer for it. For that matter, I can't even think how to phrase the query effectively.
Our former server used IIS6. The folder structure worked like this:
ddrive
inetpub
webcontent
site 1's content
site 2's content
...
site n's content
The index.asp file that drives the websites is in the "webcontent" folder, thus all sites share a common root. This let us have one engine driving all. It worked because IIS6 stores configuration settings in the metabase (right?).
It appears (and I'm just feeling my way along, here) that configuration settings are stored in the root folder in an text file. This means that if I try to add a second website using the previous model, I get conflicts.
Two questions, then:
Are my assumptions about my situation correct?
Is there a way to use a similar setup to what I had before, or do I have to rewrite the engine? For the sites, there is no .NET. Everything is in classic ASP, migrating ever so slowly to PHP.
I have hosted a Tomcat application on CloudBees which allows users to edit some XML and saves them. I need to download and save these files locally for my personal usage. However I could not find a way to do this. I tried the 'download source' option but it downloads the original files that I had uploaded and not the edited versions. However my application is able to access the edited versions (and so clearly everything is being saved all right). Getting these files back is extremely critical and necessary for me and is, in fact, the whole motive of this app. Kindly tell if there is some way to get back the files in CloudBees or any other free Java hosting site which would allow me to do it.
It's not very clear from your question how your app is currently dealing with these files, but I'll take a swing at providing some general info.
To support editing and downloading of files, your app design would need to address the following issues:
How do users edit/upload the changed XML?
Where does your app store the changed XML?
How does your app retrieve the edited XML and make it available for download?
For #1, you will need to provide an edit or upload interface in your app for manipulating the XML files. I'm assuming this is something your app has already solved using a form of some kind.
For #2, you need to pick an approach for storing the files that is appropriate for app's needs and the runtime environment where your app will be deployed. For instance, on CloudBees (or most other CLoud platforms), it's important to understand that the local filesystem of the app can be used for temporary storage, but it is not clustered and it will be wiped away each time the app is updated or restarted. If these XML files need to be available forever, you will need to store them in a persistent location that is external to the application's runtime instance. Most developers use databases (such as the CloudBees MySQL service) to store persistent data in this way. In general, your app can store these files anywhere, but your app needs to manage how to store them, and how to retrieve them later.
For #3, to allow a user to download the changed files, you will need to implement your own mechanism for retrieving the file from its persistent location, and then send it back to the user's browser. If you want something like right-click "Save As" to work, then your app will just need to support a URL that can display the edited XML file directly in the browser. If your app then provides a link to that URL, users can download it using RightClick+SaveAs. If you want the user to be able to click on a button/link and trigger a Save As dialog automatically, then you'd need to write a URL handler (Servlet) that serves the XML content up using a Content-Disposition header (see this StackOverflow article). This header will tell the browser that the file is supposed to be saved to disk, and allows you to provide a default file name.
We have a custom CMS site in which the admin can make a change to the _Layout.cshtml (since they are making lots of changes). The site was hosted in Azure Web Sites, but now we are moving it to Cloud Services.
Now, the admin panel is reading and showing the contents of _Layout.cshtml (actually, all of the files in the ~/Views/Shared folder can be edited), but when the application is trying to write to a file, it throws this error: Access to the path 'F:sitesrootViewsoasShared_Layout.cshtml' is denied.
We are working on a new way to edit the layout files, but before we get there, we need a quick fix!
I am using this method to write to the file: System.IO.File.WriteAllText(path, fileContents);
Locally, in the windows azure emulator, this is working correctly, but not when it's hosted on Azure.
Thanks!
First of all, I have to say there will be some problems even though you can update your _Layout.cshtml file.
If you have more than one instances of your web role, once admin changed the page, it will only update the file one that instance, but others will NOT be changed by default. You have to somehow sync them.
If your instance had been moved to another virtual machine, for some reasons such as hardware failure or virtual machine resource reallocation, all changes your admin made will be lost.
So I strongly recommend to amend your implementation. How about save the change part into BLOB, table or database, then when the page was rendered you retrieve the content from DB. I think this would be better than just modify the page itself.
HTH.
I need to clear the IIS cache on my server. The exact reason is detailed below; but the reason doesn't matter. I'm 100% sure that this is the solution I need; as detailed below, I have used the process of elimination to determine that this is, indeed, the problem I'm facing, and the solution I need.
I have an MVC3 app that's themeable (skinnable architecture). Think of it as Wordpress; users can develop a theme, download it, and activate it on their site. The theme controls exactly the final HTML output. This is an over-simplification, since I provide an API with useful functions to be consumed by themes.
Anyway, users can change the theme of the site. The theme is currently stored in a static variable. When a view page is rendered, the name of the theme determines the location of the layout file (which contains references to the CSS files, etc.) and the view files. The theme is a setting that persists in the DB.
For example, if I have a theme called "Foo", then when requesting the /Admin page, I might use /Themes/Foo/Admin.cshtml. If I have another theme called "Bar" which does not have that file, then for /Admin it might request /Themes/Bar/Generic.cshtml as the layout.
The problem is that changing a theme means that every single page on the site is outdated. This means that any sites cached on IIS7 will show the old theme; this is incorrect. I need them to show the new theme.
Anyway, IIS7 uses caching by default. I need essentially a way to clear the cache when a user changes the theme. Currently, this is not happening, and users continue to see the old theme until the cache (somehow) expires itself.
I am not using output caching, or any other form of explicit caching; this is a "vanilla" ASP.NET MVC3 application from a caching perspective (i.e. I didn't add/configure any caching). IIS7 has its own default caching. I know this, because if I disable output caching in IIS7 for my Site, I will always see the correct theme after a change.
How can I flush the cache? Other SO questions point to using Cache.blah, and I tried using HttpContext.Current but that is null during tests (using VS test tool) -- because the ASP.NET pipeline is not used in full.
To explain, in an integration test, I basically:
Go to localhost/Test/
Log in (submit values into the forms)
Change the theme by browsing to the right page and clicking the right link
Request another page
See if the theme changed (based on the layout/css file name).
This is all done by code; I use a C# port of HtmlUnit, and along with deploying my app to /Test in IIS, I can essentially browse it like an end user.
Currently, this test passes around 50% of the time. The problem is that IIS is caching the results, and I can't cleanly reliably reset the cache on the server-side.
Again, I'm not talking about clearing the session or the user-side cache; IIS itself is the culprit guilty of caching my application. Nor do I want to completely disable the cache via the IIS settings, a) because I can't force people who install my application to do that, and b) because caching is good.
So how can I force flushing the cache on the server?
For example, I tried programatically touching web.config; this works, but recycles my application pool, and so, kills my static variables; every request means reloading all the static vars from the DB, which kills my performance.
As you requested I have amended this post:
You can use output cache, you say that the selected theme is stored in the database ( like settings for the site ) Well I would add another column with say a GUID and then use this as the varybycustom value.
Your global.asax file will be able to run code:
void Page_Init() {
///code here to get the GUIDforthissitestheme
var outputCacheSettings = new OutputCacheParameters() {
Duration = Int32.MaxValue, //think its maxvalue
VaryByCustom = GUIDforthissitestheme
};
InitOutputCache(outputCacheSettings);
}
At least here you will have output cache, but also every change of theme, changes the GUID so therefore changes the cache and then your page should be new.
I did something like this on a site that listed products, and when the products database was updated the key would be changed, however I can't find what site I implemented it and I work on a hell of a lot of sites.
hope this helps
Set up 'Cache Rule' in 'Output caching' feature with 'File Cache Monitoring' set to 'Using file change notification'. Then 'touch' the files theme change affects, from .net code you could do:
System.IO.File.SetLastWriteTimeUtc(fileName, DateTime.UtcNow);
The issues you are describing sound a lot like a client side caching issue. Have you checked this with a HTTP Proxy like Fiddler to verify if this is getting cached on the client?
If you are seeing HTTP 304's after a template change you may want to try configuring IIS (or your site template) to disable client side caching.
I dont think the approach mentioned for themes is correct.
If we are using STATIC variables , then it will affect all the users and all the pages.(Which is certainly not required.)
We can think of two approaches,
Use theme name in url and make it as a prat if RouteData. So the url "http://myHost/BLUE/.." will return in BLUE theme and "http://myHost/RED/.." will return in RED theme. If user will change theme then url will be updated.
The problem with above approach is next time user browse, it will load default theme.
So better approach will be save theme as a part of user preference. Once user logged in read the theme from DB and set the RouteData value.
Just touch web.config. That's the easiest and most reliable way. Flushing the application pool programmatically is overkill.
If you have a problem finding out where web.config is in a test environment (since System.Web.HttpRequest.Current is null, and similar for Server), you can always use an app.config file to point out the location.
Again, there's no other easy way to do it; even disabling output caching, as mentioned in the question, is hard to do through web.config alone.