[development] hook_fileapi (file products and download permission)
Robert Douglass
r.douglass at onlinehome.de
Tue May 9 10:56:51 UTC 2006
A fileapi hook was proposed nearly 2 years ago, much along the same
lines. It was concluded, along the way, that the place for this is in
the file.inc file or in some centralized upload manager. I agree.
The filemanager[1] module has had the problem of access permissions
solved for a very long time. It has a hook that lets modules impose
their own access restrictions on downloads, and supports separate
public/private download regions (it doesn't force you to choose between
one or the other). Furthermore, the filemanager module only provides the
API for uploading and downloading, not the user interface. The UI is
provided by the attachment module [2]. Other modules (acidfree) have
decided to use the filemanager module as their basis for dealing with
uploads. I feel that it is close to what we want in core, and that
building the proposed fileapi hook would be much easier if this were the
case.
If you're not familiar with the filemanager module, please review it.
I'd be interested in hearing what criticisms exist. I'd be in favor of
moving it to core.
cheers,
Robert
[1] http://drupal.org/project/filemanager
[2] http://drupal.org/node/10245
Nedjo Rogers wrote:
> Dave,
>
> So far as I can tell, the problem you're addressing indeed exists as
> you describe it: there is no opening in the file api to enable nuanced
> file access control. And it should be addressed--there's no sense in
> us having to override/replace our file api just to control access (as
> was done, e.g., in the ecommerce file.module).
>
> Your suggested approach for handling access looks basically sound to
> me--but it would be more useful to hear from more experienced
> fileapi-ers. Walkah, killes, dopry, Chris Johnson, etc.?
>
> Likley we'd want to keep it as close as possible to existing _api and
> _access hooks. So, e.g.,
>
> * @param $op
> * The type of event ('upload', 'download', 'update', 'delete')
>
> might be better as
>
> * @param $op
> * The type of event ('insert', 'view', 'update', 'delete')
>
> Are you thinking of doing this as a contrib module for 4.7? Part of
> ecommerce, or a generic file handling module?
>
More information about the development
mailing list