Hooking into SharePoint server-side

Question

Please note I am talking of injecting my code into SharePoint server-side (via a package / add-in etc) as opposed to using Microsoft.SharePoint.dll or web-services to access SharePoint.

So my problem is this, I need to customise how Document Libraries work, including custom permission management. I have been browsing through Microsoft.SharePoint.dll analysing the internals of its working. Here are my observations:

1. SPDocumentLibrary provides the core logic of managing a document library. However, its not a WebPart in itself.
2. The actual web part rendering for a Document Library probably is handled by ListViewWebPart or a derived class.
3. There's actually a SPPictureLibrary class which makes me assume it might be possible to inherit SPDocumentLibrary class to provide custom behaviour on a Document library.
4. WebPartAdder.SiteWebPartGalleryProvider in some way is connecting SPDocumentLibrary to its WebPart inside Microsoft.SharePoint.WebPartPages.WebPartAdder.AddSources method.

Now all this is client-side, none of this happens on SharePoint server itself (afaik). However I see overridable methods on SPSecurableObject that SPDocumentLibrary/SPList override, specifically:

1. CheckPermissions
2. GetUserEffectivePermissionInfo
3. GetUserEffectivePermissions
4. EffectiveBasePermissions, etc.

What I really want to do is be able to override CheckPermissions / EffectiveBasePermissions on a SPDocumentLibrary inside SharePoint server to inject my custom logic.

I would now divert my research to SharePoint server side dlls and understanding them. But I would love to get some expert opinion on whether this is feasible at all / pointed in the right direction. Microsoft's hallmark (especially considering ASP.NET 2.0 / ASP.NET MVC as a benchmark) is extensibility / provider framework. They provide excellent providers for "things" out of the box but you can create your classes by inheriting/implementing something to replace default providers. So:

1. Can I inject into SharePoint server-side. My ideal solution would be to create a SPDocumentLibrary derived class (server-side), and inject it in so that anytime a Document library is instantiated, my class object is created (instead of SPDocumentLibrary, assuming that's the class server-side too. I still need to "reflect" SharePoint server-side classes).
2. If 1) is a nopes, can I create a custom WebPart to use a SharePoint Document Library in a way where it gives a native Document Library feel, but still allow me to use a SPDocumentLibrary derived class when that web part is accessed (please again note, all my discussion is around SharePoint server-side, i.e. my code executing inside SharePoint's address space/w3wp process).
3. Why do we have logic in SPSite.EffectiveBasePermissions at all. I mean its supposed to be CSOM, and it should simply be responsible for serialization/deserialization of what is returned by/sent to server. However, I see elaborate logic in this overridden property revolving around permission deducing.
4. If both 1) and 2) is a no-op (literally :)), do I have any option manipulating SharePoint effective permissions while operating in SharePoint's address space before SharePoint takes any action based on those permissions.

I know its been a long question, but hopefully I am doing my research well.

Answer 1

I don't think you have that level of Control in SharePoint.

Not sure whether you have looked into the option of SharePoint Events. Rather than creating your own class to add the logic, you could add the logic as a SharePoint event. You can subscribe to the relevant events and add logic accordingly. For example, you could cancel an update based on your custom logic. However, I don't think you can customize the base permission logic.

The SPList has a method 'CheckPermissions' which in turn calls the 'CheckPermissions' of the base class (SPSecurableObject). However, I doubt it would be possible to create your own sub-class, overwrite the relevant methods and take over the permission logic. It is something very core to SharePoint which I don't think is intended to be customized.