Invalid token received by FileService.ashx so blocking access

If you have questions about using mojoPortal, you can post them here.

You may want to first review our site administration documentation to see if your question is answered there.

This thread is closed to new posts. You must sign in to post in the forums.
4/25/2012 12:58:17 PM
menagerie56
Gravatar
Total Posts 130
View Posts

Invalid token received by FileService.ashx so blocking access

Hi Joe,

Had an interesting thing happen and am wondering if you know what is causing it.  I had a user try to delete a pdf file in the file manager, then upload a file of the same name.  She was getting "Operation Denied" and the log provided the following:

2012-04-25 11:19:35,693 INFO  - en-US - /Services/FileService.ashx?cmd=movefile&srcPath=forms%7Cwaiver_procedures_form.pdf&destPath=waiver_procedures_form.pdf&t=266c9b86-aba3-41f8-9b88-335a16ccc6c9&_=1335367165917 - mojoPortal.Web.Services.FileService - Invalid token received by FileService.ashx so blocking access

I've never seen this message before.  I had her try moving the file to a different directory and then upload the new version of that file to the desired directory and that worked.  I don't know if mojoPortal thought the file was still present after it had been deleted.  The user also stated that the 'old' pdf was loading in the browser even after replacing it with the new one.  She cleared out her browser cache, which didn't help.

I'm thinking that changing/updating files in the file manager won't touch the application's caching system and that is why the new version of the file wasn't being reflected in the browser.  Does that sound right?

Also, how often does the internal cache clear?

Thanks,

Beth

4/25/2012 2:36:01 PM
Joe Audette
Gravatar
Total Posts 18439
View Posts

Re: Invalid token received by FileService.ashx so blocking access

Hi Beth,

There is a security token that is passed in the url to the file service used by the file manager as a way to prevent cross site request forgery attacks that could attempt file system operations. Currently this token is a guid stored as an application variable that is regenerated in the Application_Start event.

The error can happen in a web farm scenario if the file manager page is served from one node but then the post to the file service is handled by another node becasue the applicaiton variables are not shared across nodes so the guid would not match and the operation would be denied and this message would be logged.

I just changed this in my copy to use cache instead of an application variable, but I'm afraid that won't solve it for your scenario because you are not using a distributed cache shared across nodes so in your scenario each node has a separate cache.

This security token was introduced a long time ago in version 2.3.5.3, to fix the security bug of a potential cross site request forgery, so it isn't something new.

In a fail over cluster this problem should not happen very often (only if the user is uploading right at the time when failover occurs) but if using multiple nodes concurrently and no shared cache I don't have a solution for it except to suggest using the Alternate (older) File Manager which does no use the file service and therefore doesn't rely on this token.

Best,

Joe

You must sign in to post in the forums. This thread is closed to new posts.