tags:

views:

43

answers:

3

Currently the entire ListItem is removed from the Doc library if the user does not have permission to view the corresponding document, but I would really like it if the user could at least see the meta data with the list item, and prevent them from accessing the corresponding document (ie they click on the document link and get denied, or they type in the url by hand and get denied, etc).

Is there some Document Library event handler that handles 'accessing' a document which I can implement and check the user's permissions before passing off the document to them? Or something along those lines..

A: 

Lists/Libraries have the following item-level event handlers:

  • ItemAdded
  • ItemAdding
  • ItemAttachmentAdded
  • ItemAttachmentAdding
  • ItemAttachmentDeleted
  • ItemAttachmentDeleting
  • ItemCheckedIn
  • ItemCheckedOut
  • ItemCheckingIn
  • ItemCheckingOut
  • ItemDeleted
  • ItemDeleting
  • ItemFileConverted
  • ItemFileMoved
  • ItemFileMoving
  • ItemUncheckedOut
  • ItemUncheckingOut
  • ItemUpdated
  • ItemUpdating

As you can see, there are no events to handle opening an item.

In order to prevent the user from accessing the document from the library listview webpart, you could potentially extend the OOTB listview webpart to incorporate your required functionality or use a secondary webpart to manipulate the OOTB listview webpart through the SharePoint API or javascript.

Dylan Berry
A: 

This is something completely experimental, I have not tried it and never heard of anyone who has, but here goes: There is a file named serverfiles.xml under Template\Xml folder. You can also create your one, just be sure to build the name as following: serverfiles[yourname].xml. This file controls redirects depending on file types, this way for instance InfoPath XML files are redirected to Forms Server. You could:

  1. Redirect all Office files to your custom ASPX page
  2. In that page's code behind apply some kind of custom permissions check (say create a group of Readers, if the user is only in that group means he can only see the metadata).
  3. Redirect restricted users to a custom error page.

This way the users can see the metadata (because from the point of view of SharePoint they are readers), but cannot see the document (as you are blocking that). Again, I have not tried it, but it might just work.

If you decide to go for it, I would love to know how it went :)

Vladi Gubler
This seems nice, although it would be at the farm level, right? That may not matter, I might be satisfied with it being at the farm level, however having an option for handling redirection at the Library level or Site level/etc might be nice. I'll think about this some more, your solution could be the one. Do you know of any articles related to this?
ferr
Wow, this is a pretty obscure approach, google seems to return 0 results for anything concerning this. About to test it out!
ferr
ferr
Guess it didn't pass one of my tests, I can still enter in the url into the address bar or right click the link and open in new window/etc and it passes right through to the pdf. The serverfile redirection does not occur..
ferr
Well, as I said, i never tried it. Was worth a shot, it could be helpful for other stuff, maybe
Vladi Gubler
Well, then you need to go the usual path: create an event receiver on doc libs that copies the metadata to a link list
Vladi Gubler
I have found a good route using an httpHandler. Not 100% tested with everything I need, but it seems to be doing the job so far, and people use it in examples for similar tasks like adding a watermark to a PDF, etc. Good tutorial here, http://dotnetslackers.com/articles/aspnet/WatermarkingPDFDocumentsUsingHttpHandlers.aspx Keep in mind to anyone out there that may utilize this, there are some strange 'bugs' with ashx files, I needed to put all of my C# code in a code behind file to get it to work.
ferr
A: 

The answer to my question: create a custom httpHandler that handles the document types that must be intercepted.

Good articles: http://dotnetslackers.com/articles/aspnet/WatermarkingPDFDocumentsUsingHttpHandlers.aspx http://blogs.msdn.com/b/kaevans/archive/2010/08/04/deploying-an-asp-net-httphandler-to-sharepoint-2010.aspx

Also, there may be a bug with the generic handler code that visual studio creates, read this article for creating an httpHandler with code behind, http://aspnetresources.com/blog/httphandler_code_behind

ferr