[geeklog-devel] FCKeditor integration

Vincent Furia vfuria at gmail.com
Mon Aug 31 01:24:43 EDT 2009


I think the ideal solution would be for all uploads to wind up outside the
web root or in a "closed" directory (i.e. not allowing downloads). Then we
can have some php pass through scripts that control access to uploads. Then
we can us our autotags (or something similar) to include links/pics/etc in
articles and other content.

This has a couple advantages. Users can submit uploads as part of articles
(or other submissions). They would not be accessible directly from the web,
making "attacks" like the recent malware uploads worthwhile (sure you can
upload a file, but then it just disappears into a black hole).

The pass through scripts could would only allow access to files that were
approved, and only to users who have the correct permissions to
view/download the content.

The downside is doing this would not be a small project (though I don't
think it would be huge either)...

-Vinny

On Sun, Aug 30, 2009 at 2:49 PM, Dirk Haun <dirk at haun-online.de> wrote:

> Okay, after that recent FCKeditor-related debacle (our fault, not
> theirs) it's about high time that we reconsider how we integrate
> FCKeditor and why.
>
> So users want to use images and other media (sound, video) in their
> posts and may need a way to upload those first. I can understand that.
>
> But why exactly did we allow to upload archive files (.zip, etc.)? I
> can't really think of a use case for those inside an _editor_. If at
> all, those should be uploaded through a separate plugin, e.g. File
> Management.
>
> Same with the various text documents (including Word, Excel, PowerPoint
> and others) that are still allowed now (in 1.6.0sr2).
>
> In other words: I can't really see a good reason to continue to support
> uploads to FCKeditor's generic "File" directory. I'd suggest to drop
> that and only keep the other three (Image, Media, Flash) and only allow
> the file types that go into those.
>
>
> Next: Permissions. Anonymous users should never have been allowed to
> upload something without approval. That was a big mistake there.
>
> A common request is to allow image uploads in story submissions. Should
> we offer this through FCKeditor? I'd say no, at least not to "normal"
> registered users. A story will go through moderation, but an image (or
> video) would be available immediately. That is asking for trouble.
>
> So I guess the way around this is to introduce separate .upload
> permissions (story.upload, staticpage.upload, etc.) and a plugin API
> function that checks if the current user does have that permission.
> Actually - it doesn't work that way. We would need a callback or
> FCKeditor would need to be made aware of where it is currently (in a
> story editor, static pages editor, etc.) so that it can check that.
> Anyone more familiar with the internals of FCKeditor's PHP connector who
> would like to make a better suggestion?
>
> What I mean is: The part of Geeklog that's integrating FCKeditor needs
> to decide whether to show the upload option to the current user, but
> then the actual upload function has to be able to check if it's really
> okay to perform the upload.
>
> In any case, the goal should be to only allow uploads for users who have
> specifically been given the permission.
>
>
> Not security-related: I'd also like to see an option to enable/disable
> FCKeditor on a per-user basis. Obviously, if it's disabled in the
> Configuration, you shouldn't be able to enable it. But if enabled, I'd
> like to have the option to disable it for me.
>
> Anything else?
>
> bye, Dirk
>
>
> --
> http://www.haun-online.de/
> http://geeklog.info/
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20090830/82ca9822/attachment.html>


More information about the geeklog-devel mailing list