Windows / NTLM Authenticated Application Manifest File Errors
How do browsers implement requests for Cache application manifest files and differ from how other files are requested?
I ask because I am seeing behavior that I would not expect when using Windows / NTLM authentication in IIS 7. The situation is that I have a site with a specific manifest file. With anonymous authentication, everything works as expected - the site loads and is available offline.
When I turn off anonymity and turn on Windows Authentication, the site will load after logging in, but I see an error on the console (in Chrome or on iPad 2) stating that the manifest file cannot be retrieved.
On iPad, the error is that the application cache file cannot be selected. In Chrome, the specific error is the "Application Cache Error: Failed Manifest" event (401) "I see a 401 response code in the web server logs in both instances.
Why this behavior seems unexpected, requests for all other resources (CSS, JavaScript, images) work as expected. Alternatively, I can navigate to my .appcache file and download it.
Can anyone please explain what's going on?
Has anyone else encountered this and found a solution?
source to share
Not sure if this is still relevant, but I also have this problem.
Since my site is making AJAX requests as soon as the page is loaded, I am asked to enter the credentials for the request. Once this has happened, launching it applicationCache.update()
updates the application cache correctly.
So as a job, maybe try making an AJAX request to something so that the user is prompted for credentials, then call applicationCache.update()
.
source to share
I know his old question, but I had the same problem that brought me here.
my setup:
servers - IIS8
authentication - windows
anonymous authentication - enabled (did this so that I could get my dynamic manifest which was selected regardless of authenticity, I had to then decorate all other controllers with [Authorize]
)
With the above setting, the app will cache however, when loading from the cache, if an update was found in the manifest, some sections were not fetching (eg allowed content) because the user was not "logged in" and hence did the full update even fail.
My solution was to add an ajax call to the authorized resource, such that when the user was online, they would be prompted to log in, that next time the cache was refreshed, they would be authorized again.
source to share