Access to static files in MVC 3 in an Azure web role on the Visual Studio Development Webserver
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 d开发者_如何学编程evelopment 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)
精彩评论